AI Agent Memory Architectures: Choosing a Storage Model
Compare persistent agent memory architectures across client-managed state, dedicated memory engines, raw vector databases, and self-hosted MCP knowledge layers for cross-tool portability, restart survival, and data control.
Choose agent memory by the records you need to preserve, the people and agents that must use them, and the controls required when those records change. A local client feature may be sufficient for one person's recurring context. A shared knowledge layer becomes relevant when several interfaces need authorized access to organizational evidence and work results.
Key takeaways
- Persistence, retrieval, access control and context selection are separate responsibilities. MCP supplies an interface; it does not supply all four.
- Provider features, memory engines, agent runtimes, database primitives and shared knowledge layers overlap. They are not mutually exclusive storage categories.
- Readable records, metadata, embeddings and relations can coexist. A vector database does not necessarily store vectors alone.
- Evaluate updates, conflicting writes, denied access, deletion and restore as well as answer quality. Version history is useful but is not a complete backup.
Start with the memory's purpose and scope
Separate active context from durable state. A model request sees a bounded context, while its client may persist transcripts, project instructions or memory files. Restarting loses state held only in a process; it does not necessarily erase saved client memory. Cross-client sharing is a different question from persistence.
Identify whether you need personal preferences, an agent's execution state, conversational facts, or shared organizational documents and decisions. Record who may read and change each category, which source is authoritative, and how corrections become effective. A transcript can preserve evidence without providing a policy for extracting or using it.
Compare approaches at the right abstraction level
| Approach | Records and retrieval | What the team must evaluate |
|---|---|---|
| Client or provider memory | Instructions, saved conversations or extracted context; behavior depends on the feature. | Persistence, inspection, scope, export and sharing across the required clients. |
| Memory engines such as Mem0 | Extracted readable memories and metadata, with retrieval indexes and optional graph features. | Extraction errors, updates, provenance and the differences between hosted and self-hosted editions. |
| Stateful agent platforms such as Letta | Agent state, in-context memory blocks and separately retrieved archival information. | How memory management fits the agent runtime; do not assume it is a drop-in external MCP memory server. |
| Temporal graph approaches such as Graphiti and Zep | Entities, relationships, episodes and temporal information. | Effective-time interpretation, fact updates and the distinction between a framework and its managed offering. |
| PostgreSQL with pgvector | Relational records and vector retrieval, with application-defined memory behavior. | Extraction, context assembly, MCP integration, authorization and operations that the application must provide. |
| Reference MCP memory server | A local JSONL graph of entities, relations and observations. | Suitability as a learning baseline; test persistence, concurrent access and recovery before broader use. |
| Shared knowledge layers such as AKB | Organizational documents, tables, files and explicit relationships accessible to agents and people. | Permissions, document history, retrieval, source maintenance and the required application interfaces. |
The examples describe architectural choices, not a product ranking. Check the exact edition and release before treating a capability as available.
Extracted memories are not just compressed vectors
Mem0 can retain readable memory records alongside metadata and retrieval structures. Its open-source graph documentation describes graph context returned alongside vector results; do not assume hosted ranking behavior applies to that configuration. Extraction can omit qualifications or preserve an incorrect statement. Test the retained record against the original evidence before claiming token savings or better answers.
Agent state and graph memory serve different needs
Letta's stateful-agent documentation distinguishes persisted agent state and memory management. In-context blocks and archival retrieval are different mechanisms. A filesystem interface such as MemFS should not be treated as the universal storage model for every deployment.
Zep distinguishes its managed offering from Graphiti, the temporal graph framework. A graph can record when a fact was valid and where it came from, but an answer still depends on correct ingestion and retrieval. Verify integrations for each product; one component's MCP support does not establish another's.
What a shared MCP interface does—and what remains to test
MCP can give compatible clients access to the same service. It does not guarantee identical tools, automatic synchronization, durable writes, business authorization or lossless migration. Streamable HTTP can expose a shared backend. With stdio, a client launches a subprocess; two clients share state only if their processes connect to the intended common backend or a storage design that safely supports concurrent access. See the MCP transport specification and verify the protocol revision supported by your deployment.
Use independently scoped identities for people and agents. Enforce permissions in the service rather than relying on prompts. Stored memories and retrieved documents are untrusted input: they must not authorize tool calls, grant access or override application rules.
AKB as shared organizational knowledge
AKB's public documentation describes documents, tables, files, explicit relations and multiple retrieval paths, with MCP access for agents and REST/UI access for people and applications. Its document history supports reviewing changes. Evaluate the supported interfaces and resource types in the release you deploy.
Keep Core storage and retrieval separate from optional ingestion and curation workflows. Collector or Gardener packaging and released capabilities require verification; their existence does not establish that every governance workflow is built into Core. Use supported writes rather than treating direct Git edits as a normal way to bypass the service. Document revisions, database recovery and attachment backups cover different recovery needs.
Test the lifecycle before selecting a storage model
| Scenario | Evidence to collect |
|---|---|
| Restart and cross-client use | Confirm a write by record identity, restart clients and server, then retrieve the expected version from each supported interface. |
| Concurrent updates | Two writers update the same base version; verify documented conflict handling and no silent loss of an accepted change. |
| Contradictory facts | Retain source, effective date and revision; verify the answer distinguishes superseded and current guidance. |
| Exact and semantic retrieval | Test identifiers, paraphrases and relationship questions against annotated evidence. |
| Permission revocation | Verify denial across reads, search, snippets, metadata, caches and derived memories against the agreed propagation policy. |
| Deletion and retention | Trace the record through source, derived memories, indexes and backups; verify the documented retention and restore behavior. |
| Malicious stored instructions | Confirm that retrieved text cannot expand authority or trigger an unapproved write. |
| Export and restore | Restore the required content, metadata and relations into an isolated environment; test permissions and queries again. |
Measure retrieval, answers and cost separately
LongMemEval (ICLR 2025) provides 500 curated questions across five memory abilities, including temporal reasoning, knowledge updates and abstention. It is useful for designing evaluations, but does not certify enterprise permissions or prove a particular AKB result.
A hypothetical pilot might use 20 scenarios x 2 clients x 3 roles = 120 cases. This is an illustrative worksheet, not an industry standard or evidence that testing is sufficient. Define expected allowed and denied outcomes before running it; add realistic corpus, concurrency and failure cases.
Report retrieval Recall@k against relevant evidence, source-supported answer correctness, task success, p50/p95 latency and update visibility separately. Count unauthorized disclosures over attempted unauthorized cases; zero observed disclosures applies only to the tested scope.
For a defined period, cost per successful task equals total in-scope cost divided by unique successful tasks. Include extraction, embeddings, retrieval, generation if in scope, infrastructure and review labor, including failed and retried work within those categories. Count a task that succeeds after retry once. With zero successes the ratio is undefined. Compare candidates under the same workload and cost boundaries.
Operational and licensing decisions
Self-hosting changes who operates the system; it does not establish complete offline operation. Inspect model, embedding, telemetry, authentication and client network paths. Managed services shift only contracted responsibilities. Assign owners for backups, upgrades, permission mapping, source freshness and incident response in either model.
AKB's current BSL 1.1 license is source-available, with a conditional production-use grant below 100 aggregated Named Seats as defined there. The threshold and qualifying third-party hosted, embedded or rebranded services require separate commercial licensing. Check the deployed release and its exact definitions. Verify other products' core, adapter and hosted-service terms separately.
Frequently asked questions
Can Claude Code and Cursor share memory without lock-in?
Compatible clients can share a backend through supported MCP connections. Verify authentication, tools, write visibility and conflicts in both clients. A common protocol can reduce client coupling, but backend export and migration remain separate tests.
Does changing the model erase stored memory?
Not inherently, if the same persistent backend and retention policy remain in place. The new model or client may select and interpret context differently, so rerun retrieval and task tests.
How does a knowledge layer differ from a vector database?
A vector database is a storage and retrieval component and may also retain readable payloads and metadata. A knowledge layer adds a defined resource, access and lifecycle model. Evaluate the complete application rather than assuming vectors imply opaque or unversioned data.
Is AKB automatically free for a small team?
Do not infer eligibility from headcount alone. The applicable license defines Named Seats, aggregation and third-party service restrictions; review those terms for the intended deployment.
Can several agents write safely at once?
Only if the selected service's concurrency and retry semantics support the workload. Test conflicts and uncertain write outcomes; neither MCP nor Git history alone proves safe concurrent mutation.
Explore shared, inspectable agent knowledge
Evaluate how AKB can support shared evidence, controlled updates and access across people and agents.
