The Knowledge Graph Debate Is Asking The Wrong Question

Everyone's shopping for a knowledge graph right now. You might ask why. Gartner's 2026 Hype Cycle puts agentic AI at the Peak of Inflated Expectations: only 17% of organizations have deployed AI agents, while more than 60% expect to within two years, representing the most aggressive adoption curve of any emerging technology in its CIO survey. Practices like context graphs show up on that same curve as early-stage¹... which is exactly why shopping for one by name is premature.

What's more, almost nobody I talk to can tell me what problem they expect it to solve that their current systems can't.

That's not a knock on the people asking; it's a symptom of how the term got popularized. "Knowledge graph" is what shows up on LinkedIn as the thing you need to get trusted context into your AI. So people go looking for a knowledge graph the way you'd go looking for a specific brand of aspirin: because that's the name they've heard, not because they've diagnosed the headache.

I want to make a specific, slightly contrarian case: the fight over whether you need "a knowledge graph" versus "a data catalog" is a fight over the wrong variable. It treats representation (how the relationships are stored and traversed) as the thing that determines whether your AI is trustworthy. It isn't. The thing that determines whether your AI is trustworthy is whether those relationships are still true by the time an agent acts on them.

Nested layers, not competing bets

I don't think the honest answer is "you don't need a knowledge graph." The honest answer is that the mental model most vendors are selling — pick a semantic layer, or an ontology, or a knowledge graph, or a context layer, whichever one the sales rep in front of you happens to sell — is the wrong model entirely. These aren't competing purchases. They're nested capabilities, each one containing and extending the one below it:

A semantic layer standardizes what things measure. An ontology contains that and adds what things are and how they connect. A knowledge graph is what you get when you populate that ontology with your real, governed data. An enterprise context layer contains all of that and adds the judgment an autonomous agent needs to act on it responsibly: who owns this, is it still current, is it safe for this agent to use.

Ask "do I need a knowledge graph?" in isolation, and you're asking the wrong question. Ask "which layer is actually my bottleneck?" and you get somewhere.

If different teams get different numbers for the same metric, that's a semantic layer gap. If your agents don't understand how your business concepts relate to each other, that's an ontology gap. If your agents need to trace a chain of relationships several hops deep, that's a traversal gap and a knowledge graph is built for the job. If your agents fail on multi-step workflows that need judgment and policy awareness, that's a context layer gap.

None of these get solved by picking a representation first and hoping the rest follows.

Why this matters more for agents than for search

This distinction is easy to gloss over when the use case is retrieval: an agent doing RAG-style lookup just needs to find a relevant chunk of context, and a graph traversal or a well-built catalog search will both get it there.

It gets much less forgiving once the agent is expected to act autonomously: file a change, flag a disruption, make a recommendation someone downstream will trust without checking it by hand. Matt Robuck, VP of Data and Analytics at Georgia-Pacific, states the challenge plainly: when something was wrong in a report, a human would usually catch it, but with agents, there often isn't a human in the loop until much later, so poor-quality data carries much further.²

A knowledge graph answers "how are these things related?" It doesn't, by itself, answer "is this relationship still true, who owns it, and can I trust it right now?" — and that second question is the one an autonomous agent actually depends on. A graph populated once and never revisited will confidently hand an agent a relationship that was accurate eighteen months ago and isn't anymore. The graph doesn't know that. Neither does the agent, unless something or someone is actively checking.

That's true whether you call the artifact a graph, an ontology, or a catalog. A catalog you populate once and never touch again decays exactly as fast as a graph you populate once and never touch again: tables get deprecated, definitions shift, ownership changes hands, and the artifact quietly stops describing anything real. So the question worth asking isn't "graph or catalog." It's "what's actually keeping this current?" regardless of what you call it.

The real differentiator is the feedback loop

The organizations getting durable value out of any of these layers have built a working feedback loop: a way for the system to notice when an agent gets something wrong and route that signal back into the underlying model, plus continuous data quality monitoring underneath, checking that the data feeding all of this is still accurate before an agent ever touches it.

That's not a hypothetical mechanism. On a published benchmark of 20 question-SQL pairs, a SQL agent's accuracy went from 60% to 100% across two iterations — not because the model changed, but because each failure was traced to a specific metadata gap, the metadata was fixed, and the agent was re-tested, with a person reviewing and approving every change.³

Georgia-Pacific shows the same mechanism at a different scale. Robuck inherited a spare parts problem decades in the making:⁴ more than 200 sites were each stockpiling spare parts against the cost of downtime, accumulating duplicate inventory faster than it could be tracked or reconciled.⁵ The data to fix it already existed across thirty sources.⁶ What didn't exist was trust: this users described numbers that would double, without explanation, overnight.... so they stopped looking.⁷

To address this, Robuck's team connected GP's data quality tools directly into the platform, so quality signals sat alongside the documentation, metadata, and lineage users needed to make sense of what they were seeing.⁸ Data quality and business processes improved, and the behavior changed at the point of decision. Today, a procurement manager can check whether a specific mill already has a key motor rather than ordering one from an external supplier.⁹ Across GP's three businesses, that capability moved about $25 million in intercompany transfers in 2025, spend that never left the company.¹⁰

And Daimler Truck North America shows the version of this where the relationships themselves have to stay current. Its team is building supply-chain agents as an early-warning system against the bullwhip effect — agents that detect risk and surface it to planners before a delay escalates. Its chief data officer's precondition for the whole program is blunt: "no metadata, no AI."¹¹ Those agents aren't waiting on a better model. They're waiting on context that's accurate.

None of those three results depended on which representation anyone chose. They depended on capturing good context and keeping it current, the unglamorous, compounding work that doesn't fit neatly into a vendor pitch about graph technology.

Why this needs a platform, not another layer

This is also why "just add a knowledge graph" tends to disappoint people. A graph is an artifact. It doesn't monitor itself, it doesn't know when a table gets deprecated or an owner changes teams, and it doesn't have an opinion about whether a given agent should be trusted with a given relationship. Somebody, or something, has to do that work continuously — across the semantic layer, the ontology, and everything built on top of them — or the artifact starts lying to you quietly, which is worse than not having it at all.

That's the problem Alation's Intelligence Operating System is built to solve end-to-end, rather than leaving it to whichever tool happens to sit on top. Instead of treating the semantic layer, the ontology, and agent governance as separate purchases from separate vendors, each maintained on its own schedule by its own team, AIOS runs them as one system: catalog, lineage and quality scoring at the foundation, ontologies and semantics as the reasoning layer, governance wrapping every layer, and feedback loops that route an agent's mistake back to whichever layer caused it.¹² The result is a governed foundation that describes your business as it exists today, not as it existed when someone last got around to updating it.

That's the part worth shopping for. Not a storage format. Not a specific graph engine. A system where the semantic layer, the ontology, and the governance that keeps them current aren't stitched together from separate parts, but are one maintained foundation you can build reliable agents and applications on top of — because you can trust what it's telling them.

Start with the outcome

None of this means representation doesn't matter at all, since the shape you choose still has to fit the questions your AI agents need to answer. What I'd push back on is the idea that you get reliable agents by shopping for a specific representation first.

You get reliable agents by asking what business problem you're actually trying to solve, building the governed foundation that any of these layers needs to sit on, and putting a real feedback loop underneath it so that foundation stays true as the business changes. Once you've done that, the representation — semantic layer, ontology, knowledge graph, context layer — is the easy part. Start with the outcome, and build the system that keeps it trustworthy.

Sources & notes

Every external claim on this page is independently verifiable. The public sources are listed here.

1. Agentic AI placed at the Peak of Inflated Expectations; 17% of organizations have deployed AI agents against more than 60% expecting to within two years, per the 2026 Gartner CIO and Technology Executive Survey; context graphs among the early-stage practice profiles on the curve. — Gartner, "What the 2026 Hype Cycle for Agentic AI Reveals," 15 April 2026 ↗ https://www.gartner.com/en/articles/hype-cycle-for-agentic-ai

2. Robuck on the absence of a human in the loop until later in an agentic process, and the consequences for data quality. — CIO, "How Georgia-Pacific drives autonomous decision-making," 27 May 2026 ↗ https://www.cio.com/article/4174331/how-georgia-pacific-drives-autonomous-decision-making.html

3. SQL agent improved from 60% to 100% accuracy — 12 of 20 evaluation cases correct at baseline, 20 of 20 after two iterations — with every change to the underlying data product surfaced for human review and approval, and an audit trail of what changed. — Alation, "How to Build SQL Agents That Actually Work: Why Evaluations Matter," 10 March 2026 ↗ https://www.alation.com/blog/ai-agent-evaluations/

4. Robuck: many of the problems his team is solving today are ones Georgia-Pacific has been dealing with for decades. — CIO, 27 May 2026 ↗ https://www.cio.com/article/4174331/how-georgia-pacific-drives-autonomous-decision-making.html

5. Over 200 Georgia-Pacific sites independently stockpiling spare parts against downtime cost; inventory accumulating faster than it could be tracked or reconciled. — Alation, "The $25 Million Reason Georgia-Pacific Rebuilt Its Data Foundation," 6 April 2026 ↗ https://www.alation.com/blog/georgia-pacific-data-transformation-matt-robuck/

6. Thirty separate data sources across the organization held the answer. — Alation, 6 April 2026 ↗ https://www.alation.com/blog/georgia-pacific-data-transformation-matt-robuck/

7. Users reported figures that doubled from one day to the next, and confidence eroded to the point that people stopped looking. — Alation, 6 April 2026 ↗ https://www.alation.com/blog/georgia-pacific-data-transformation-matt-robuck/

8. Data quality tools connected into the GP Data Pulse platform, in context alongside the documentation, metadata, and lineage users needed. — Alation, 6 April 2026 ↗ https://www.alation.com/blog/georgia-pacific-data-transformation-matt-robuck/

9. A procurement manager can check whether another GP facility already holds a replacement motor before buying new from an external supplier. — Alation, 6 April 2026 ↗ https://www.alation.com/blog/georgia-pacific-data-transformation-matt-robuck/

10. About $25 million in intercompany transfers last year, company-wide across GP's three business divisions (Consumer Products; Building Products; Packaging and Cellulose). — Alation, 6 April 2026 ↗ https://www.alation.com/blog/georgia-pacific-data-transformation-matt-robuck/

11. Daimler Truck North America developing "vertical" and "horizontal" supply-chain agents as an early-warning system against the bullwhip effect, detecting risk and surfacing insight so planners can act sooner; "no metadata, no AI." — Edgar Gallo, Chief Data Officer, Daimler Truck North America, writing for Alation, 3 December 2025 ↗ https://www.alation.com/blog/daimler-trucks-ai-agents-metadata-manufacturing/

12. AIOS layers: catalog, lineage, quality scoring and curation at the data foundation; data products, marketplace, ontologies and semantics as the context layer; Agent Studio with evaluations; governance enforced across every layer; and feedback loops that route a correction to the layer that caused it. — Alation, AIOS product overview, accessed 7 August 2026 ↗ https://www.alation.com/aios/

Analyst attributions & disclaimers

Gartner, What the 2026 Hype Cycle for Agentic AI Reveals, Rajesh Kandaswamy, 15 April 2026. Survey data cited: 2026 Gartner CIO and Technology Executive Survey.

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER and Magic Quadrant are registered trademarks and service marks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.