blog: One Bank or Many? A Field Guide to Structuring Agent Memory#2747
Merged
Conversation
A field guide to bank strategy in Hindsight: a bank is a recall boundary, when to use separate banks vs tags within one bank, the dynamicBankId/granularity config, anti-patterns, and a decision checklist. All claims grounded in the source.
Tone down the opening 'one architectural choice' claim, and add a 'Does one bank or many affect performance?' section: memories live in one table with bank_id as a column (per-bank vector index on the default Postgres backend), so one-vs-many is a correctness decision, not a performance one.
Soften the description's 'one architectural decision / useful or a liability' framing, and make the performance section modest: number of banks is usually not the lever for recall speed, rather than asserting either shape always performs well.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
New non-integration feature/concept post: how to decide what a Hindsight bank should represent.
The idea
A bank is a recall boundary —
recall/retain/reflectall stay inside one bank and there is no cross-bank query. So every scoping decision reduces to: if A retains a memory, should B be able to recall it?What it covers
bank_id= an empty bank)tags+tags_matchas a within-bank partition, and whyany(includes untagged) makes tags a soft partition, not a security controldynamicBankId/dynamicBankGranularity(Claude Code),bankGranularity(Paperclip), oh-my-pi's global / per-project / per-project-taggedGrounding
Every claim was verified against the source (bank model, per-bank query scoping, no cross-bank recall, tag SQL semantics) and the integration configs. Companion to Inside retain().
Cover: editorial family (matches Inside retain()), 1600x900.
🤖 Generated with Claude Code