Three common patterns for agent memory are per-user memory, stateful agent runtimes, and shared knowledge stores. Choose among them by who needs to read and correct the knowledge; one system may use all three.
Key takeaways
- Per-user memory fits personalization inside one product, such as remembering a customer's preferences.
- Runtime memory fits a long-running agent whose state belongs to that agent.
- A shared knowledge store fits facts that several agents, tools, and people must read, correct, and trace.
Start with the next reader
Take a team decision such as "new services use the shared payments client." A coding assistant needs it next week. A review agent needs it during pull requests. A new engineer needs it during onboarding. If the decision stays in memory accessible only to that agent, the other readers cannot reuse it.
A preference such as “this user wants short answers” usually belongs in that user’s memory scope. It may follow the user across authorized tools without becoming team knowledge.
Compare the three options
| Option | Example to evaluate | Good fit | Question to ask |
|---|---|---|---|
| Memory layer for an application | Mem0 | Personalization, such as user preferences and history | Which other tools and teammates can read this memory? |
| Stateful agent framework | Letta | Agents that keep their own state across sessions | Can agents outside this framework use the same memory? |
| Shared knowledge store | AKB | Team knowledge used by several agents and people | Who owns and reviews what gets written? |
These are illustrative design categories, not product limits; check current documentation when evaluating a tool.
Check correction and traceability
Ask what happens when a remembered fact is wrong. In a shared store, a person should be able to find the entry, see who wrote it and when, correct it, and confirm the next answer uses the correction. In per-user memory, the user or the application usually handles the fix.
Also ask who can read each entry. Shared knowledge needs explicit access scopes. Per-user memory needs isolation between users.
Decide where AKB fits
AKB, Dnotitia's agent knowledge base, is a shared store. Agents connect over MCP, read and write documents, tables, and files in vaults, and link entries with explicit relations such as depends_on. Document changes retain revision history, so people and agents can inspect earlier versions. Vault permissions are granted per user, per organization, or public.
AKB stores knowledge and leaves agent execution to your runtime. Private session memory and shared team knowledge still need separate access scopes; connecting clients to the same backend does not make private notes public to colleagues. A team can keep per-user preferences in the application, run agents in its existing runtime, and put shared decisions and reference material in AKB.
Try one shared decision
Write a team decision from one agent, then give a different agent appropriate access permissions and ask it in a new session to find and cite the decision. Correct the decision and repeat the question. This checks cross-agent reuse and correction visibility for that workflow; broader access and retrieval tests remain separate.