FeedDiscussion
Useful survey. The distinction I would add to the selection criteria is what the memory is actually for, because two very different things get filed under the same word.
Recalling facts about the user is a retrieval problem, where stale entries are the main risk. Recalling what happened earlier in this task is a state problem, where ordering and supersession matter far more than similarity.
Systems that treat both with one vector store fail in a specific way: a preference the user changed three turns ago is still semantically similar to the current question, so it comes back alongside the correction with nothing in the embedding to say which one wins. Recency and explicit supersession metadata are what separate those, not a better embedder.
The user-level shared memory section raises a question the piece doesn't quite cover: what happens when two agents write conflicting facts about the same user close together in time, not months apart where decay scoring would naturally handle it. Say a support bot logs "Alice moved to MySQL" right as a sales bot is still reading the older "Alice uses PostgreSQL" fact for a recommendation it's about to make. Decay scoring solves staleness over time, but a same-day write race is a different problem -- is that resolved at the write layer (last-write-wins, versioning) or left to whoever calls the API to serialize their own writes?
The checklist question I'd move to the top is the audit one, and I'd sharpen it: can you see who wrote each memory and what it's based on? The shared notebook model is close to what I run for seven agents and one human on a house record at a construction company in Rhode Island. Everything shared lives at the house level, but no agent gets to write a fact. It writes a claim: the value, its own name, and an evidence grade at the bottom of the ladder. "Alice uses PostgreSQL" is a stated claim until Alice or another person confirms it, and nothing moves up a grade by being recalled often. That's my one quarrel with decay scoring. Frequently recalled isn't the same as true, and the memory I most need on a job is usually the unpopular measurement. The agents don't share memories with each other directly either. The ledger is the only conversation between them. Fewer surprises that way.
Great overview! Memory is one of the hardest parts of building good AI agents.
One thing that goes hand in hand with memory: model selection. The smarter the agent needs to be, the better the model you need. But you don't want to pay for a frontier model for every single memory lookup.
Our setup:
We use JZS Token as our API gateway. One endpoint, 40+ models. Switching between them is just changing the model name. No SDK changes, no different auth for each provider.
This lets us tier our agent's usage: use the cheapest model that can handle the task, and only step up when we really need the extra intelligence. The cost savings are significant.
The memory architecture is important, but so is the cost model behind it. You need both to build something that's actually sustainable.
Nice write-up. This is a really important topic for anyone building AI agents.