NODES AI 2026 - Multi-Agent Shared Graph Memory: Building Collective Knowledge for Agents

This talk discusses the challenges faced by multi-agent systems related to memory management and proposes a solution leveraging shared graph memory. The speaker identifies issues such as duplicated discovery, conflicting beliefs, and context collapse that arise when agents operate independently without shared memory. By introducing a design pattern based on Neo4j and a vector database like Quadrant, the speaker outlines an architecture consisting of three layers: a graph layer for world modeling, a vector layer for content storage, and a working memory layer for real-time processing. The session emphasizes the importance of persistent knowledge accumulation, structured question handling, and conflict management in agent collaboration. Through a concrete example involving four agents working on incident debugging, the speaker illustrates how this approach creates a single shared representation of reality, thereby enhancing efficiency and accuracy in agent interactions.

Amazing to be a part of Neo4j Nodes 2026. Excited to get started. The title of my talk is multi-agent shared graph memory building collective agents collective knowledge for agents. So I would like to get started with something simple. A major problem. Uh most agentic systems have a memory issue. It's not a capability problem, not a reasoning problem. It's a memory problem. Every agent you have ever deployed

starts fresh. It figures out the same things the last run figured out. It throws all of that away when it is done. And in a multi-agent system that is not just inefficient, it compounds very fast. So today I want to show you a design pattern that fixes this. Shared graph memory for multi-agent systems built on Neo4j and any vector database, but in this case I have used

Quadrant. And I'm going to make it completely concrete with a working example. So let's get started. So three things go wrong when agents do not share memory. The first is duplicated discovery. You have two agents working different parts of the same problem. They both find the same entity. They write it in different formats with different confidence scores from different sources. Now your downstream logic has to reconcile

them. At small scale that is annoying. At production scale it is a reliability The second is conflicting beliefs. Agent A determines a service is healthy. Agent B, running a different sub-graph of the same workflow, flags it as degraded. So, neither knows about the other. So, no system-level truth exists. The right answer depends entirely on which agent you happen to ask last. The third is context collapse. Long-running

tasks hit context window limits. So, the agent summarizes, compresses, and loses precision. So, the next agent in the chain inherits inherits a lossy version of reality, and it kind of makes decisions on that. So, every hop degrades the signal. So, the root cause across all three is the same, I would say. Agents are reasoning about a shared world, but they have no shared representation of it. So,

before getting into the architecture, I wanted to address something directly, because I know this like because generally audience use memory like Redis or MongoDB for building agents. I feel that these are not the wrong tools. It is right. These are the right tools for the like hot layer, sub-millisecond reads for like active task state. Pub/sub and streams for agent-to-agent coordination, TTL and eviction for automatically like explay

expiring stale memories. Semantic caching for cuts redundant LLM calls by like about I would say 70 to 90%. 43% of the developers use Redis for agent memory right now, and there are definitely good reasons for that. And MongoDB is also solid for document storage, logging agent outputs, flexible schema work. So, it definitely has its place. But, here is what neither of them gives you, native relationship traversal,

the ability to ask a multi-hop question in a single query, persistent accumulation of knowledge across like hundreds of agent runs, conflict handling that preserves both sides of a disagreement, full provenance on every assertion any agent has ever made. So, that is what graphs give you. These are not competing tools. They just solve uh I would say different layers of the same So, a problem a production system

often uses more than So, this is a specific architecture that I propose. The architecture has three layers and it helps to be precise about what each one does. So, the layer one is the graph layer. This is Neo4j. So, this is like the world model. It stores entities, relationships, provenance, confidence scores, and the task state. Every agent reads and writes here. When you want to know what

exists, how things connect, and what happened in what order, this is exactly where you ask. And layer two is the vector layer. In this case, I have a chosen Quadrant. So, this is the content store. It holds the full text attached to each graph nodes or let's say graph triplets. Incident descriptions, research notes, resolution summaries, things that are too long and too unstructured to live as node

properties. So, the important thing about how Quadrant is used here is that it is not for discovery. It is for like let's say enrichment. But, I'll come back to that. The third layer is the working memory. So, this is actually the in-context window. This is what the agent is actively thinking with right now. For like for this run, this is this specific current run. It is assembled

at run start and discovered when the run ends. I want to be very precise about this because it confuses at times. So, we'll start with the working memory. I would like to give an analogy. The context window is not basically the memory, it is a workspace. So, think of it exactly like RAM on a computer. Let's say Neo4j and Quadrant are the hard disk. Everything lives there

permanently. The context window is RAM, fast, immediately accessible, gone when the process ends. So, when a run starts, the agent has an empty context. The first thing that happens is hydration. A graph query pulls the relevant subgraph, and those node IDs go to Quadrant. Quadrant returns the associated text content for exactly these nodes, or the triplets, I would say. The triplets are basically the nodes and their

associated edges in like subject, predicate, and object form. So, that assembled package goes into the context window. The agent reasons, acts, and then before the run ends, everything worth keeping gets written back to So, the context window here is not memory, it is just the workspace. Here, Neo4j is what I propose as the memory. And here is the compounding value of this design. The graph is what

exactly makes the next agent smarter than this one. So, every run deposits knowledge. Every future run actually inherits from So, I would like to cover on why exactly Neo4j goes first. This is the part of the architecture that I think is the most commonly misunderstood. So, I want to be direct. Agents basically do not ask vague questions. So, they ask structured ones. Like, give me all tasks

that depend on this specific task. Or like, uh show me every entity this agent has discovered. Or which incidents are unresolved as of today. So, these are structured questions. Graph retrieval handles them precisely and immediately. So, Neo4j goes first because it filters. It traverses the entire knowledge graph and returns the exact nodes and relationships relevant to this agent's current step. Those node IDs then become the filter

passed to Quadrant. So, Quadrant doesn't search the entire corpus. It fetches the full context full text context for exactly the nodes Neo4j already identified as relevant. That's it. Nothing more. Quadrant is basically not here for discovery. It is for enrichment. So, this matters because I would say it means your agent's context window is not filled with the let's say top case semantically similar chunks from a giant

corpus. Uh but, it is filled with precisely the content attached to the entities your graph already determined that were So, that's fundamentally different and a more reliable context I would call. From this, I would like to share an example. This has four agents and one graph, one shared graph. The researcher and planner are the knowledge agents. They primarily write. They discover entities, infer relationships, assert facts. Their

rights are claims about the world. And the executor and critic are action agents. They primarily read and write back observations. They query the graph before acting, execute, then they write back what happened, like what succeeded, what failed, and what changed. So, all the four agents are reading from and writing to the same Neo4j instance. That is the shared When the researcher writes a node, the planner can

immediately traverse to it. When the executor writes a resolution, the critic can query it. There is just one version of the world and it lives in the graph. So, I would like to make this concrete with an example of an incident debugging system. So, let's assume a service goes down. Three agents work the same incident. So, let's say the researcher starts. It queries the graph for known

issues related to this service, and then it pulls the relevant context from quadrant, investigates, and identifies a root cause. It writes an entity node type database timeout, confidence uh let's say 90% source researcher one. So, that is now in the graph. Then, the executor agent picks up the task. It queries the graph, sees the researcher's entity, hydrates its context with the associated incident history. It attempts a

fix, then restarts the connection pool. So, it writes a resolution node linking back to the entity. That's it. Done. And let's consider the third agent now, the critique. Uh the critique runs, it queries the same incident, it reads the researcher's entity, reads the executor's resolution, and then reads the full context from quadrant. Uh and then it disagrees. It believes the root cause is a misconfigured timeout, not

a database issue. So, it does not override the researcher's entity. It writes a contradicts edge with a confidence of 85% raised by critique one and timestamp as the current time. So, both beliefs are now in the graph. The contradiction is a relationship. Nothing is basically lost. So, the next agent that runs on this incident may be another critique, maybe even a HITL or a human-in-the-loop trigger. So,

it starts with the full picture. It sees both assertions, both confidence scores, the full provenance chain. It resolves the dispute and marks it closed. So, basically, we don't have any duplication, no amnesia, or any like starting from zero in this case. So, the key idea is this. Um agents do not basically agree by overriding, they agree by actually accumulating evidence. So, let's consider this graph schema. It

kind of supports everything I just described. Five node types: task, agent, entity, incident, resolution, and six relationship types connecting them. I want to say something about this that I think is more, you know, useful than explaining each node individually. This is not just a schema, it's kind of a minimal ontology for each agent collaboration. And an ontology is nothing but a template, a standard template that defines

how exactly the graph should be, like what all types of nodes and edges it can have. So, everything an agent does reduces to four things: a task it was given, an entity discovered, and an action it took, and the final outcome it produced. So, if you can express your domain in those four concepts, you can use the schema as a starting point. Lock the taxonomy, extend the

properties like as freely as you want to. But, do not let the agents invent new labels. Uh also, I'll come back to this soon, and like tell you why exactly. Now, I would like to cover about conflict handling. So, if you build this system, you will eventually have two agents that disagree same fact. Here is exactly how the graph handles it. Let's say agent one writes an

entity. Agent two reads it, and then disagrees. Instead of overriding, agent two writes a contradicts edge pointing from its new entity to the existing one. And that edge carries the reason for the disagreement, the confidence score, the agent ID, and a timestamp. Now, both versions exist in the graph. The contradiction is a queryable Then, the critique agent can run a query. Like, let's say, show me all

unresolved contradictions ordered by confidence gap. Then it evaluates, resolves, and marks the winner. Or it escalates it to a human reviewer. Basically, even in this nothing is lost. Every assertion is preserved. Every dispute has a record. So, the graph never loses information. assertion, every challenge, or even like every resolution is actually a query fact with its own timestamp and the source. So, this is the full agent

loop. The loop has four steps and they're always in this order. First one is hydrate. The agent starts with an empty context. It queries Neo4j for the relevant subgraph, takes those node IDs to the vector database, assembles the result into a context window. Next one is reason. The agent now has structured graph context plus the associated text. So, it forms a plan. Next one is act. This

one executes, observes outcomes, and collects new facts. The final thing is writing back. Before the run ends, everything worth keeping is written back to Neo4j. New entities, new relationships, updated confidence scores, provenance, chain to the agent ID, everything. So, basically this loop repeats. The next agent hydrates from a graph that is richer than the one this agent started from. So, this is not stateless execution, but this

is cumulative reasoning. The graph is the institutional memory of the entire system. So, one thing I would like to say, three things that might go wrong. If you built this system, you will hit probably these three problems. Uh the first one is schema sprawl. Agents will invent new labels and relationship types if you let them. Like after 50 runs, the graph has no consistent structure and traversal

can actually become unreliable. So, the fix is to like enforce schema at right time. Any right against an unrecognized label fails loudly and immediately. So, this is a major constraint you add from day one. So, it's it cannot be a cleanup job that you can do later. The second one that thing second thing that could go wrong is stale nodes. The graph accumulates assertions indefinitely. Like old

confidence scores from two months ago will mislead every agent that follows unless you manage their life cycle. Let's say add valid until timestamps from the beginning. Or run a periodic process that marks expired assertions as, you know, superseded. one suggestion, though, never delete, just preserve the provenance, but mark clearly what is no longer current. The third issue might be over querying. Agents that hit Neo4j on like

every micro decision compound latency multi-step task. The fix is pretty straightforward. hydrate once at run start, pull everything relevant into the context window up front. One query per run. So, not one per action. So, here's my closing point or conclusion. If your agents do not share memory, you do not have a system. Basically, you will have parallel guesses. So, the pattern I have described today gives you

three things that individual agents with private memory cannot actually give. A single shared world model that every agent reads from and writes to. Persistent accumulation of knowledge across every run the system has ever completed. And a conflict model that treats disagreement as data rather than an error to be silently overwritten. I would suggest and encourage you all to pick one workflow in your organization where multiple agents

currently operate independently. Model the shared world state as a graph. So, that is enough to see how the pattern works. uh one more thing I wanted to mention, only in this specific case I have specified quadrant. You can use any other vector store as you prefer. So, that's the whole thing. If you have any questions, I'm ready to answer. Thank you.