# AI Memory on Memgraph: Persistent Context Across Session, Team and Organization > Source: > Published: 2026-10-29 19:36:57+00:00 [Back to blog](https://memgraph.com/blog) # AI Memory on Memgraph: Persistent Context Across Session, Team and Organizationh More workflows now involve directing agents through work that people previously did directly. Software 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. But 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. The problem is that the context often remains inside the session or the harness that produced it. You 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. The 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. So 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. [AI memory](https://memgraph.com/ai-memory) changes that arrangement. Instead 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. ## The Memory Should Survive the Agent That Created It Sessions from different agent harnesses can feed the same underlying memory store. A later session, including one opened in another harness, can recall from it. Work can begin in Claude Code and continue in Codex without requiring you to manually carry the working context across. The same architecture can also connect through agent SDKs, so the memory layer is not limited to an individual coding tool. The agent uses the memory. It does not own it. That 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. ## A Session Log Is Not a Memory Moving memory outside the agent harness creates another problem because agents produce a lot of activity. A 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. In the example behind Memgraph Context Graph, one session generates **214 events**. The system also creates three memories that give the session useful structure: - the failure came from the shared token cache - the `fresh_token_cache` fixture fixed it - Ana owns `auth-service` Those three memories do not replace the 214 events. They make the underlying record easier to navigate. A later agent can retrieve a relevant memory and follow it back to the session, entities, actions, or other records that contain the fuller context. The raw history preserves what happened. Memory gives the system a way to find and navigate the parts of that history that matter later. ## Memory Adds Structure to the Raw Session Record Memgraph Context Graph keeps the raw session record and the memory structure around it connected. While 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. The flow looks roughly like this: Reconciliation happens outside the agent's active path, so the memory pipeline does not have to process every tool call while the agent is working. The 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. That 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. Keeping memory outside the agent also makes the data boundary clear. Running 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. The session data, extracted entities, and memories live in Memgraph, where you control the deployment and can inspect the underlying graph directly. ## Memory Is More Useful When the Relationships Survive Too A remembered string such as `shared token cache` can help. The surrounding structure gives it more context: Memgraph stores the memories, entities, sessions, actions, and relationships as connected data. A 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. As 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. ## The Next Session Gets the Context It Needs Two weeks after the original debugging session, you ask: CI is red on `test_login` again. Any idea why? The relevant context is already in the memory graph: It'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. The agent can start from those memories and, when needed, follow them back into the underlying session data. The 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. ## Shared Memory Adds Identity to Retrieval Persistent context across sessions is the first step. Once several people and agents contribute to the same memory, the retrieval problem changes. The 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? A shared memory graph may contain engineering decisions, ownership information, workflows, incidents, customer data, or other domain-specific context accumulated across many sessions. The 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. [Memgraph Enterprise](https://memgraph.com/enterprise) adds database controls for shared deployments, including role- and label-based access control, multi-tenancy, and auditing. ## Memgraph Context Graph: One Working Way to Build AI Memory Memgraph Context Graph is part of the Memgraph AI Toolkit. It provides a working architecture for AI memory without prescribing what every memory system should look like. You 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. The underlying data remains accessible with Cypher. For 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. ## Install It in Your Agent Harness Context Graph is designed to be easy to try: The 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. Context Graph stores the agent's session data, memories, entities, actions, and relationships as connected data in Memgraph. The 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. What stays under your control is the persistent memory layer and the graph behind it. ## See the Workflow Live on October 29 On October 29, [Ante Javor](https://hr.linkedin.com/in/antejavor), our Engineer, hosts a Memgraph Community Call. ### Build Your Own AI Memory on Memgraph The 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. Ante also demonstrate context moving between agent sessions rather than remaining inside one harness. [Save your seat: Build Your Own AI Memory on Memgraph Community Call](https://www.crowdcast.io/c/build-your-own-ai-memory-on-memgraph) Memgraph 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. [View Memgraph Context Graph on GitHub](https://github.com/memgraph/ai-toolkit/tree/main/context-graph)