{"slug": "ai-memory-on-memgraph-persistent-context-across-session-team-and-organization", "title": "AI Memory on Memgraph: Persistent Context Across Session, Team and Organization", "summary": "Memgraph introduced AI Memory, a persistent context layer built on its Context Graph that lets agents from different harnesses, such as Claude Code and Codex, share and recall context outside any single session. In the example behind Memgraph Context Graph, one session generates 214 events, which the system condenses into three structured memories — that the failure came from the shared token cache, that the fresh_token_cache fixture fixed it, and that Ana owns auth-service — while keeping them linked to the raw activity record. The approach addresses the handoff problem where reasoning, tried approaches and decisions stay trapped inside the session that produced them, forcing users to act as the bridge between tools.", "body_md": "[Back to blog](https://memgraph.com/blog)\n\n# AI Memory on Memgraph: Persistent Context Across Session, Team and Organizationh\n\nMore workflows now involve directing agents through work that people previously did directly.\n\nSoftware development makes the shift easy to see. A developer who once spent a morning writing and debugging an implementation can now spend that time directing Claude Code, reviewing what it produces, correcting its approach, and asking it to test the result.\n\nBut the change is not limited to software development. Agents are increasingly involved in research, experiments, tests, presentations, design work, and other tasks where useful context accumulates while the work is being done.\n\nThe problem is that the context often remains inside the session or the harness that produced it.\n\nYou can spend a morning working in Claude Code, then open Codex later to review what you have been working on. The repository survives the handoff. The reasoning behind the changes, approaches already tried, facts uncovered along the way, and decisions made during the first session often do not.\n\nThe same problem applies outside a codebase. Source code at least has version control. The reasoning behind an experiment, the assumptions behind an analysis, or the context behind a design decision may be much harder for the next agent to reconstruct.\n\nSo you become the bridge between tools, copying context from one session to another or asking the next agent to rediscover what the previous one already learned.\n\n[AI memory](https://memgraph.com/ai-memory) changes that arrangement.\n\nInstead of tying useful context to one session or one agent harness, the memory can live outside both. Agents can contribute to a shared store and recall from it later.\n\n## The Memory Should Survive the Agent That Created It\n\nSessions from different agent harnesses can feed the same underlying memory store. A later session, including one opened in another harness, can recall from it.\n\nWork can begin in Claude Code and continue in Codex without requiring you to manually carry the working context across.\n\nThe same architecture can also connect through agent SDKs, so the memory layer is not limited to an individual coding tool.\n\nThe agent uses the memory. It does not own it.\n\nThat separation becomes more useful as workflows spread across models, harnesses, and custom agents. The application around the agent can change without taking the accumulated context with it.\n\n## A Session Log Is Not a Memory\n\nMoving memory outside the agent harness creates another problem because agents produce a lot of activity.\n\nA session can contain file reads, shell commands, edits, messages, tool calls, skill usage, intermediate hypotheses, corrections, and failed approaches. That raw record can remain valuable long after the session ends, especially as models and retrieval improve.\n\nIn the example behind Memgraph Context Graph, one session generates **214 events**. The system also creates three memories that give the session useful structure:\n\n- the failure came from the shared token cache\n- the `fresh_token_cache` fixture fixed it\n- Ana owns `auth-service`\n\nThose three memories do not replace the 214 events. They make the underlying record easier to navigate.\n\nA later agent can retrieve a relevant memory and follow it back to the session, entities, actions, or other records that contain the fuller context.\n\nThe raw history preserves what happened. Memory gives the system a way to find and navigate the parts of that history that matter later.\n\n## Memory Adds Structure to the Raw Session Record\n\nMemgraph Context Graph keeps the raw session record and the memory structure around it connected.\n\nWhile an agent works, Context Graph collects its activity as session data in Memgraph. After the session, reconciliation adds structure around that record by identifying useful memories, entities, and relationships while keeping them connected to the underlying activity.\n\nThe flow looks roughly like this:\n\nReconciliation happens outside the agent's active path, so the memory pipeline does not have to process every tool call while the agent is working.\n\nThe raw record remains available. Memory adds structure and pointers around it instead of forcing the system to decide in advance which details will matter forever.\n\nThat gives later agents two levels of context: a compact memory that is easy to find and the underlying session data when they need the fuller story.\n\nKeeping memory outside the agent also makes the data boundary clear.\n\nRunning memory on infrastructure you control does not mean every component of the AI stack has to run locally. Your agent harness continues to call its existing model provider. Memgraph Context Graph does not add another external LLM call for entity extraction: reconciliation uses GLiNER, a small model that runs locally.\n\nThe session data, extracted entities, and memories live in Memgraph, where you control the deployment and can inspect the underlying graph directly.\n\n## Memory Is More Useful When the Relationships Survive Too\n\nA remembered string such as `shared token cache` can help.\n\nThe surrounding structure gives it more context:\n\nMemgraph stores the memories, entities, sessions, actions, and relationships as connected data.\n\nA memory can therefore remain linked to the session that produced it, the system it concerns, the people around it, and the underlying records that explain what happened.\n\nAs the memory grows, those relationships give later agents more than a matching piece of text. A question may need one fact, its source, and the entities connected to it rather than an entire historical session.\n\n## The Next Session Gets the Context It Needs\n\nTwo weeks after the original debugging session, you ask:\n\nCI is red on `test_login` again. Any idea why?\n\nThe relevant context is already in the memory graph:\n\nIt's the shared token cache in `auth-service` again. Last time the `fresh_token_cache` fixture fixed it. Ana owns `auth-service` if the TTL needs to change.\n\nThe agent can start from those memories and, when needed, follow them back into the underlying session data.\n\nThe previous session has become context for the current one. Because that context lives outside the harness, the new session does not have to use the same tool that created it.\n\n## Shared Memory Adds Identity to Retrieval\n\nPersistent context across sessions is the first step. Once several people and agents contribute to the same memory, the retrieval problem changes.\n\nThe system now has to answer two questions: which context is relevant, and which of that context is the person behind the agent allowed to access?\n\nA shared memory graph may contain engineering decisions, ownership information, workflows, incidents, customer data, or other domain-specific context accumulated across many sessions.\n\nThe underlying graph can evolve with that domain. Teams can change what Context Graph collects, adapt the memory ontology, and add connectors for the agent environments they use.\n\n[Memgraph Enterprise](https://memgraph.com/enterprise) adds database controls for shared deployments, including role- and label-based access control, multi-tenancy, and auditing.\n\n## Memgraph Context Graph: One Working Way to Build AI Memory\n\nMemgraph Context Graph is part of the Memgraph AI Toolkit.\n\nIt provides a working architecture for AI memory without prescribing what every memory system should look like.\n\nYou can inspect it, change what gets collected in the graph, adapt the memory ontology, replace parts of the pipeline, or build a connector for another agent harness or SDK.\n\nThe underlying data remains accessible with Cypher.\n\nFor teams already using higher-level memory tooling, Memgraph can also sit underneath that layer as the graph database. Context Graph is one implementation of the AI Memory workload. Memgraph is the persistent graph infrastructure underneath it.\n\n## Install It in Your Agent Harness\n\nContext Graph is designed to be easy to try:\n\nThe installer sets up [Memgraph Context Graph](https://memgraph.com/docs/ai-ecosystem/ai-memory/get-started) and launches the configuration needed to connect an agent harness to a new or existing Memgraph instance.\n\nContext Graph stores the agent's session data, memories, entities, actions, and relationships as connected data in Memgraph.\n\nThe agent harness continues to use its existing model provider. Running Memgraph locally does not make the entire AI workflow local, and model calls may still send context to that provider.\n\nWhat stays under your control is the persistent memory layer and the graph behind it.\n\n## See the Workflow Live on October 29\n\nOn October 29, [Ante Javor](https://hr.linkedin.com/in/antejavor), our Engineer, hosts a Memgraph Community Call.\n\n### Build Your Own AI Memory on Memgraph\n\nThe session covers why AI memory matters, how Memgraph Context Graph works, what developers can change, and how an individual memory setup can grow into shared memory for a team.\n\nAnte also demonstrate context moving between agent sessions rather than remaining inside one harness.\n\n[Save your seat: Build Your Own AI Memory on Memgraph Community Call](https://www.crowdcast.io/c/build-your-own-ai-memory-on-memgraph)\n\nMemgraph Context Graph provides one working implementation of AI memory: it keeps the raw activity, adds structure around it, and lets later agents find their way back to the context they need.\n\n[View Memgraph Context Graph on GitHub](https://github.com/memgraph/ai-toolkit/tree/main/context-graph)", "url": "https://wpnews.pro/news/ai-memory-on-memgraph-persistent-context-across-session-team-and-organization", "canonical_source": "https://memgraph.com/blog/ai-memory-persistent-context", "published_at": "2026-10-29 19:36:57+00:00", "updated_at": "2026-10-29 19:46:49.310290+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "artificial-intelligence"], "entities": ["Memgraph", "Memgraph Context Graph", "AI Memory", "Claude Code", "Codex", "Ana"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-memory-on-memgraph-persistent-context-across-session-team-and-organization", "markdown": "https://wpnews.pro/news/ai-memory-on-memgraph-persistent-context-across-session-team-and-organization.md", "text": "https://wpnews.pro/news/ai-memory-on-memgraph-persistent-context-across-session-team-and-organization.txt", "jsonld": "https://wpnews.pro/news/ai-memory-on-memgraph-persistent-context-across-session-team-and-organization.jsonld"}}