---
title: "Your Agent Doesn't Need to Walk the Graph"
url: "https://atlan.com/context-and-chaos/issue/your-agent-doesnt-need-to-walk-the-graph/"
description: "Storing your context in a graph can be the right call. Hooking that graph up to the agent almost never is, and the two decisions get made as though they were..."
keywords: "Knowledge Graphs, Context Engineering, AI Agents, Semantic Layers"
---

> Atlan is hosting Context Conference, bringing together the leaders and builders at the frontier of giving AI the context it needs to understand their business. It runs online on October 28, 2026, from 11:00 AM to 2:00 PM ET. Atlan co-founder Prukalpa Sankar opens and closes the day. Leaders from AstraZeneca, BNY and Verizon share why they invest in context and what they get from it. Registrants get early access to The AI Context Gap, a new study from MIT Technology Review Insights. Register: https://atlan.com/context-conference/

A Context & Chaos deep dive (Atlan's practitioner newsletter) by **Andrew Lentz, Solutions Consultant at Atlan**, who prototypes apps and agent tooling on top of the metadata layer alongside Atlan's largest customers. Published August 20, 2026, 18 min read. Storing your context in a graph can be the right call; hooking that graph up to the agent almost never is, and the two decisions get made as though they were one.

Key points:

- Every schema already has relationships, so connectedness cannot be the test for a graph database. A foreign key is an edge and a JOIN is a one-hop traversal, so "our data is a graph" is true of every warehouse. A test that never fails is not a test.
- Where you store context and what the agent queries at runtime are separate decisions. A graph is often the right place to model and govern an ontology. Distil it into definitions, join keys, grain and governing rules, and the agent never needs to know the graph exists.
- Three conditions earn a second database: a path or topology deliverable, a recursive frontier that genuinely explodes, and single-digit-millisecond traversal under concurrent writes. None requires an agent to touch the graph; each is satisfied by a system that runs the traversal and returns a result.

## The insurer that did not need a graph

A Fortune 500 insurer had been handed reference architectures by every cloud vendor in its stack and concluded its agent had to be wired into a managed knowledge-graph service. The conviction came from the diagrams, not the workload: nobody had counted the questions or described the path the agent would take. The actual questions were bounded ("can this rep sell this product in this state?", "what is the status of this policy?"), with napkin-drawable join paths, and they already ran a governed metadata layer holding most of what was needed. They did not need a graph database, nor their agent near a graph. They needed it to know what their columns meant.

## Store it in a graph if you like. Just don't wire it to the agent.

- Storing context in a graph is a storage decision, and can be right when context serves many agents. An ontology is the one genuinely graph-shaped part: its content is relationships (what subsumes what, which properties apply where), it is small and slow-changing, and people govern it, not pipelines. Model and govern it there, then distil from it and let the agent read the distillation.
- "Our data has relationships, so we need a graph" is the same slip: every schema has relationships. (Vocabulary per Jessica Talisman's January issue.)
- What the author objects to is the model doing the walking, deciding hop by hop and then still writing the query. A service that walks a graph and hands the agent a result is fine and often the right build. Data lives in relational systems in the large majority of cases; the agent's job is to structure a correct query, and curated context tells it how, a graph does not.
- Hidden cost: reasoning across a graph and then to SQL is two rounds of inference for one answer - more tokens, more latency, more run-to-run variance. Hand the agent known-good query patterns, notes on how a table is meant to be used, and the rules that govern fields instead.

(Diagram: a graph or ontology used for upstream authoring and governance, separate from the distilled definitions, join keys, grain, governing rules and known query patterns the agent reads before querying SQL.)

## Paths or lookups: the whole sort

- **Lookups:** bounded questions with a join path knowable at design time; the answer is a value or a set (e.g. claims filed in a region last quarter). The agent needs definitions, join keys, grain and the governing rule, then queries existing data. No second database; nothing traverses.
- **Paths:** the shape of the connection is the answer - shortest or all routes, fraud rings (cycles), centrality, who is within N hops and how they are linked.
- Depth is the wrong criterion. A recursive frontier grows at roughly fan-out to the power of depth: a deep, narrow acyclic graph is cheap to walk; a shallow, dense cyclic one is ruinous by depth three. Enterprise metadata is overwhelmingly the first shape.
- Recursive CTEs make SQL Turing-complete, but expressiveness is not speed. One team walking a 335,000-node tree cut a recursive CTE from 47 seconds to 227 milliseconds by moving traversal into a C extension, in the engine they already ran, not a graph database. Another published limits: fine at 100,000 nodes and depth four, degrading at 500,000 nodes and depth six.
- Pathfinding (betweenness centrality, community detection, cycles) is where recursive SQL becomes a bad idea; graph engines have decades of specialised algorithms. General cyclic graphs need explicit cycle handling that DAG traversal never needs.
- Diagram data: recursive traversal time on a dense cyclic graph rises from 0.016 s at depth two to 30.267 s at depth three and 1,543.5 s at depth four. "Density, not depth."

## Three conditions earn a second database. None put the agent on it.

Query-pattern tests, not modelling tests:

1. The deliverable is a path or topology result: shortest or all paths, cycle detection, community identification, centrality ranking.
2. The frontier actually explodes: high fan-out, many back-edges, nothing to prune on. Measure it.
3. You need single-digit-millisecond per-entity traversal under concurrent writes. Index-free adjacency makes per-hop cost independent of graph size, which matters for operational serving, not analytics.

None requires the agent to touch the graph. Meet condition one and buy the engine; that still does not mean wiring it to the model. Standing exclusion: aggregations, rollups and temporal windows, where graph query languages are weak and columnar engines excel.

Common failures:

- A second store proposed when the existing governed metadata layer would answer the question, inherited from a reference architecture; nobody measured the frontier or sorted the questions.
- The stale replica: an ETL'd copy of an authoritative relational system, buying staleness in exactly the compliance and executive settings where the graph was pitched as the trust layer. One team moved hierarchy, dependency and ownership questions off a graph database into recursive SQL in their warehouse: roughly 94% less cost (about $800 a month to about $50 a year) and one less system. They kept the graph engine only for centrality, community detection and unbounded pathfinding.

## What the graph papers actually measured

- **Sequeda et al.:** QA accuracy over an enterprise SQL schema rose from 16.7% to 54.2% with a knowledge graph. But that knowledge graph is an ontology plus mappings acting as a context layer the model reads, not a graph the agent traverses at query time.
- **Han et al., systematic GraphRAG evaluation** (plain retrieval vs four GraphRAG families on single-hop, multi-hop and detail-oriented benchmarks). The knowledge-graph-extraction variant loses to plain retrieval on every QA benchmark:

| Measure | KG-based GraphRAG | Plain retrieval |
|---|---|---|
| MultiHop-RAG accuracy | 48.5% | 67.0% |
| HotpotQA F1 | 42.6 | 60.0 |
| Index build time | 7,702 s | 135 s |
| Retrieval time | 14,434 s | 1,724 s |

That is 57 times the preprocessing and 8 times the query cost, to be worse at multi-hop. Winning variants gain about three points on multi-hop by using the graph to choose which text chunks to retrieve; the model never sees the graph. GraphRAG is a retrieval strategy over text, not an argument for an operational graph database.
- On unanswerable questions, plain retrieval correctly declines 96.0% of the time; the community-summarisation variant declines 19.3% and otherwise fabricates a relationship and answers.

## Two numbers on the same benchmark

- Semantic-layer benchmarks in the high nineties score only questions inside the layer's modelled scope.
- Whole schema: on Spider 2.0 (enterprise text-to-SQL), frontier models first scored in the low teens, against 86.6% for the same model on Spider 1.0. Holding DeepSeek-R1 fixed and changing only the scaffolding: 13.7% (reference scaffolding), 30.5% (one agent framework), 52.3% (another). Thirty-nine points, same model and store; what changed is what the system tells the model about the schema.
- Context & Chaos's February controlled experiment: 174 questions, 13-table schema, 522 runs, changing only the context layer. Accuracy rose from 16.1% (bare schema) to 22.2% (high-signal context), significant at p below 0.0001. Verbose documentation-style context did worse than concise high-signal context, dropping 13.8% while costing 52% more.
- Enterprise text-to-SQL is neither solved nor unsolved; it responds to how much of the schema is described, and how well. The work is enlarging the modelled scope and keeping it current. A governed layer also lets the system refuse unanswerable questions instead of returning a wrong number that lands in a board deck.

## The agent should never know the graph was there

Context & Chaos previously argued semantic layers failed and context graphs are next, "unless we get it right." Semantic layers failed because they were built as hand-maintained documentation projects that went stale; a context graph maintained the same way inherits that failure. Even a fresh context graph is the wrong thing to hand an agent: distil it into definitions, join keys, grain and governing rules read in a single pass. The distillation must be generated, versioned and close enough to the systems of record that nobody asks how old it is.

## Mark twenty questions. Count the paths.

Take the last (or next expected) twenty agent questions and mark each three times:

1. **Path or lookup?** If paths are at or near zero, no graph database will help.
2. **Inside or outside the modelled scope?** The outside count is your real accuracy ceiling, the one vendor benchmarks do not measure.
3. **Does the agent have to know the graph exists to answer it?** This decides the architecture, and the column comes back empty even for teams that legitimately need a graph engine somewhere.

Most teams find almost no paths, many out-of-scope questions, and nothing in the third column: a context problem, and the one to fund. The advice to the insurer: a graph is for questions shaped like paths; yours are lookups, so don't stand up a second database for a SQL question or put the model in front of one.

Closing cartoon: a cat with an AGENT backpack climbs a graph-covered mountain past a "17 hops to answer" sign; a professor cat beside a product/state/eligibility table, "distilled once from the same graph", asks "Why are you the one walking it?"

## About Context & Chaos

A community newsletter where practitioners, builders and thinkers share stories and lessons on context engineering, governance, architecture, discovery, and the human side of data and AI work. [Browse all issues](https://atlan.com/context-and-chaos/) or [contribute](https://atlan.com/context-and-chaos/contribute/).

Related reads:

- [Semantic Layers Failed. Context Graphs Are Next.](https://atlan.com/context-and-chaos/issue/semantic-layers-failed-context-graphs-are-next/) (February 2026)
- [Ontologies, Context Graphs, and Semantic Layers: What AI Actually Needs in 2026](https://atlan.com/context-and-chaos/issue/ontologies-context-graphs-and-semantic-layers-what-ai-needs-in-2026/) (January 2026)
- [The Context Problem Nobody's Fixing in Talk to Data Initiatives](https://atlan.com/context-and-chaos/issue/the-context-problem-nobodys-fixing-in-talk-to-data-nl-to-sql/) (February 2026)
- [Context Graphs Are a Trillion-Dollar Opportunity. But Who Captures It?](https://atlan.com/context-and-chaos/issue/context-graphs-are-a-trillion-dollar-opportunity-but-who-captures-it/)