Most teams building agents give them a vector database and call it memory. That works right up until the question changes shape. Ask an agent to find a document that looks like three others and a vector store is the correct tool. Ask it to prove that no such document exists, or to explain how five separate facts connect into one answer, and similarity search runs into a wall it cannot see, because a k-nearest-neighbor lookup was never built to report an absence.
We are going to be careful about who is telling us this, because the honest version of this argument is narrower than the pitch decks make it sound. Seven talks from the same AI Engineer conference graph track converge on roughly the same claim, and four of the seven talks come from companies that sell a graph product: three from Neo4j, one from Zep. That is not a reason to discount the argument. It is a reason to weigh it correctly. The vendor talks supply mechanism and vocabulary, the shapes a context graph can take, the pillars a control plane needs. The two customer-side talks, the Gates Foundation and ZS Associates, supply the evidence: named organizations describing what happened when they tried the alternative and what happened when they replaced it. An article that discounts its own sources and still finds the argument holding up is more useful than one that counts every speaker as independent proof.
The demo that isolates the point
Stephen Chin, a Neo4j developer relations VP, built a controlled test on his own home-lab network rather than on borrowed enterprise data. He converted his infrastructure documentation, a handful of Proxmox servers on a segmented VLAN, into markdown files, then loaded the identical files into two separate stores: a vector database on one side, a graph store built on Cognee with a Neo4j backend on the other [1]. Same source data, same questions, two retrieval architectures.
He asked both agents a security question: what is exposed to the internet and running end-of-life software. The vector agent’s answer, quoted directly from the demo: “Couldn’t find specific details, excluded by policy for more precise information, yada yada yada, source it separately” [1]. Chin’s own assessment: “that’s not very helpful” [1]. The graph agent, working from the same files, traversed one hop out from a seed node and named the exact host, his daughter’s Minecraft server, reported its operating system version, and flagged it as out of date [1].
Figure 1 - Same files, two answers: Identical markdown memory loaded into a vector store and a graph store, asked the same security question. The vector agent reports it cannot find specific details. The graph agent traverses one hop and names the exact out-of-date host.
We want to be precise about what this demo does and does not show. It is a personal home-lab test by a Neo4j employee, not an audited enterprise benchmark, and Chin says as much on stage about the broader claim it illustrates: “similarity in vector space is not the same as actual relationships” [1]. Chin configured both arms of it himself, including the vector baseline that lost. What makes it worth leading with anyway is that it illustrates the structural point more cleanly than a production case study usually can. Both agents read the same words. Only one of them could walk a relationship. The vector agent had every fact it needed and still could not connect them, because connection was never something a similarity score could compute.
Figure 2 - How the graph side actually retrieves: Vector similarity still does a job here, it finds the seed node to start from. The graph then traverses outward from that seed, ranking neighbors by how related they are rather than how similar their embeddings look. Similarity finds an entry point. Traversal does the reasoning.
KEY INSIGHT: Semantic similarity cannot prove a negative. It can only report what looks like the answer, never that no answer exists. Graph traversal can walk to the edge of what is modeled and stop there, which is the only way an agent can honestly say “I checked, and it isn’t here.”
Who is actually saying this
Before going further, the honest inventory. Four of the seven source talks come from Neo4j (Zach Blumenfeld [2], Stephen Chin [1], and CEO Emil Eifrem [3]) or from Zep (Daniel Chalef [4]), both companies whose revenue depends on graphs beating vectors in exactly this argument. A fifth, Frank Coyle of UC Berkeley, is academic rather than commercial, teaching neuro-symbolic patterns rather than selling a product [5]. That leaves two named enterprises actually describing their own production systems: the Gates Foundation’s Strategic Intelligence Platform, presented by Mike Phipps [6], and ZS Associates’ pharma-commercial pipeline, presented by Subbiah Sethuraman and Abhilash Asokan [7].
Two customer accounts is a narrower evidentiary base than “roughly ten independent talks” would suggest, and we are not going to claim a count this batch does not support. Of the seven talks, two describe named enterprises building and operating a graph in production. The other five describe mechanism, vocabulary, and a validator pattern from people who are either selling the mechanism or teaching it without a commercial stake. We are going to treat the vendor talks that way for the rest of this piece: useful for the “how,” not counted as a third or fourth “who.”
Figure 3 - Weighing the sources, not just counting them: Four of the seven talks come from Neo4j or Zep and supply mechanism and vocabulary. Two come from named enterprises describing their own production systems and supply the evidence. One is an academic validator pattern with no commercial stake either way.
Three shapes, not a bigger embedding
Blumenfeld’s framing is the one the title of this piece borrows, and it earns the borrowing. His argument is not that every enterprise problem belongs in a graph. It is that most enterprise grounding problems fall into three specific, reusable shapes, and none of the three requires bulk-loading the underlying data into the graph at all [2].
The connection shape is a metadata graph over a SQL warehouse, built with Neo4j Labs’ Neocarta [8]. It ingests table and column metadata plus the join paths between them, not the row data itself, so an agent discovering how to join two tables it has never seen structured this way reads the metadata graph instead of guessing. A newer, related Neo4j offering, Virtual Graph, is in public preview as of this writing and goes a step further by translating Cypher queries directly against the warehouse with no copy of the data at all [9]. The table-of-contents shape is a deterministic containment tree over a document corpus, folders and sections linked the way an Obsidian vault links notes, letting an agent traverse the corpus “like a human flips through a book’s table of contents,” per Blumenfeld’s own analogy, instead of only pattern-matching on similarity [2]. The themes shape runs Leiden community detection over the link structure between documents, surfacing natural clusters (a braking-system cluster, a wiring-harness cluster) with zero LLM labeling cost and fully reproducible output [2].
Figure 4 - Three shapes, three different jobs: A metadata layer over structured data, a containment tree over documents, and a community-detection layer over how documents link to each other. None of the three copies the underlying data into the graph.
Blumenfeld’s own summary of why this matters lands on the same structural point Chin’s demo made live: “This is sort of like proving a negative, which can be very hard with something like semantic search, which can only match similar things, right? It can’t really find a negative example” [2]. He is explicit that this is additive, not a replacement for vector search, since most production systems that adopt these shapes eventually pair them with hybrid vector or full-text retrieval for the questions vector search is genuinely good at [2].
Three pillars, and what they buy an enterprise
Eifrem’s keynote names the same structural problem from the infrastructure side, using a bank-account-opening agent as his running example. An enterprise wiring every agent’s business logic directly to its data sources pays four repeated costs: every team rediscovers from scratch where its data lives across a hundred databases, judges on its own whether that data is trustworthy, has no way to propagate a fix across every agent touching the same source, and gets no cross-agent learning, since the wiring lives in a mix of code and prompts per agent [3].
His anticipated objection and his answer to it are both worth quoting directly. “I know what you’re all thinking: work on files, skills to the rescue. And yes and no… we’ve seen a ton of teams that try to solve this problem using just markdown files, and the summary is it is part of the solution but it is not the solution” [3]. He then relays a line he attributes to swyx, from a Latent Space podcast appearance roughly a week before this talk. No recording or transcript of that episode is on the public record, so the line is attributed here the way the evidence supports: as Eifrem’s own on-stage retelling of a claim he credits to swyx, not as a verified swyx quotation. As Eifrem tells it, swyx said, “You got to learn your databases. You cannot vibe code with just markdown files” [3].
Eifrem’s proposed fix is three pillars, and he numbers exactly three in his own closing line: “a business ontology, a technical ontology, the execution traces, taken together they solve all four of the problems” [3]. A business-facing ontology names the organization’s concepts the way people actually say them, a customer with a first name rather than a raw f_name column. A technical ontology catalogs every real data source, which of a dozen databases holds what, with the mapping from business concept to system of record described as connective tissue between the first two pillars rather than as a numbered pillar of its own. Execution traces record what an agent tried and whether it worked, feeding back into the substrate as a bottom-up trust signal, so an agent invoked tomorrow starts slightly smarter than it was today.
Figure 5 - The three pillars, in Eifrem’s own order: A business ontology, a technical ontology with a mapping to systems of record, and execution traces that feed learning back into the substrate. The mapping sits between the first two pillars rather than counting as a third.
Eifrem also namedrops the Gates Foundation, monday.com, and JPMorgan Chase as fellow speakers in the same conference’s graph track, offering their presence as evidence of traction for graph-plus-agent patterns generally [3]. No primary source describes what JPMorgan Chase actually said or built: no talk recording, no recap, no written account, only Eifrem’s single-line mention that the talk happened. A Neo4j executive saying a JPMorgan Chase talk took place is the entire extent of what is verifiable, so it is not a validator here.
What graph-as-control-plane looks like in production
ZS Associates built a four-agent pipeline to automate pharma-commercial analytics: detect a signal, find its source, attribute the driver, synthesize a recommendation. Each agent produced locally correct output. The pipeline as a whole did not. Their worked example: the system correctly detected an 18% prescription drop in a territory, correctly identified the cause, a payer had moved the drug to a lower coverage tier, and then recommended the wrong action anyway, sending more sales reps to talk to doctors, because the weight of the insurance-coverage cause never survived the handoff to the synthesis agent [7]. Every individual agent had a correct fact. No agent owned the end-to-end picture.
Sethuraman and Asokan named three root causes. An LLM was doing deterministic statistical work that belonged to a plain statistical method. Multi-agent handoffs lost the weight and context a single reasoning agent would have kept. No agent, on top of that, shared a common domain model, so each one inferred relationships from raw tables at runtime, a process the team describes as “not scalable” and prone to relationships that “did not actually exist in the data” [7].
The fix pulled deterministic work out of the agent loop entirely, consolidated judgment into one agent that owns the reasoning end to end, kept sub-agents for delegated investigation only, and replaced ad hoc table lookups with a domain knowledge graph built with pharma subject-matter experts. The line worth keeping from the talk is the one that gives this section its title: “Graph cannot be treated just as a lookup layer. It has to be treated as a control plane which the agent uses to navigate and take its next decisions” [7]. Every edge in their graph became a hypothesis the agent was permitted to test against live data. The agent did not go outside the graph’s edges.
Figure 6 - A lookup table cannot own the handoff: Four agents each got their own step right and the pipeline still recommended the wrong action, because no agent owned the end-to-end picture. Rebuilding around a domain graph as a control plane meant every hypothesis the agent could test was an edge already in the graph, not an inference it made up at runtime.
Sethuraman and Asokan report that the rebuilt system produces, in roughly 50-plus turns, output comparable to what a human analyst previously took 3 to 4 weeks to produce, in about 20 to 30 minutes [7]. That figure is self-reported by the presenting team about their own client work, with no third-party audit and no pharma client named beyond “a lot of the top pharma” companies [7]. ZS is also a services firm with its own reason to present the engagement as a success, a different incentive from a graph vendor’s but not an absent one. We are citing the figure as ZS’s own claim about its own system, not as an audited benchmark.
The Gates Foundation’s data-model moat
Mike Phipps described the Gates Foundation’s Strategic Intelligence Platform, a knowledge graph sitting over the foundation’s grant portfolio, modeling three hierarchies at once, funding lineage, org and investment management, and a people layer, then stitching them to a document layer of meetings and unstructured files through shared entities, so an agent can traverse structured and unstructured sources as one connected space [6].
Phipps stated on stage that the platform serves “about 4,000 people” and, later in the same talk, “4,000 different employees of the foundation” [6]. We checked that figure against the foundation’s own public fact sheet, which lists 2,215 current foundation employees, roughly half of Phipps’s stated number [10]. That is a real, material gap, not a rounding difference, and we are not going to smooth it into the article as an established fact. The gap may come down to whether contractors or grantee-embedded staff are counted, which is plausible but unconfirmed.
The load-bearing line from the talk, and the one worth reproducing precisely, is Phipps’s own framing of what the graph is actually protecting: “what’s defensible… was our understanding of our internal processes, the tacit knowledge you need to run successful AI… no matter how good models get” [6]. He is explicit that the chat interface and even the agent-interaction layer were not considered the moat. Only the modeled tacit knowledge was.
Figure 7 - The moat is the model, not the interface: Three connected hierarchies plus an unstructured document layer, queryable as one graph. The employee figure on stage was roughly double the foundation’s own published headcount, which is why it is marked here as Phipps’s stated number rather than a verified fact.
What makes Phipps’s methodology worth stealing independent of any number is how the platform is evaluated. For each target question, a data owner co-writes a graph query in advance. At evaluation time that query runs live against the current graph as ground truth, and the agent’s answer is scored against it on whether it matches on the first try and whether it returns the same answer when asked repeatedly [6]. That is a reusable eval pattern for any client claiming their agent is grounded: write the query a human would trust, run it as the answer key, and check the agent against it every time the underlying data changes.
Tracing a fact back to its source
Daniel Chalef, from Zep, opened with a problem that neither the shape talks nor the control-plane talks addressed directly: once an LLM has synthesized a fact from several sources, the paper trail behind it is gone unless the graph is designed to keep it [4]. His framing question: “when an agent retrieves context, can we point to the exact source and its veracity? For complex agent applications, the answer is often no” [4].
A single source-ID column, the obvious fix, fails for three reasons Chalef names directly: an LLM synthesizing from several sources produces facts with more than one parent, entity merges (two records for the same person) need to preserve both sets of source links rather than picking one, and facts mutate over time in ways an append-only log manages poorly at scale [4]. His fix models provenance as ordinary graph structure. Episodes are the raw ingested source data. Entities are extracted from episodes. Facts are edges between entities, hydrated from the underlying triple. Tracing a fact to its source becomes a graph walk instead of a separate audit subsystem [4].
Chalef adds a second mechanism on top of raw lineage: tag-based verification propagation. An episode from a verified source, an electronic health record in his example, is tagged at ingestion, and every fact derived from it inherits the tag. Whether a multi-source fact counts as verified is a policy decision the graph makes queryable rather than one it enforces by default: a life-or-death fact like a drug allergy should require every parent source to carry the tag, while a fact like consent-on-file should require the opposite, blocking if any parent lacks it [4]. This same structure solves right-to-be-forgotten requests correctly: a fact is deleted only if none of its remaining source episodes still support it, which is a meaningfully different rule from cascading a deletion to everything a source ever touched [4]. Graphiti, the open-source project implementing this pattern (Zep, Apache-2.0 license), is the concrete implementation behind the talk [11].
Figure 8 - Lineage has to be built into the structure, not logged after the fact: Raw episodes produce entities, and facts are edges between them. A verification tag applied once at ingestion propagates to every fact derived downstream, and a fact survives deletion only if at least one supporting episode still exists.
Chalef’s argument against file-based memory here is direct, not implied: “markdown suffers from provenance. File-based memory starts to break down with provenance. It’s very difficult when you mutate lines in a file to understand the lineage or the provenance of why those changes occurred” [4]. That claim is scoped correctly to multi-user, multi-source, regulated deployments, where “why do I have this fact, and can I trust it” has to be answerable as a query. It says nothing about whether files are the wrong choice for a single operator’s own working memory, which is a different problem with a different right answer.
KEY INSIGHT: If an agent cannot say where a fact came from, it cannot say whether the fact should be trusted. That is not a nice-to-have for regulated data. It is the entire difference between an audit and a guess dressed up as an answer.
Ontologies as the agent’s guardrail
Frank Coyle, at UC Berkeley, brought the same structural pattern to a narrower, harder-edged problem: not what an agent can find, but whether an action it already decided to take is allowed to happen. His framing pairs a probabilistic LLM, prone to hallucination by design, with a symbolic reasoner built on a formal ontology (RDFS and OWL constraints) that checks a tool call’s result against the domain model before the agent loop trusts it and moves on [5]. This is not a model reviewing another model’s output. A functional-property violation or a disjoint-property collision either occurred in the structured result or it did not, no probability attached.
Coyle’s own summary of the split is the line worth keeping: “Pydantic at the door, ontology at the ledger” [5]. Type validation at the door checks that a tool call’s parameters have the right shape going in. The ontology at the ledger checks that the result is semantically valid against the domain model coming out, before anything downstream acts on it. He calls the combination neuro-symbolic AI, and he is explicit about its limit as well as its strength: it catches category confusion, cardinality violations, and enum violations cheaply and deterministically, but it cannot catch anything that is not expressible as a formal constraint, which is exactly the contextual judgment call a model-based reviewer is built to handle instead [5].
The counterexample: when files beat vectors
One company routinely grouped with the graph adopters does not belong on that list, and its own retrospective is the reason why. monday.com’s retrospective, published on the AWS Machine Learning Blog, describes trying vector retrieval for cross-session agent memory and finding it “worked badly” [12]. What worked instead was a plain markdown file, MEMORY.md, plus a daily journal, stored on shared EFS storage. Their own words: “We over-invested in vector stores before realizing MEMORY.md on EFS was always the right answer” [12]. That is a real, useful data point. It argues that vector-only retrieval keeps disappointing production teams. It says nothing about graphs, because monday.com never names a graph database or graph structure anywhere in that post, and a separate monday.com conference talk from the same event describes a two-engine architecture over structured data without naming a graph either [13].
Figure 9 - A real finding, misfiled as a graph story: monday.com’s own production retrospective argues files beat vectors for session memory. Neither of monday.com’s two public sources names a graph anywhere, which is why it belongs in the anti-vector-only argument and nowhere near the list of named graph adopters.
That is why monday.com does not belong on a list of named graph-adopting enterprises. It belongs here instead, as corroboration for the narrower point: teams that reach for a vector store as the default answer to cross-session agent memory keep finding out the hard way that similarity is not the guarantee they needed. Which store actually solves the problem still depends entirely on which kind of memory is being solved for.
Choosing the architecture before you scale
None of the patterns above argue for ripping out a vector store. Blumenfeld says as much directly, calling the graph shapes additive rather than a replacement, and every one of the production systems described here still pairs graph traversal with vector or full-text search for the questions similarity is genuinely good at [2]. The actual decision is not vector versus graph. It is matching the storage shape to the kind of memory being solved, a distinction two companion pieces on this site have already walked in depth: The Context Engineering Stack covers the three-layer compression, retrieval, and decision-memory model this piece leans on without repeating, and The Production RAG Stack Nobody Ships Complete covers the evidence-and-freshness layer that Chalef’s provenance pattern extends. This piece adds the enterprise-scale case for the graph substrate itself, and cites those two rather than re-teaching them.
That distinction is exactly the shape of a scoped audit rather than a rebuild. Session continuity, what an agent needs to remember inside or across a single working session, is usually a files-or-vector problem, and monday.com’s own retrospective above is the evidence for that half. Domain knowledge, the tacit, procedural understanding of how a business actually runs, is the piece the Gates Foundation and ZS Associates both ended up modeling as a graph, because nothing else let an agent traverse how one fact depends on another. Provenance and compliance, whether an answer can be traced back to a source with a stated confidence, is the piece Chalef argues collapses in a flat file store the moment the data is regulated.
Figure 10 - Score the architecture per memory type, not as one decision: Session continuity, domain knowledge, and provenance each have a different right answer. Scoring a client’s context architecture against all three separately is the audit; picking one storage technology for everything is the mistake this whole piece has been describing.
We already argue, in our data-model consulting work, that a client’s data model is a defensible moat regardless of how good the underlying models get. What the two customer talks here add is a scoped way to test that claim before recommending a rebuild: an audit that scores an agent’s existing context architecture against the three memory types above, names where the client’s actual tacit-knowledge moat lives, and shows whether any of it is modeled anywhere an agent can currently reach it. This is a review, not a build commitment. It hands back a map of what is unmodeled, what is modeled but disconnected, and what is connected but missing the authorization trimming a regulated deployment needs, and the client decides from there whether the gap is worth closing.
Conclusion
The strongest version of this argument is also the narrowest one. Two named enterprises, not four, describe replacing an ad hoc or vector-only approach with a graph because their agents needed to answer questions vector similarity structurally cannot: prove a negative, walk a hypothesis space bounded by real business relationships, or trace a synthesized fact back to a source worth trusting. Four vendor talks supply the shapes and the vocabulary for how to build that graph without a full data migration, and one academic talk supplies a validator pattern for checking an agent’s actions against it deterministically. None of that requires discarding a vector store. It requires knowing which kind of memory problem you actually have before reaching for the same tool for all of them.
That is the honest shape of the convergence. Not five companies saying the same thing at the same conference, but two companies who tried it in production, four talks from the two vendors with a reason to want you to believe it, and a demo clean enough to show exactly where the line sits between what similarity can answer and what only a traversal can.
References
[1] S. Chin, “CrabRAG: Why Automated Assistants Need Graph Memory, Not More Tokens,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=Q0VkgCyNVUg
[2] Z. Blumenfeld, “AI on Your Lakehouse: Context Comes in Shapes, Not Queries,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=kRkcNOsRyYg
[3] E. Eifrem, “Thinner Agents on a Smarter Substrate: The Ontology-Based Semantic Layer,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=VGN22pPpb-8
[4] D. Chalef, “Citation Needed: Provenance for LLM-Built Knowledge Graphs,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=H7puB0RwJMM
[5] F. Coyle, “Why Agentic Systems Need Ontologies,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=Sir59K8ZDPU
[6] M. Phipps, “Your Moat Is Your Data Model,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=jt1Pbr_n6oU
[7] S. Sethuraman and A. Asokan, “Why We Killed Our Multi-Agent Pipeline,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=u6jJcIFDLE4
[8] Neo4j Labs, “Neocarta,” GitHub repository. https://github.com/neo4j-labs/neocarta
[9] Neo4j, “Neo4j Virtual Graph Is Now in Public Preview,” Neo4j Graph Intelligence Platform Blog. https://neo4j.com/blog/auradb/neo4j-virtual-graph-is-now-in-public-preview/
[10] Gates Foundation, “Foundation Fact Sheet.” https://www.gatesfoundation.org/about/foundation-fact-sheet
[11] Zep (getzep), “Graphiti,” GitHub repository. https://github.com/getzep/graphiti
[12] Amazon Web Services, “AI Teammates: How monday.com Runs Production AI Agents on Amazon Bedrock,” AWS Machine Learning Blog, Jul. 22, 2026. https://aws.amazon.com/blogs/machine-learning/ai-teammates-how-monday-com-runs-production-ai-agents-on-amazon-bedrock/
[13] O. Bruchim and T. Ast, “From Systems of Record to Systems of Context,” AI Engineer conference, Jul. 2026. https://www.youtube.com/watch?v=Btk8wDUVs74
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.