From Knowledge Graphs to Context Graphs: The Next Evolution for AI Agents

Knowledge graphs have proven their value as a context layer for AI agents. Hybrid search — lexical, semantic, and structural — is now a production pattern at scale. Organisations run 45,000-node graphs on Community Edition instances, and every major platform ships a graph-backed offering for agent retrieval.

But retrieval of what exists is not the same as governing what is allowed, what was true at decision time, or what an agent actually did. The knowledge graph maps entities and relationships. The context graph adds four dimensions that production AI agents require: temporal validity windows, policy nodes, decision traces, and event-driven subgraph activation.

What Knowledge Graphs Do Today

A knowledge graph is fundamentally a map of facts. It answers "what is related to what":

// Find all products affected by a vulnerability
MATCH (v:Vulnerability {cve: "CVE-2026-1234"})-[:AFFECTS]->(p:Product)
RETURN p.name, p.version

This query works because the graph has been populated with entities and relationships extracted from documents, databases, or manual curation. The graph is a snapshot — it reflects the state of knowledge at the time of ingestion. Timestamps may exist as properties, but the graph model itself is static. Every edge asserts "this relationship holds" without necessarily specifying when it started, when it expired, or under what conditions it applies.

Vector RAG retrieves semantically similar text chunks. Graph-enhanced RAG traverses relationships to surface connected entities. Both operate over a frozen knowledge base. Neither encodes permissions, temporal scoping, or the provenance of past decisions. For a question-answering bot that references documentation, this is sufficient. For an autonomous agent that executes actions against live systems, it is dangerously incomplete.

What Context Graphs Add

A context graph extends the property graph model with four primitives that mirror the requirements of production agent systems:

Temporal Validity Windows

Every relationship carries an interval — a half-open range [valid_from, valid_until) that defines when the relationship was active in the real world:

// Create a context-graph edge with temporal validity
CREATE (a:Agent {id: "agent-iota"})
CREATE (s:Service {id: "payment-api", version: "3.2.1"})
CREATE (a)-[r:ACCESSES {
  valid_from: datetime("2026-03-01T00:00:00Z"),
  valid_until: datetime("2026-09-01T00:00:00Z"),
  granted_by: "iam-role/admin-binding",
  reason: "Production deployment phase 2"
}]->(s)

An agent querying this graph at runtime must include the current timestamp in its traversal. The graph engine filters out expired and not-yet-active edges automatically. This prevents an agent from acting on stale authorisations or attempting to use a service that has been decommissioned.

Policy Nodes

Policies are first-class nodes, not edge properties. They encode what is permitted, prohibited, or required for a given action on a given resource:

CREATE (p:Policy {
  id: "pol-pci-dss-11",
  type: "restriction",
  action: "EXFILTRATE",
  resource_pattern: "database:customers/*",
  condition: "env != 'prod-dr' AND NOT user.role IN ['sre', 'compliance']",
  priority: 100,
  enforcement: "HARD_BLOCK"
})

Context graph queries are rewritten at traversal time to intersect results with applicable policies. The agent never sees forbidden paths — the graph simply does not return them. This is the difference between asking "may I access this?" and having the graph enforce boundaries silently.

Decision Traces

Every agent action that produces a side effect is reified as a decision node with full provenance:

CREATE (d:Decision {
  id: "dec-20260704-8a3f",
  agent_id: "agent-iota",
  action: "DEPLOY",
  target: "payment-api:v3.2.1",
  timestamp: datetime("2026-07-04T14:32:11Z"),
  input_context_hash: "sha256:a1b2c3d4...",
  output: "success",
  evidence: [
    "policy/pol-pci-dss-11:allowed",
    "ticket/DEPLOY-8923:approved",
    "status/canary:healthy"
  ]
})

These nodes create an auditable chain of causation. Every agent decision is linked to the context that informed it — the policies that allowed it, the evidence that supported it, and the state of the world when it was taken. For compliance, debugging, and post-incident analysis, this is the record that matters.

Event-Driven Subgraph Activation

A context graph is not queried in isolation at a single point in time. It listens for events — deployment completed, vulnerability published, policy revoked — and activates or deactivates subgraphs accordingly. An edge with valid_until in the past is pruned from query results. A new ACCESSES edge created by an IAM event handler becomes visible to agents within seconds.

This dynamic activation enables the graph to serve as a live control plane rather than a static index. AWS launch notifications, Kubernetes admission webhooks, and CI/CD pipeline events all feed into the graph, which in turn re-shapes the context available to every agent in the system.

Why Agents Need This

The hallucination problem is often framed as a retrieval problem — give the model better documents and it will answer correctly. In practice, production AI agents fail for a different reason: they operate outside their permitted context.

An agent that can read any document, access any service, and act on any relationship will, given enough steps, attempt something the organisation did not intend. The boundary is not one of knowledge but of permission and temporal relevance.

Context graphs encode this boundary structurally. An agent traversing a context graph cannot reach a node or edge that is forbidden, expired, or irrelevant to the current operation. The graph does not return unauthorised paths, so the agent never picks them. There is no prompt engineering, no runtime guardrail, no post-hoc filter — the constraint is baked into the retrieval layer itself.

This is the architectural difference between a bot that answers questions and an agent that acts autonomously. Questions require facts. Actions require boundaries.

MCP as the Interface

The Model Context Protocol (MCP) is emerging as the natural transport layer for context graphs. Each context graph node can be exposed as an MCP resource with a URI pattern like context-graph://agents/agent-iota/decisions/{id} or context-graph://policies/pol-pci-dss-11.

MCP tools provide the temporal traversal operations that agents need:

MCP Tool	Purpose
get_context	Retrieve active context for an agent at a point in time
traverse_at_time	Graph walk constrained by a temporal validity window
query_decision_chain	Trace provenance from action to evidence to policy
subscribe_context	Receive real-time push when context subgraph changes

Streamable HTTP transport — the recently adopted MCP transport specification — supports server-sent events for the subscribe_context tool. When a deployment completes or a policy updates, the context graph pushes the delta to every subscribed agent. The agent's context window stays current without polling.

Real-World Convergence

The industry is already moving in this direction, even if the terminology varies.

Atlan ships what they call a "data context graph" that maps relationships across enterprise data assets with lineage and ownership. Their model enriches metadata with usage context — who accessed what, when, and why — approaching the decision-trace pattern.

DataHub (Acryl) extends metadata graphs with assertion-based lineage and access policies as first-class graph nodes. Their Policy Engine evaluates graph-encoded rules at query time, intersecting permissions with entity traversal.

TrustGraph is a deliberately designed policy-grounded context system. It models permissions, data sensitivity labels, and agent capabilities as graph nodes. Every traversal is mediated by policy evaluation — closer to the context graph model than any other production system.

Kore.ai and Tekst both maintain per-session agent context stores that track conversation state, retrieved evidence, and action history as relational or graph structures. Neither exposes the temporal and policy dimensions in the graph model itself, but the direction is clear: agents need structured, auditable context, not flat retrieval.

The Gartner Trajectory

Gartner's 2026 "Emerging Tech: AI Agent Context" report projects that more than 50% of enterprise AI agent systems deployed by 2028 will incorporate graph-based context models rather than flat vector stores or relational tables. The reasoning is practical: as agent autonomy increases — from read-only copilots to write-capable operators — the cost of context errors rises proportionally. Static retrieval cannot enforce boundaries; only a graph with temporal, policy, and provenance dimensions can.

Knowledge Graph vs Context Graph

Dimension	Knowledge Graph	Context Graph
Query model	"What entities are related?"	"What is relevant, permitted, and temporally valid now?"
Temporal modelling	Timestamps as optional properties	Half-open validity intervals as first-class edge attributes
Policy enforcement	External — applied via middleware or post-query	Structural — policies are nodes, traversal is policy-mediated
Agent integration	Retrieved chunks fed to LLM prompt	MCP resources + tools; agent traverses boundaries natively
Mutation handling	Batch re-ingestion	Event-driven edge activation/deactivation via Streamable HTTP
Decision audit	Logs outside the graph (if at all)	Reified decision nodes with provenance links within the graph
Consistency model	Eventual — snapshots reflect last batch	Near-real-time — state changes propagate to subscribed agents

The knowledge graph is not going away. It becomes the base layer — the map of entities and relationships that the context graph annotates with temporal validity, policy constraints, and decision provenance. The context graph is the control plane that rides on top. One maps what exists. The other governs what happens.