A knowledge graph maps entities and their relationships at design time. A context graph extends that structure at runtime with decision traces, temporal validity, and policy, and Gartner expects over 50% of enterprise AI agent systems to rely on context graphs by 2028. That raises a practical question: does your stack already count as one? Atlan’s Enterprise Data Graph unifies metadata from 75+ connectors: assets, lineage, policies, certifications, and business glossary: into one governed substrate that gives AI agents the decision traces, temporal validity, and access rules they need to act, not just answer.
Picture an AI agent inside a B2B company, handed a live request: a sales rep wants to approve a 20% discount for a strategic account before quarter close. The agent has to decide, not just describe. What it can pull from the graph behind it determines whether that decision holds up.
A knowledge graph handles the structural questions well. It knows the account, the contract, the product, and the pricing policy, and it knows how those entities connect. Ask it which discount tier applies to this product line, and it returns a clean answer.
A context graph answers the questions the agent needs before it acts. Was a similar discount approved last quarter, and who signed off? It also surfaces which policy version was in force when that exception was granted, and whether the exception was later reversed. Those are decision traces, approvals, and temporal validity, the kind of record a knowledge graph was never built to hold.
Context graph vs. knowledge graph: At a glance
Permalink to “Context graph vs. knowledge graph: At a glance”Foundation Capital’s Ashu Garg framed the distinction as a new layer of value, describing a context graph as “the accumulation of decision traces” and “the enduring layer” for agent systems. The table makes that abstraction operational.
| Dimension | Knowledge graph | Context graph | What Atlan does about it |
|---|---|---|---|
| Purpose | Model what entities exist and how they relate | Record how decisions get made and what was true when | The Enterprise Data Graph unifies metadata from 80+ connectors into one traversable graph |
| Focus | Noun-centric: entities and relationships | Verb-centric: decisions, events, provenance | Connects glossary terms and assets to the lineage and policies that act on them |
| Content unit | Entities and typed relationships | Decision traces, policy nodes, lineage edges, certification | Treats lineage, policies, and certifications as first-class graph nodes |
| Temporal model | Mostly the current state | Validity windows and point-in-time answers | Active metadata timestamps change so the graph can answer “what was true on a given date.” |
| Governance model | Usually documented outside the graph | Policies modeled as queryable nodes | Policy-aware traversal is built into the platform |
| Update cadence | Often, design-time or batch | Continuously generated at runtime | Active metadata refreshes from queries, lineage events, usage, and quality signals |
| Query pattern | Semantic queries in SPARQL or Cypher | Multi-hop traversal returning a bundle of context | Context is exposed through the MCP Server, SQL, and APIs |
| Consumers | Humans and applications | AI agents and humans together | The same governed context serves copilots, agents, and analysts |
| Build mode | Ontology modeled by hand | Generated from existing metadata, then curated | Context Agents bootstrap descriptions, linked terms, and lineage |
| Audit model | Limited provenance | Approvals and provenance on the record | Lineage plus certification supply the audit trail |
| Schema flexibility | Fixed ontology | Evolves as new traces and policies arrive | The graph extends as connectors and policies change |
| AI-agent fit | Grounds answers in entities | Grounds actions in governed, time-aware context | Rich metadata improved AI-generated SQL accuracy by at least 38% in Atlan AI Labs tests |
Gartner expects context engineering to improve agentic AI accuracy by at least 30% through 2028, and to be built into 80% of the software tools used to build AI applications by the same year, per Atlan’s analyst summary.
What is a knowledge graph?
Permalink to “What is a knowledge graph?”A knowledge graph is a structured representation of entities and the semantic relationships between them, machine-readable and optimized at design time for semantic queries. Entities are the nodes: customers, products, datasets, and policies. Typed edges, called relationships, connect those nodes.
An ontology defines the vocabulary, classes, properties, and constraints of the domain, usually expressed in W3C standards such as RDF and OWL, and queried with SPARQL. Property-graph systems like Neo4j model the same idea with nodes-that-carry-properties and a query language called Cypher.
This is mature, proven technology, and it carries real weight in production. Google’s search results, biomedical research, and fraud-detection systems all run on knowledge graphs. The graph structure also measurably helps language models answer enterprise questions. In a 2023 study by Sequeda, Allemang, and Jacob, GPT-4 with zero-shot prompting reached 16.7% accuracy answering enterprise questions directly over a SQL database, and 54.2% when the same questions were answered over a knowledge graph representation, roughly a 3x improvement.
What is a context graph?
Permalink to “What is a context graph?”A context graph is a knowledge graph extended at runtime with operational metadata, including lineage, policy nodes, decision traces, temporal validity, and certification, purpose-built for AI agent consumption.
PlayerZero founder Animesh Koratana put the image simply at the Neo4j NODES keynote, calling a context graph “a fabric of decision traces that are woven together.”
A decision trace is the core unit. It is a structured record of how a specific decision was made, capturing the inputs gathered, the policies applied, the exceptions granted, the approvers, the timestamp, and the outcome.
The reason this matters commercially is ownership of the work that sits on top of the graph. The operational case is narrower and more useful to a buyer: a context graph changes how the graph is built, how often it updates, what it stores, and who reads it, which is why “just a knowledge graph with extra metadata” understates the difference.
The agent query: what a context graph actually returns at runtime
Permalink to “The agent query: what a context graph actually returns at runtime”The two examples below are illustrative pseudocode built from Atlan ecosystem entities. They are not a query-language specification. They exist to make the difference between “answer” and “governed action” visible.
Start with the everyday case. An analytics agent needs to write SQL for a revenue question. A knowledge graph can tell it which table relates to revenue. What a context graph returns is that table plus everything the agent needs to use it safely.
agent.request: "write SQL for Q3 net revenue by region"
context_graph.return {
table: "finance.fct_revenue_v2"
glossary_term: "Net Revenue = gross revenue minus refunds and credits"
lineage: ["raw.orders" -> "stg_orders" -> "fct_revenue_v2"]
certification: "Certified by Finance Data team"
last_edit: "schema changed 2026-04-11, refund logic updated"
owner: "[email protected]"
policy_node: "row-level filter: region scope by requesting team"
temporal_validity: "definition valid from 2026-01-01; prior periods use v1"
}
The second case is where the verb-centric nature earns its keep. A regulated-decision agent needs to approve or deny something a policy governs, and it needs precedent, not just a definition.
agent.request: "Can this counterparty be onboarded under the current policy?"
context_graph.return {
policy_node: "KYC tier-2 approval, effective 2026-02-01"
approvers: ["compliance-lead", "risk-officer"]
decision_precedent: "3 similar cases approved with enhanced due diligence"
exception_trace: "1 exception granted 2025-11, later reversed"
temporal_validity: "policy version 4; version 3 applied before 2026-02-01"
provenance: "policy source: Compliance Handbook s.4.2"
}
In Atlan AI Labs tests, rich semantic metadata improved AI-generated SQL accuracy by at least 38% (p-value < 0.0001), measured across 522 evaluations: 174 unique queries, each run 3 times, on a Formula One dataset with 13 tables and 94 columns. Medium-complexity queries saw a 2.15x improvement with enhanced metadata.
Customers running Atlan AI Labs workshops have reported up to a 5x improvement in query accuracy after layering context onto their existing data.
See it in action: Watch the Context Engineering Studio demo to see how teams test and ship the business context an agent reads at runtime.
Knowledge graph as a subset of context graph
Permalink to “Knowledge graph as a subset of context graph”The most useful question a budget-aware architect can ask is not “what is a context graph?” It is “what do I already have?” The answer, for most enterprises, is more than they expect. A context graph sits atop the knowledge or metadata graph already in place, so the work is additive rather than a rebuild.
The five runtime properties of a context graph: decision traces, temporal validity, policy nodes, lineage provenance, and runtime governance.
Here is the dimension-by-dimension mapping of what a knowledge graph gives you versus what a context graph adds.
- What a knowledge graph already gives you: entities, typed relationships, an ontology, and a semantic query. This is the substrate, and as the accuracy benchmarks above show, it is a strong one.
- What a context graph adds on top: decision traces, temporal validity windows, policy nodes, lineage edges that record provenance, and runtime governance that an agent can traverse.
- Where the line sits: design-time versus runtime, and manual modeling versus continuous generation. A knowledge graph is something you model. A context graph is something your metadata generates and keeps fresh.
Five key differences between knowledge graphs and context graphs for AI-ready data. Image by Atlan.
Common misconceptions about context graphs
Permalink to “Common misconceptions about context graphs”There’s some skepticism among practitioners. Let’s engage the best skeptics, because each of their objections sharpens the operational definition. These misconceptions come up repeatedly:
- “It’s just a knowledge graph with more metadata.” Adding metadata is one cell; a context graph changes the build mode, update cadence, query pattern, and consumer all at once.
- “It’s just a vector database or agent memory.” Vector stores are retrieved by similarity; a context graph traverses governed relationships and returns policy and provenance.
- “It’s just procedural knowledge under a new name.” The operational distinction still holds: continuous generation from live metadata, runtime traversal, and policy-aware governance are not how procedural knowledge was historically captured.
The honest reply to the buzzword charge is data, with its caveat attached. MIT’s Project NANDA reported that 95% of organizations were getting zero return on enterprise generative AI investment, with only 5% of pilots reaching rapid revenue acceleration.
How context graphs ground AI agents in operational reality to prevent hallucinations. Image by Atlan.
Where teams go wrong when building a context graph
Permalink to “Where teams go wrong when building a context graph”A fresh set of mistakes shows up on the inside once a team starts building. Three of them recur.
- Modeling decision traces by hand: Traces should be generated from lineage, query history, and transformations, not written one at a time. Hand-authoring stops scaling after a handful of flows.
- Treating policy as documentation: A rule that lives in a handbook cannot be traversed by an agent at runtime. It has to become a queryable node before governance can act on it.
- Using static lineage as a stand-in for temporal validity. Lineage shows how data connects today. Point-in-time decisions also need to know what was true on the date a choice was made.
How to evolve from your existing metadata graph
Permalink to “How to evolve from your existing metadata graph”You are not starting from zero. Your lineage, glossary, and active metadata already make up a large share of a context graph. Five steps close the remaining gap.
- Audit your current lineage and glossary: Map what entities, relationships, and definitions you already model. This is your knowledge-graph substrate, and it is usually further along than teams assume. Start from your data lineage and business glossary.
- Layer governance nodes: Promote policies and certifications from documentation into first-class graph nodes that an agent can traverse, so governance becomes queryable rather than referenced.
- Add temporal qualifiers. Attach validity windows to relationships so the graph can answer point-in-time questions instead of only current-state ones.
- Expose the graph through MCP. Serve a governed context to agents and copilots through a standardized interface, as an MCP-connected catalog provides.
- Loop in active metadata so the graph self-refreshes. Let queries, lineage events, usage, and quality signals keep the context up to date without manual curation.
Two schools of thought meet on this path, and the build benefits from both. Neo4j CEO Emil Eifrem described the win as combining bottom-up discovery with a top-down view, calling that combination “really powerful.”
Atlan’s Context Agents are built to compress the slow part of this work. They can take 9 to 12 months of manual enrichment and complete it in weeks, generating descriptions, linked terms, metrics, and domain tagging from lineage, SQL, and transformations.
When you need a context graph (and when a knowledge graph is enough)
Permalink to “When you need a context graph (and when a knowledge graph is enough)”A knowledge graph on its own is the right answer in several cases:
- Static taxonomy or design-time semantic modeling, where the entities and relationships rarely change.
- A single-domain ontology that one team can maintain by hand.
- No autonomous agents making policy-sensitive decisions against the graph.
You need a context graph when the work crosses those lines:
- Regulated decisions where provenance, approvers, and exceptions must be on the record.
- Multi-system precedent, where “what did we do last time” spans several tools.
- Agent autonomy, where an AI system acts rather than just answers.
- Cross-functional process automation that no single team’s ontology covers.
It’s best to start small. Over-building is a real risk. Under-building is the bigger one. A Harvard Business Review Analytic Services study with Cloudera found that only 7% of organizations say their data is completely ready for AI adoption, while more than a quarter (27%) say it is not very or not at all ready.
Frequently asked questions about context graph vs. knowledge graph
Permalink to “Frequently asked questions about context graph vs. knowledge graph”How long does it take to extend a knowledge graph into a context graph?
Permalink to “How long does it take to extend a knowledge graph into a context graph?”It depends on how much substrate you already have, and most of the work is additive rather than a rebuild. Teams that enrich metadata by hand often spend 9 to 12 months on it. Context Agents compress that to weeks by generating descriptions, linked terms, metrics, and domain tagging from lineage, SQL, and transformations, which leaves governance nodes, temporal qualifiers, and runtime exposure as the pieces that still need human review.
What is the difference between a context graph and a data catalog?
Permalink to “What is the difference between a context graph and a data catalog?”A data catalog inventories what data exists and where it lives. A knowledge graph models how entities relate. A context graph adds the runtime layer on top: how decisions were made, what was true when, and what policy governs an agent’s next action. A catalog is a foundation a context graph builds on.
How does a context graph differ from a metadata graph?
Permalink to “How does a context graph differ from a metadata graph?”A metadata graph models metadata objects such as datasets, columns, and dashboards, which is what most modern catalogs already do. A context graph extends that with decision traces, temporal validity, and policy nodes meant for runtime traversal by agents. The metadata graph is the noun layer; the context graph adds the verb layer.
What are decision traces in a context graph?
Permalink to “What are decision traces in a context graph?”A decision trace is a structured record of how a specific decision was made. It captures the inputs gathered, the policies applied, the exceptions granted, the approvers, the timestamp, and the outcome, modeled as a traversable graph path. The underlying graph technique is reification; decision trace is the term the field has adopted for it.
Do I need both a context graph and a knowledge graph?
Permalink to “Do I need both a context graph and a knowledge graph?”Not always. A knowledge graph alone is enough for static taxonomies, single-domain semantic modeling, and cases with no autonomous agents. A context graph becomes necessary when AI agents make policy-sensitive decisions, when precedent spans multiple systems, or when regulated decisions require provenance and approvers on the record.
Is a context graph the same as a context layer?
Permalink to “Is a context graph the same as a context layer?”No, though the terms get used interchangeably. A context graph is the data structure that stores decisions, lineage, and policy over time. A context layer is the architectural slot that structures occupy between knowledge and runtime. One is the thing; the other is where the thing sits in the stack.
What software do I need to build a context graph?
Permalink to “What software do I need to build a context graph?”You need a graph substrate (a knowledge or metadata graph), a way to model policies and certifications as nodes, temporal validity on relationships, a runtime interface such as MCP, and active metadata to keep it fresh. Most enterprises already have the substrate in their lineage and glossary; the remaining pieces are governance, time, exposure, and continuous refresh.
Atlan’s approach: Enterprise Data Graph, Context Studio, and the MCP Server
Permalink to “Atlan’s approach: Enterprise Data Graph, Context Studio, and the MCP Server”Enterprises now need a governed context layer built on the metadata they already produce, rather than a graph modeled as a side project. Where a knowledge graph answers what is related to what, Atlan’s context approach answers what is true now, who approved it, what policy applies, what changed, and what an agent is allowed to do next.
Five capabilities map to the context-graph requirements:
- Enterprise data graph unifies metadata from 80+ connectors, including assets, lineage, policies, glossary, quality, and ownership, into one traversable graph.
- Context agents solve the cold-start problem by generating descriptions, linked terms, metrics, synonyms, and domain tagging from lineage, SQL, BI, and transformations.
- Context engineering studio lets teams bootstrap, test, refine, and ship the business context that AI use cases depend on.
- MCP server serves a governed context to Claude, ChatGPT, copilots, and agent frameworks through a standardized interface.
- Context lakehouse provides an Iceberg-native, open, graph-and-file architecture built for AI context storage and retrieval.
The runtime payoff is the Atlan AI Labs result already cited: at least a 38% accuracy lift across 522 evaluations, and up to 5x in customer workshops. At CME Group, teams cataloged over 18 million assets and more than 1,300 glossary terms in their first year on Atlan, the kind of governed substrate a context layer reads from.
Workday builds AI-ready semantic layers with Atlan's context infrastructure
"As part of Atlan's AI Labs, we're co-building the semantic layers that AI needs... All of the work that we did to get to a shared language amongst people at Workday can be leveraged by AI via Atlan's MCP server."
Joe DosSantos, Vice President of Enterprise Data & Analytics
Workday
Learn how Workday turned context into culture
Watch Now →
Nasdaq powers AI governance with unified metadata context
"The implementation of Atlan has also led to a common understanding of data across Nasdaq... This is like having Google for our data."
Michael Weiss, Product Manager
Nasdaq
Learn how Nasdaq cut data discovery time by one-third
Watch Now →Book a demo to see how Atlan delivers a context layer for AI.
Book a Demo →