An AI agent needs more than retrieved paragraphs. It needs an inspectable map of the entities it may act on, how they relate, which sources support a claim and which transitions are permitted. A knowledge graph can provide that semantic control plane.
“Control plane” does not mean the graph executes every action. It means the graph exposes the relationships that inform and constrain orchestration, while tools and transactional systems continue to own their operational responsibilities.
Why Agent Context Becomes a Graph Problem
Agent decisions frequently depend on relations:
- this user belongs to this organization;
- this contract grants access to this product;
- this claim is supported by these sources;
- this task depends on two unfinished tasks;
- this asset is derived from an approved reference;
- this character knows one event but not another; or
- this tool is permitted for one agent role and prohibited for another.
A flat prompt can describe these facts, but it does not provide a durable, queryable representation. A property graph models entities as nodes, connections as typed relationships and attributes as properties. The agent can request the relevant subgraph for the current decision.
Five Control-Plane Functions
1. Entity resolution
The graph gives stable identity to records mentioned under different names. Before an agent acts on “the Acme renewal,” the system can resolve the organization, contract and current renewal case.
The model may suggest a match. Deterministic constraints or a reviewed resolution process should decide whether identities are merged.
2. Relationship-aware context
Vector similarity finds semantically related text. Graph traversal finds explicitly connected entities and paths. Combining both can answer: retrieve documents similar to the request, then follow their claims to sources, owners and affected assets.
This is the useful bridge to Graph RAG. Retrieval supplies evidence; the control plane preserves the domain relations needed for action.
3. Permission and policy context
Authorization often depends on relationships rather than a single role string. An agent may use a publishing tool only for assets owned by its team and only after a reviewer approved the current version.
The graph can represent those relations, but enforcement should occur in the tool gateway or policy engine. Never rely on the model to obey a graph fact merely because it appeared in context.
4. Provenance
Generated conclusions should remain connected to their evidence. A graph can represent:
(Claim)-[:SUPPORTED_BY]->(Source)
(Claim)-[:GENERATED_IN]->(Run)
(Run)-[:USED_MODEL]->(ModelVersion)
(Asset)-[:APPROVED_AS]->(Version)
This makes it possible to inspect why an agent believed something and which downstream artifacts may be affected if a source changes.
5. Transition constraints
Some actions are valid only when related conditions hold. A task can move to READY when every blocking dependency is complete. An asset can move to PUBLISHED only when its current version has approval.
The graph helps evaluate the condition. The production service still performs the validated transition and records the event.
The Reference Pattern
event or request
→ resolve domain entities
→ load current graph neighborhood and authoritative state
→ retrieve supporting evidence
→ agent proposes a permitted action
→ policy validates identity, relation and preconditions
→ tool changes external state
→ validator checks the outcome
→ graph and event log record the accepted transition
The agent never receives “the whole graph.” Context assembly selects the smallest relevant subgraph and labels its provenance and freshness.
What the Graph Should Not Own
Hidden model reasoning
Do not store private chain-of-thought as the decision graph. Store observable inputs, proposed actions, evidence, tool results and accepted transitions.
Every transient token
The graph is not a transcript dump. Keep high-volume traces in an observability store and promote only meaningful entities and events.
Transactional guarantees it cannot provide
A graph database may store operational state, but the architecture still needs explicit concurrency, consistency and failure semantics. A semantic relationship is not automatically a distributed transaction.
Automatically extracted claims as unquestioned truth
LLMs can generate knowledge graphs from documents by extracting entities and relations. That graph begins as derived knowledge. Preserve source links, confidence or review state before using a claim to authorize action.
Evidence Graph and State Graph
A useful design separates two related views:
- Evidence graph: documents, chunks, claims, entities and supporting relations.
- State graph: current entities, ownership, permissions, dependencies and accepted events.
They may share entity identifiers, but their write rules differ. Evidence can contain conflicting claims. State must resolve what the system currently accepts.
This is the same boundary explained in Graph RAG vs. Agent Memory vs. World State .
Minimal Graph Schema for an Agent
Start small:
(:Agent)-[:MAY_USE]->(:Tool)
(:Task)-[:DEPENDS_ON]->(:Task)
(:Run)-[:WORKS_ON]->(:Task)
(:Run)-[:PRODUCED]->(:Artifact)
(:Claim)-[:SUPPORTED_BY]->(:Source)
(:Artifact)-[:HAS_VERSION]->(:Version)
(:Reviewer)-[:APPROVED]->(:Version)
Add relations only when they support a real query, constraint or explanation. A large ontology is not automatically a better control plane.
The Architectural Payoff
With an external graph, the agent does not need to recreate the domain from a prompt on every run. Models can change while entity identity, provenance and permissions remain stable. Failures can be investigated as paths through observable events rather than explained through model intuition.
That is the core benefit: the graph turns important relationships from latent context into system-owned structure.