EXPERIMENT_033 // SHARED.AGENT.MEMORY.GRAPH
Two mock agents, Curator and Auditor, read and extend one seeded brand-asset knowledge graph of guidelines, decisions, campaigns, and channels. Trigger their scripted queries and watch two of them render a live graph traversal beside a flat-similarity search over the identical text, so the gap between structured relationships and flat search is something you see, not something the copy just asserts.
LOADING EXPERIMENT...
You're looking at one shared knowledge graph — 22 nodes, 4 relationship types — that two mock agents both read from and write to: Curator, who maps what depends on what before anything ships, and Auditor, who checks what's safe to retire. Pick any of their five scripted questions and the graph answers by tracing real relationship edges, not by guessing from keywords. Two of those questions go further: they run the same question through a flat text-similarity search over the exact same node descriptions, side by side with the graph result, so you can see for yourself where flat search quietly misses a multi-hop dependency, and where it wrongly flags something unrelated just because the words happen to match. Add your own node at the bottom and it's instantly visible to both agents — that's the whole argument for shared over isolated memory, made concrete instead of asserted.
HOW IT WORKS
The graph substrate is a hand-authored TypeScript simulation of the node/edge model Cognee (github.com/topoteretes/cognee, Apache-2.0, v1.4.2) builds — typed nodes across 7 kinds (guideline, asset, decision, campaign, persona, channel, document), typed edges across 4 relationship types (`depends_on`, `supersedes`, `informs`, `used_in`). Cognee genuinely ships a local REST API server mode viable for this — confirmed by a toolkit eval before any code was written — but standing up a Python/Docker process purely to generate this demo's static seed data was judged real, marginal overhead for a browser-only Labs experiment. The graph model is what matters here, and it's faithful; the live instance isn't required to make the point.
Curator and Auditor never talk to each other and never merge their own private notes — they read the identical `GraphState` object. Curator asks dependency-mapping questions ("what depends on this guideline", "what does this campaign need"); Auditor asks change-impact questions ("what breaks if we retire this", "what replaced this document"). Every query is a deterministic breadth-first traversal — same graph, same question, same answer, every run. No LLM call decides what the graph contains or how a query resolves.
Two questions run twice: once as a graph traversal following only the named relationship types, once as a lexical-overlap search over the same nodes' label and summary text — a deliberately simple stand-in for flat vector/embedding search that shares its one real limitation, scoring text rather than adjacency. One comparison shows a false negative: the traversal finds a campaign two hops downstream of a guideline that flat search never surfaces, because nothing in that campaign's text mentions the guideline by name. The other shows a false positive: flat search surfaces a retired asset's active replacement purely because the two share a label, while the graph correctly shows nothing currently depends on the retired one.
The form at the bottom adds one new node connected to one existing node via one relationship type — always a valid, typed addition, never free-form text dumped into the graph. Submit it and re-run any query that traverses through the node you connected to: the addition is there immediately, because there was only ever one `GraphState`, not two agents each holding a stale copy of it.
WHAT THIS PROVES
Structured relationships answer a category of question flat similarity search cannot, no matter how good the embedding model gets: "what depends on this?" is a graph-adjacency question, not a text-similarity one, and the two comparison queries in this demo show both of the ways that gap shows up in practice — real dependents missing zero lexical overlap, and unrelated items surfaced on shared vocabulary alone. This extends "Your Agent's Memory Is a Contract, Not a Database": the contract a flat vector store can make with a caller is narrower than the one a typed graph can.
Shared memory is an architecture choice with a real trade-off, not a default any agent system gets for free. Curator and Auditor answer correctly here specifically because they were built to read one graph instead of two isolated ones — the extension action makes that concrete rather than asserted: a node either agent adds is visible to the other's very next query, with no sync step in between. "Agent Memory Architecture — Shared vs Isolated" argued this in prose; this is the same argument, clickable.