A memory system is easy to add. A memory system your company can explain, govern, and replace is harder.
Teams usually begin with a product question: which memory platform should we use? That is too early. A coding team sharing context across agents, a customer application remembering preferences, and an organization reasoning about changing relationships do not have the same architecture problem.
The useful question is: what must remain true when the current agent, model, or memory product disappears?
Choose the architecture before the product.
Answer the workload, ownership, portability, governance, and deployment questions. Get a recommendation, why-not explanations, evidence links, an exit strategy, and a five-test pilot.
Memory is not one architecture
Persistent memory covers several different jobs. The families below are the decision map used by the advisor, not a leaderboard.
Developer operational memory
Does engineering work need continuity across tools and sessions?
Coding agents need lessons, decisions, fixes, and project context across sessions.
Start with AgentMemory, GBrain, Memorix.
Application and user memory
Must a product remember people, preferences, and recurring context?
A customer-facing or internal application needs persistent user, session, or agent context.
Start with Mem0, Supermemory, Memobase, MemMachine, Honcho.
Temporal context graph
Do relationships change over time and need provenance?
The agent must answer what was true, when it was true, what superseded it, and which source produced it.
Start with Graphiti, Zep.
Enterprise knowledge memory
Is the hard problem connecting heterogeneous organizational knowledge?
Documents, entities, workflows, and domain ontologies must become connected, queryable context.
Start with Cognee, GBrain, Supermemory.
Reflective learning memory
Must the agent consolidate experience into lessons or mental models?
The agent should retain, reflect on, and improve from prior experience.
Start with Hindsight.
Stateful agent runtime
Should the runtime itself own the agent's durable state?
A long-running agent needs a runtime-managed identity, memory hierarchy, or framework-native store.
Start with Letta, LangMem, MemOS, OptMem.
Architecture first
What must remain useful when the current agent disappears?
No dedicated memory system
Are stable records and ordinary retrieval enough?
The durable facts already belong in Git, ADRs, an application database, or ordinary search.
Developer operational memory
Does engineering work need continuity across tools and sessions?
Coding agents need lessons, decisions, fixes, and project context across sessions.
Application and user memory
Must a product remember people, preferences, and recurring context?
A customer-facing or internal application needs persistent user, session, or agent context.
Temporal context graph
Do relationships change over time and need provenance?
The agent must answer what was true, when it was true, what superseded it, and which source produced it.
Enterprise knowledge memory
Is the hard problem connecting heterogeneous organizational knowledge?
Documents, entities, workflows, and domain ontologies must become connected, queryable context.
Reflective learning memory
Must the agent consolidate experience into lessons or mental models?
The agent should retain, reflect on, and improve from prior experience.
Stateful agent runtime
Should the runtime itself own the agent's durable state?
A long-running agent needs a runtime-managed identity, memory hierarchy, or framework-native store.
Canonical sovereign knowledge
Must the organization own the meaningful state independently of the memory engine?
Portability, auditability, and long-term ownership dominate automatic memory formation.
Canonical state stays yours. Derived memory may accelerate an agent, but it should not be the only copy of meaning.
Accessible decision map
Architecture families and their first evaluation candidates
Use the guided advisor for the complete adaptive path. This list exposes the same branches without relying on the visual map.
No dedicated memory system
Decisive question: Are stable records and ordinary retrieval enough?
The durable facts already belong in Git, ADRs, an application database, or ordinary search.
First systems to evaluate: Existing source of truth + search
Developer operational memory
Decisive question: Does engineering work need continuity across tools and sessions?
Coding agents need lessons, decisions, fixes, and project context across sessions.
First systems to evaluate: AgentMemory, GBrain, Memorix
Application and user memory
Decisive question: Must a product remember people, preferences, and recurring context?
A customer-facing or internal application needs persistent user, session, or agent context.
First systems to evaluate: Mem0, Supermemory, Memobase, MemMachine, Honcho
Temporal context graph
Decisive question: Do relationships change over time and need provenance?
The agent must answer what was true, when it was true, what superseded it, and which source produced it.
First systems to evaluate: Graphiti, Zep
Enterprise knowledge memory
Decisive question: Is the hard problem connecting heterogeneous organizational knowledge?
Documents, entities, workflows, and domain ontologies must become connected, queryable context.
First systems to evaluate: Cognee, GBrain, Supermemory
Reflective learning memory
Decisive question: Must the agent consolidate experience into lessons or mental models?
The agent should retain, reflect on, and improve from prior experience.
First systems to evaluate: Hindsight
Stateful agent runtime
Decisive question: Should the runtime itself own the agent's durable state?
A long-running agent needs a runtime-managed identity, memory hierarchy, or framework-native store.
First systems to evaluate: Letta, LangMem, MemOS, OptMem
Canonical sovereign knowledge
Decisive question: Must the organization own the meaningful state independently of the memory engine?
Portability, auditability, and long-term ownership dominate automatic memory formation.
First systems to evaluate: GBrain, Existing source of truth + search, Memorix
Cross-cutting rule: keep organization-owned canonical state outside the operational memory product.
Portability is four separate promises
State ownership means you possess the records. Same-system recovery means you can rebuild the same deployment. Semantic portability means the knowledge retains meaning outside the implementation. Behavioral portability means another engine can consume the state and behave equivalently.
These promises are not interchangeable. An export button may prove the first. It does not prove the other three. That is why the advisor asks which portability layer matters and turns the answer into a pilot test.
Canonical state versus operational memory
The rule that survives every branch is simple: keep canonical state outside the operational memory product. Durable decisions, business records, permissions, source documents, evaluation data, and approved policies belong in systems the organization already owns. A memory engine can extract, index, retrieve, and consolidate on top of them.
Derived memory may accelerate an agent. It should not be the only copy of meaning.
For a coding team, that means Git, ADRs, project instructions, and runbooks remain authoritative. For an application, raw interactions and business records remain authoritative. The product-specific memory layer becomes a replaceable operational surface.
Scenario decisions
The same map produces different first systems because the architecture changes:
Evaluate automatic cross-agent capture first; compare a canonical Git-oriented path when ownership or human review is the stronger requirement.
Family: Developer operational memory. First system: AgentMemory.
Evaluate a Git and Markdown canonical architecture first, with GBrain as the first system to evaluate when the evidence and requirements align.
Family: Canonical sovereign knowledge. First system: GBrain.
Start with Mem0 when a conventional add, search, update, and delete abstraction fits the application boundary.
Family: Application and user memory. First system: Mem0.
Keep lifecycle certainty visible; compare Supermemory when connectors, hybrid retrieval, and context assembly are the center of gravity.
Family: Application and user memory. First system: Mem0.
Evaluate Graphiti first when validity windows, changing relationships, and traceable source episodes are hard requirements.
Family: Temporal context graph. First system: Graphiti.
Evaluate Hindsight for consolidation and reflection; choose a runtime family only when the runtime itself must own durable state.
Family: Reflective learning memory. First system: Hindsight.
Use the LangGraph-native memory layer when the existing application store and lifecycle remain authoritative.
Family: Stateful agent runtime. First system: LangMem.
Keep the existing source of truth when a dedicated memory lifecycle adds more governance than value.
Family: No dedicated memory system. First system: no dedicated memory system.
Benchmarks are evidence, not architecture
The Agent Memory Sovereignty Bench is useful here as a method lesson: separate controlled retrieval from native product behavior, test lifecycle guarantees, and attribute each capability to the product, adapter, application, reader, or scorer that actually implements it. A benchmark score without that attribution is easy to overinterpret.
This article uses the benchmark as a methodological reference. Product claims in the advisor are dated and linked to the official source that supports them. Most recovery, governance, and behavioral portability properties remain untested. That uncertainty is part of the result.
The five-test pilot
- Representative recall. Does the right fact or record arrive with traceable evidence?
- Supersession. Can the system distinguish what is true now from what was true earlier?
- Isolation and deletion. Can scopes be separated and deleted state stay deleted?
- Recovery. Can the team destroy the deployment, rebuild it, and recover useful behavior?
- Exit. Can another implementation use the organization-owned records without pretending behavior is automatically portable?
Monday morning checklist
- Write down what must remember, what must remain canonical, and which portability layer is actually required.
- Separate hard constraints from preferences. Eliminate incompatible systems before ranking anything.
- Choose a first system to evaluate, one strong alternative, and an explicit no-system outcome.
- Run the five tests on representative data before expanding the deployment.
- Keep the sources, raw events, decisions, and recovery steps where the organization owns them.
Research snapshot
2026-08-11. Coverage is representative, not exhaustive. See the methodology and source records for evidence levels, inclusion criteria, and update instructions.
Built and researched by Harish Venugopal. Software engineer focused on AI systems, evaluation, and developer infrastructure.