Philip Rathle on why AI agents keep reaching for a knowledge graph

Most people who know Neo4j think of it as a graph database, and CTO Philip Rathle says that's fair, as far as it goes. But it's not where the business is anymore. More than 70% of Neo4j's new business last quarter was Neo4j used as an AI knowledge layer.

At the AI Engineer World's Fair in San Francisco, WorkOS CEO Michael Grinich sat down with Rathle to talk about what a graph company looks like once agents become the primary consumer of its data. Both companies predate the current AI wave, a point Grinich raised early, and it shows in where the conversation went: infrastructure problems, not model problems.

‍

The smartest person you know, with none of your data

Grinich opened with an analogy he says he keeps hearing: using AI models inside a company is like dropping the smartest person you know into it. If they don't have the context and the data, their intelligence doesn't matter.

Rathle took it further. "Intelligence bereft of knowledge and data is meaningless," he said. "That's not to say that models don't have knowledge, but it's the world's knowledge and it's not your knowledge". Companies want separation between the model and their data for three reasons: the data is part of their moat, sovereignty is a live concern, and models get swapped out as they evolve.

His argument for graphs starts from what AI needs to work: knowledge, memory, context, semantics. All of it takes structure of some kind, whether that's a network, a hierarchy, or a set of paths and journeys.

Where the answer has to be right every time

The interesting part of Rathle's pitch is how narrow he makes it. He isn't claiming agents need graphs for everything. His claim is that inside most agentic applications there's a small subset of questions where the accuracy bar is absolute, for regulatory reasons, health and safety, or brand and reputational risk, and those questions need 100% accuracy, explainability, and access controls.

Those properties are hard to get, or simply unavailable, when the data is baked into the model's training or scattered across a pile of SQL silos. Representing it in a knowledge graph lets you run the query deterministically instead. The graph call then does one of two jobs: it feeds context back so the model makes a better decision, or it returns a deterministic answer that gets passed straight through.

"Gartner uses the term multihop reasoning," Rathle said. "I like to call it connect-the-dots reasoning — solve for money laundering or fraud or drug discovery by degrees of Kevin Bacon". Whatever the name, he credits it with moving a lot of teams from prototype to production.

Fifty ERP systems and the reconciliation shortcut

Rathle described a customer where this problem got concrete: years of acquisitions left them with 50 ERP systems, plus the authorization systems and data warehouses hanging off the back of each one.

The stakes there are competitive, not aesthetic. If the scope of your AI is limited to the scope of a silo, Rathle argues, each decision is bounded by whatever happens to sit in one system, one division, one department, and the company's competitiveness shrinks to match.

His answer skips the boil-the-ocean migration. Rather than lifting all of a company's data at once, you take the key data for each entity as it's represented in each system, create a node for it, run an entity reconciliation exercise, and hang a relationship from each of those nodes to the master reconciled entity. One customer scattered across a dozen systems becomes a dozen nodes pointing at one, and the context an agent needs is the set of relationships around it.

What makes it tractable is schema flexibility: start with some data, add more later. "You don't need to do it as a multi-year 'let's try to predict everything I'm going to need three years from now,'" Rathle said, "because no one can predict out three weeks".

From PageRank to GraphRAG

Rathle dates Neo4j's AI trajectory well before ChatGPT. His reference point is Google, a trillion-dollar-plus company built entirely on graphs, where PageRank, a structural graph algorithm, is what separated it from search engines that were otherwise indexing at roughly the same level.

Neo4j's own AI work started around 2020, layering graph algorithms onto a transactional database: clustering, centrality measures, graph machine learning like link prediction. Then graph neural networks. A GNN embedding looks identical to a word embedding, but it encodes the topology of the graph around a node, enough to ask whether someone in a social network looks like a celebrity, a bot, or a regular person. GNNs were the hot up-and-coming technique right up until ChatGPT shipped, at which point everyone forgot about them in favor of LLMs.

What happened next came from the community rather than the company. Open source, commercial, and SaaS users worked through big models, small models, open, closed, fine-tuned, not fine-tuned, and multiple models playing against each other, then landed on the same conclusion: they needed some of their own data in the loop. Vectors were the first stop. "Everyone went to vector embeddings first, but that's kind of a one-trick pony, or generously two, if you consider the two kinds of similarity," Rathle said. "There's still a lot missing there. There's no explicit knowledge, and that knowledge can't be viewed or inspected by a human".

Graphs restore the parts vectors drop: explicit knowledge a human can read, plus pattern matching and filtering through Cypher and through GQL, the ISO standard graph language modeled on SQL. Rathle credits Microsoft with popularizing the term for the pattern that followed, GraphRAG, where a model or harness calls out to a knowledge graph, pulls data back, and feeds it to the model.

Neo4j read that as a platform shift, for the industry and for itself, and reworked its product portfolio, sales and marketing motion, positioning, and integration partners around it. The target position: the best possible knowledge layer living alongside LLMs, or as Rathle put it, "the left brain to the LLM right brain, for a full-hemisphere kind of AI solution".

Chained agents compound their error rates

Ask what changed with agents specifically and Rathle goes straight to arithmetic. More autonomy means less human in the loop, and chaining agents together lets inaccuracies cascade. "If you have 10 different agents, each one of which can be 80% accurate, then the decision coming out the other end is going to be pretty bad".

That's the argument for putting something deterministic somewhere in the chain.

It also raises two design questions for anyone building multi-agent systems. First, orchestration: with enough agents involved you want a supervisor agent working out how agents get called, and Rathle has seen agent call graphs used to govern those interactions. Second, placement: which of the agents in an interaction should actually make a graph call, since it probably shouldn't be all of them.

What a database company will and won't hand to an agent

Grinich pointed out that databases resemble authentication in one specific way: you don't vibe code them, you don't skip permissions, and you don't skip code review, because data integrity matters too much.

Rathle split Neo4j's internal adoption into what makes it harder and what makes it easier. Harder: a very high bar for security and availability, with hundreds of thousands of managed databases and a level of customer trust the team treats as non-negotiable. Easier: years of investment in code quality. "We've cleaned up tech debt, so that makes it easier for the models to replicate good patterns as opposed to getting confused by bad patterns," he said. "We also have hundreds of thousands of tests, and that makes it easier for us to mess around with things".

The payoff landed somewhere other than where they started. Prototyping was the obvious entry point, but the real return came at the other end of the lifecycle. Across a set of independent, interdependent codebases whose APIs call each other, agents turned out to be very good at troubleshooting the gnarly issues that would otherwise cost engineers hours of root causing. The second win was onboarding: new engineers asking the codebase the questions they'd otherwise route through permanently busy senior engineers.

The through-line of the conversation is that the model was never the scarce resource. Structure was. Whether you get there through a knowledge graph, a reconciled entity model, or a hundred thousand tests that let agents work safely in your repo, it's the same job: making your own context legible enough that something autonomous can act on it and be right.

This interview was recorded at the AI Engineer World's Fair 2026 in San Francisco.