Knowledge Graphs for AI Agents: The Retrieval Architecture That Makes Context Real

Knowledge Graph Practitioner’s Guide: Overview | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 | Part 9 | Part 10 | Part 11a | Part 11b | Part 11c | Appendix A | Appendix B | Appendix C | Part 12

The Research Agent That Cited An Unverified Note

Apex Capital Partners is an illustrative composite, a mid-size US asset manager drawn from publicly documented agent-deployment failure patterns rather than a single real firm. In the scenario, Apex deployed a research-analyst agent in late 2025. The agent was meant to answer questions like “what is the current exposure to suppliers of Counterparty X across the global investment-grade book, and which of those exposures changed in the last quarter.” On a clean test set, the agent looked impressive. It found the right counterparty, surfaced the right exposures, and generated a coherent summary with citations. The portfolio managers approved it for limited rollout in February 2026.

In April, a portfolio manager asked the agent a routine question about a German industrial supplier and got a confident answer that named a specific 2024 acquisition, citing the agent’s source as an internal counterparty research note. The acquisition had not happened. The “internal note” the agent cited was a draft pitch deck that an associate had uploaded to the team’s research drive eighteen months earlier and never finalized. It was sitting in the same vector index as the audited counterparty profiles. Vector similarity surfaced it because it used most of the same vocabulary as the audited profiles. The agent had no way to know that the audited profile was gold and the draft deck was bronze. It treated both as evidence and gave equal weight to both. The portfolio manager almost made a position change on the basis of a fact that did not exist.

The post-mortem at Apex Capital was familiar from the data quality problem in AI agents article and from the missing quality layer piece. The retrieval pipeline did exactly what it was built to do. It returned semantically relevant chunks. It had no model of which chunks were entities, which were relationships between entities, which had been audited, which were drafts, or how they connected. The retrieval surface was a flat similarity score. The agent above it was being asked to do reasoning that the retrieval surface could not support.

Apex Capital’s incident is the single most important reason knowledge graphs have moved from optional to architectural for production agents in 2026. Vector retrieval and long context together solve a different problem from the one most agents actually face. They solve “find me a relevant passage.” They do not solve “give me the entities, the relationships between them, the trust tier of each piece of evidence, and the audit trail behind every fact.” That second job is what a knowledge graph does, and it is the job an agent has to do every time it answers a non-trivial question.

The Ceiling That Vector RAG and Long Context Cannot Raise Together

Three results from 2023-2025 set the ceiling that pure vector retrieval and pure long context cannot raise together.

First, the Lost in the Middle result (Liu et al., TACL 2024). Models attend well to the start and end of context but poorly to the middle. In multi-document question answering with twenty documents, accuracy dropped by more than thirty percent when the relevant document was placed in positions five through fifteen compared to position one or twenty. This is not a cache miss. It is the model itself failing to use information it was given.

Second, the Chroma Context Rot research (2025). Across eighteen frontier models including GPT-4.1, Claude Opus 4, and Gemini 2.5, every model exhibited performance degradation at every input length increment tested. More tokens in produced worse output, even when the model’s window was nowhere near full. The mechanism is a combination of attention dilution (transformer attention is quadratic in sequence length, so a hundred thousand tokens carries ten billion pairwise relationships), distractor interference (semantically similar but irrelevant content actively misleads the model), and the lost-in-the-middle effect. As a practical matter, throwing more context at the agent is not a free quality win.

Third, the retrieval shift analysis summarized the cost side of the same trade. Stuffing two hundred thousand tokens into a single query costs roughly fifty times more than targeted retrieval, narrowed to about five times after prompt caching, but the quality penalty (the thirteen to eighty-five percent degradation as context grows) does not go away. Long context is a useful tool. It is not a substitute for selective retrieval.

Pure vector RAG hits a different but related ceiling. Vector similarity returns chunks that are individually relevant. It does not capture how they connect. The Neo4j multi-hop analysis and the 2026 Singlestore comparison report the same finding from production deployments: vector RAG performs well on single-hop queries and on queries that ask for detailed information from a single source, and fails on questions that require traversing relationships between entities. “Which suppliers of Counterparty X have we increased exposure to since the last quarter” is a three-hop query that vector similarity cannot answer reliably no matter how many chunks it returns.

The structural gap is clean. Multi-hop queries need a structure that exposes entities, relationships, and the paths between them. Long context can hold the structure but cannot reliably reason over it. Vector similarity can find pieces but cannot connect them. A knowledge graph is the data structure that closes the gap.

Retrieval mode	What it does well	Where it fails
Pure vector RAG	Single-hop relevance, document recall, fast index, low cost	Multi-hop reasoning, entity disambiguation, relationship traversal, provenance
Pure long context	Single-pass reasoning over a coherent document, no retrieval cost	Cost at scale, lost-in-the-middle, context rot, no provenance, no audit trail
Pure graph traversal	Multi-hop, exact entity match, traversable provenance	Recall against unstructured corpora, sensemaking over many entities
Hybrid (graph + vector + selective long context)	Each layer used where it dominates	Higher engineering complexity; needs governance

The 2026 production answer is the bottom row. The interesting question is not which layer wins. It is how the layers compose, which is what GraphRAG and its descendants address.

What a Knowledge Graph Adds Specifically for an Agent

Four properties of a knowledge graph map directly onto the four problems that pure retrieval cannot solve.

Property	What the agent gets
Entity identity (IRIs from Part 5)	A canonical handle for “Counterparty X” that survives spelling variants, language variants, ingest cycles, and merger renames
Typed relationships (vocabulary from Part 4)	A precise model of how entities connect (hasSupplier, ownedBy, holdsExposureTo) so multi-hop queries become graph traversals rather than chunk searches
Provenance and trust tiers (from Part 7)	Per-triple metadata that lets the agent know whether a fact is gold, silver, bronze, or quarantine before it cites it
Versioned, time-aware state (from Part 8)	The ability to answer “what did we know about Counterparty X on April 4” without rebuilding the past from logs

Each of these is something a vector store cannot provide and a long context cannot reliably reconstruct from chunks. Together, they turn the retrieval surface from a list of similar passages into a structured, traversable, auditable substrate that the agent can reason against.

This is the core thesis of the article. The question is not “should we use a knowledge graph for our agent.” The question is “which slices of our agent’s retrieval surface need entities, relationships, provenance, and time, and how do we layer those slices behind the agent’s prompt.” For Apex Capital, the answer was: the counterparty surface absolutely, the regulatory filings probably, the unstructured research drive selectively. The fix to the April incident was not a better vector index. It was an entity-resolved counterparty graph with trust tiers, behind a retrieval planner that consulted the graph first and the vector store only for evidence the graph could not provide.

The GraphRAG Family: From Microsoft to LightRAG to HippoRAG 2

GraphRAG, in the broad sense, is any retrieval architecture that uses a knowledge graph as part of the retrieval surface for an LLM. The pattern was popularized by Microsoft Research’s “From Local to Global” paper (Edge et al., 2024) and has since spawned a family of production variants with materially different cost and capability profiles.

Microsoft GraphRAG

The original Microsoft GraphRAG pipeline is a four-stage process. First, slice an input corpus into TextUnits. Second, use an LLM to extract entities, relationships, and key claims from each TextUnit and assemble them into a knowledge graph. Third, run hierarchical clustering with the Leiden algorithm to discover communities at multiple resolutions. Fourth, generate community summaries from the bottom up so each community has a human-readable description.

At query time, the architecture supports two primary modes. Local search answers questions about specific entities by traversing the graph from a seed entity outward. Global search answers sensemaking questions across the whole corpus by map-reducing community summaries: each community summary answers the query in parallel, then a final pass synthesizes the partial answers. The 2024 paper reports that on million-token corpora (podcast transcripts and news datasets), global GraphRAG achieves comprehensiveness win rates of seventy-two to eighty-three percent and diversity win rates of sixty-two to eighty-two percent against vector RAG baselines. The cost trade-off is real: indexing a 500-page corpus with full Microsoft GraphRAG runs roughly fifty to two hundred dollars and forty-five minutes, per the 2026 production comparison.

LightRAG

LightRAG (Guo et al., 2024) is the cost-optimized variant. Instead of building hierarchical communities and pre-summarizing each one, LightRAG builds a simpler entity-relationship graph and uses a dual-level retrieval (low-level for entity-specific queries, high-level for thematic queries). The result is roughly six thousand times lower indexing cost than Microsoft GraphRAG on equivalent corpora. The 500-page corpus that costs fifty to two hundred dollars to index in Microsoft GraphRAG indexes in LightRAG for around fifty cents in three minutes. The trade-off is that LightRAG does not produce the rich global-summary capability that Microsoft GraphRAG does. For agents that primarily ask local entity-centric questions, LightRAG is the better fit.

LazyGraphRAG

In late 2024, Microsoft Research released LazyGraphRAG as a counterpoint to its own original. LazyGraphRAG defers the expensive LLM-based summarization step until query time. Indexing cost is identical to vector RAG (effectively free at the LLM layer). The query-time cost is roughly seven hundred times lower than Microsoft GraphRAG’s global search while matching its answer quality on the published benchmarks. In Microsoft’s reported evaluation, LazyGraphRAG won all ninety-six pairwise comparisons against GraphRAG (Local, Global, and Drift Search), against vector RAG with eight-thousand and 120-thousand-token windows, and against three published methods (LightRAG, RAPTOR, TREX). The architecture deliberately treats indexing as cheap and query as where the LLM budget goes.

HippoRAG and HippoRAG 2

HippoRAG (Gutiérrez et al., NeurIPS 2024) takes a different inspiration: human long-term memory and the role of the hippocampus in indexing memories for later retrieval. The architecture builds a dual-node graph (passage nodes and phrase nodes) and runs Personalized PageRank from query-derived seed entities to score retrieval candidates. The PageRank step is the analog of the hippocampal pattern-completion process. HippoRAG 2 (2025) extends this with an LLM-based triple filter and improved context integration. On the MuSiQue multi-hop QA benchmark, HippoRAG 2 reaches 48.6 F1 versus 45.7 for the strongest embedding baseline (NV-Embed-v2) and lifts Recall@5 from 69.7 to 74.7 percent, with associative QA F1 up roughly seven points over state-of-the-art embedding retrievers (see Table 2 of the paper). Indexing uses roughly 9 million versus 115 million LLM tokens (HippoRAG 2 versus the LLM-assisted extraction pipeline) on MuSiQue. HippoRAG 2 is the strongest published academic result for retrieval that needs both single-hop accuracy and multi-hop traversal.

Picking the right variant for an agent

The four variants are not interchangeable. The picking dimensions are corpus size, query mode (local vs global vs mixed), indexing budget, and query-time budget.

Variant	Best for	Indexing cost	Query cost	Trade-off
Microsoft GraphRAG	Sensemaking over large corpora; “tell me the key themes of these ten thousand documents”	High (LLM-heavy summarization)	Moderate	Best global answers; high indexing budget
LightRAG	Entity-centric retrieval; cost-sensitive deployments; agents that ask local questions	Very low	Low	Loses global sensemaking quality
LazyGraphRAG	Mixed local/global with cost discipline; one-off queries on large corpora	Free at LLM layer	Low to moderate	Higher per-query latency than pre-indexed alternatives
HippoRAG 2	Multi-hop QA where benchmark accuracy is the priority; research-grade agent retrieval	Low (LLM-light)	Low	Newer ecosystem, fewer production deployments

Apex Capital’s fix used a hybrid. The counterparty subgraph (entities, ownerships, exposures) was built with deterministic R2RML mappings from the structured systems, then enriched with a lightweight LLM-assisted entity-relationship extraction pipeline (see Appendix A for the specific tools) over the unstructured research drive, with provenance per triple and trust tiers per source. Global sensemaking (“what are the themes in last quarter’s research notes”) was answered with a small community-summary overlay on the unstructured layer only. The agent’s retrieval planner consulted the structured graph first; vector retrieval was a fallback for evidence the graph did not have.

Agent Memory: Four Layers, One Knowledge Graph Underneath

The retrieval architecture is half of the agent’s relationship with a KG. The other half is memory. An agent that runs for more than a single conversation eventually needs to remember things across sessions, learn from past interactions, and accumulate skills. The reference framework here is CoALA: Cognitive Architectures for Language Agents (Sumers, Yao, Narasimhan, Griffiths, 2024), which formalizes four memory types for LLM agents.

Memory type	What it holds	Lifetime	Where it lives
Working memory	Current conversation, current tool results, current scratchpad	Single agent run	The prompt (the context window)
Episodic memory	Records of specific past events, conversations, tool calls, decisions	Hours to years	External store, retrieved on demand
Semantic memory	Generalized factual knowledge: who is whom, what owns what, what implies what	Indefinite	External store, queried on demand
Procedural memory	Skills, learned routines, behavioral instructions	Indefinite	A mix of weights (implicit) and prompts/code (explicit)

The CoALA framing is helpful because it stops the conversation at “we need agent memory” and forces the question “which kind of memory, on what cadence, with what consolidation rules.” Each kind has a different storage substrate, a different retrieval pattern, and a different relationship with a knowledge graph.

Working memory is straightforward. It lives in the prompt, it is bounded by the model’s context window, and the long-context literature already discussed (lost-in-the-middle, context rot) constrains how big it can usefully grow. The KG is not directly involved here, except as the source of structured snippets that get injected into the prompt for the current turn.

Episodic memory is where most production agent-memory frameworks (Letta, Mem0, Zep) put the bulk of their engineering. In a KG-backed implementation, an episode is a node in a session subgraph: timestamps, participants, tool calls, decisions. Episodes carry their own provenance, and they typically have weaker trust tiers (silver or bronze) than ground-truth semantic facts (gold). An agent that has just been asked “did we discuss Counterparty Y last week” performs episodic recall, which is a graph query against the session subgraph filtered by valid time and participant.

Semantic memory is where the heart of the KG sits. Counterparty X is an entity; its industry classification, its parents, its subsidiaries, its rated exposures, its FIBO type are all triples in the semantic subgraph. Semantic memory has the strongest identity discipline (every entity has a stable IRI from Part 5), the most rigorous provenance (the seven-field contract from Part 8), and the highest trust tiers when sourced from gold systems. When the agent asks “who owns Counterparty X,” it is performing a semantic recall.

Procedural memory is the most under-engineered layer in 2026 production agents. Some of it lives in the model’s weights (the LLM “knows” how to write SQL because it was trained to). The rest lives explicitly: in tool descriptions, in prompt templates, in chains of behavior, and increasingly in skill libraries (the Letta skills model is a worked example). A KG can capture procedural memory by representing each skill as an entity with preconditions, postconditions, tools used, and success/failure history. This is closer to research than production for most teams, but it is the direction the frontier is moving.

The lift from CoALA’s framing is that all four memory types can share a single semantic backbone. The KG is the substrate. Working memory is what gets pulled into the prompt for the current turn. Episodic memory is the session-level subgraph. Semantic memory is the curated, provenance-bearing entity-relationship graph. Procedural memory is the skill subgraph. The retrieval planner picks which slice to consult per query.

What this looks like in practice. When an agent’s response surprises you, the diagnostic is to ask which memory layer produced it. If the answer is “working memory” (the agent had the fact in the prompt), the question is about prompt assembly. If the answer is “episodic” (the agent recalled a past conversation), the question is about episode storage and recall. If the answer is “semantic” (the agent used a curated fact), the question is about graph quality and trust tier. If the answer is “procedural” (the agent followed a learned routine), the question is about skill management. Conflating these layers makes incidents hard to triage.

The Production Memory Frameworks: Letta, Mem0, Zep/Graphiti

Three open-source frameworks dominate the 2026 production memory landscape. They make different architectural bets, and the choice between them is consequential.

Letta (formerly MemGPT)

Letta is the production evolution of MemGPT. Its core abstraction is “the LLM as an operating system,” with a tiered memory architecture inspired by the OS memory hierarchy. Core memory lives in the context window like RAM. Recall memory is searchable conversation history outside context, like a disk cache. Archival memory is long-term storage queried via tool calls, like cold storage. The agent itself manages memory through tool calls (read, write, search, archive). Letta’s recent direction is toward git-backed memory and skill packages, making procedural memory first-class.

Letta’s bet is that memory is best modeled as the agent’s editable state, with the agent managing its own paging operations. The framework is model-agnostic and treats the KG (when used) as the underlying store rather than the central abstraction. For agents whose memory pattern is “remember this conversation, surface relevant past conversations, accumulate behavioral skills,” Letta is the strongest fit.

Mem0

Mem0 takes a different architectural bet: a dual-store hybrid (vector + graph) with an LLM-driven extraction step that decides what to remember from each conversation. The vector store handles semantic similarity recall; the graph store captures entity relationships explicitly. Mem0’s strength is operational: it is the lowest-friction managed service for adding memory to an existing agent, and the State of AI Agent Memory 2026 report positions it as the fastest path to production. The trade-off is that Mem0’s graph layer is an enrichment, not the primary substrate. Teams that want graph-first memory typically reach past Mem0 to Zep/Graphiti.

Zep / Graphiti

Zep’s Graphiti engine is the strongest 2026 example of a graph-first memory system. Every fact stored is a node in a temporal knowledge graph with valid-time and transaction-time annotations (the bitemporal pattern from Part 8). When a fact changes (“Kendra now prefers Adidas, not Nike”), the old fact is not overwritten; it gets a validTo timestamp and the new fact is asserted with a new validFrom. Queries can answer “what was true at time T,” not just “what is true now.” On the LongMemEval benchmark with GPT-4o, Zep scores 63.8% versus Mem0’s 49.0%, a fifteen-point gap driven specifically by the temporal model. Graphiti is the right choice when the agent’s domain has facts that change meaningfully over time and the agent has to reason about that change.

Framework	Memory model	KG role	Best fit
Letta	OS-paging tiers (core, recall, archival), agent-managed	Optional underlying store	Conversational agents with skill accumulation; OS-style memory control
Mem0	Dual-store (vector + graph), LLM-driven extraction	Enrichment layer alongside vector	Fastest path to production; semantic search with light graph augmentation
Zep / Graphiti	Temporal knowledge graph, bitemporal facts	Primary substrate	Domains where facts change over time; temporal queries are first-class

Apex Capital’s research-analyst agent is now backed by Graphiti for episodic and semantic memory because the counterparty domain has facts that change meaningfully (ownership, ratings, exposure positions) and the agent needs to answer “what did we know on April 4.” For agents whose domain is more stable (a customer-service agent for a stable product line), Mem0 or Letta would be better matches.

Trust-Tier-Aware Retrieval: The 2026 Pattern That Prevents the Apex Incident

The single most important pattern in 2026 KG-for-agent architecture is the one that would have prevented the Apex Capital incident. The pattern has a name in this series: trust-tier-aware retrieval. It is the operational extension of the four-tier trust pattern from Part 7 (gold, silver, bronze, quarantine) to the agent’s retrieval surface.

The mechanics are straightforward. Every triple in the graph carries a trust tier (the seven-field provenance contract from Part 8 includes the trust tier as a first-class field). Every retrieval call from the agent specifies, explicitly, the maximum tier of evidence it will accept and how to handle multiple tiers in the result set. Three policies dominate.

Policy	Rule	When it fits
Strict-tier-floor	Only return evidence at or above tier T (e.g., gold-only for regulatory reports; gold+silver for portfolio decisions)	High-stakes outputs where lower-tier evidence is unacceptable
Tier-segregated context	Return evidence at all tiers but inject into the prompt with explicit tier labels and instructions to weight gold over silver over bronze	Exploratory queries where bronze evidence is useful as signal but must not be cited as fact
Tier-explicit-citation	Return any tier, but require the agent to surface the tier alongside every cited fact in its response	User-facing surfaces where the human can judge tier-by-tier

The Apex Capital fix used strict-tier-floor for any answer that named a specific transaction, ownership relationship, or exposure (gold-only). It used tier-segregated context for thematic questions (“what are the major risks in our European industrials book”), with bronze drafts allowed but explicitly labeled. The agent’s response template was rewritten to surface the tier of every cited fact. The April incident specifically would have been blocked at retrieval time by the strict-tier-floor policy: the draft pitch deck was bronze, and the question (“when did Counterparty X acquire Z”) triggered the gold-only path.

The pattern is enforceable in three layers, and good production deployments enforce all three.

Layer	Enforcement
Retrieval planner	The planner emits SPARQL or Cypher that filters by trustTier predicate; bronze content is structurally excluded for gold-only queries
Prompt assembly	If lower-tier content reaches the prompt (under tier-segregated policy), it is wrapped in a labeled block: <bronze-evidence>...</bronze-evidence>
Response post-processing	The agent’s answer is parsed for cited facts; each fact is checked back against the source tier; mismatches block the response

The third layer is what prevents the failure mode where the agent reads bronze and emits gold-sounding citations. It is also the layer most teams skip first, which is why most agent-with-KG deployments still have an Apex Capital incident in their first eighteen months.

For practitioners: If your agent does not currently know which tier a fact came from, your agent will eventually cite a bronze fact as if it were gold. The fix is not “more careful prompting.” It is to make the trust tier a first-class field on every retrieval and to fail closed when the tier does not meet the policy. Bronze is not the enemy. Bronze that escapes its tier is.

When You Do Not Need a Knowledge Graph for Your Agent

It would be a mistake to read this article as “every agent needs a knowledge graph.” Two patterns survive without one in 2026.

The first is the small-corpus pattern that Andrej Karpathy described in April 2026 for his personal research system. At roughly four hundred thousand words (around five hundred thousand tokens), Karpathy reports that his LLM “compiles” a wiki of summaries, concept articles, and backlinks, and answers queries directly against the wiki without RAG infrastructure. The pattern works because the corpus is small enough to fit in modern long-context windows, the wiki structure substitutes for the explicit graph (the LLM-maintained backlinks act as relationships), and the user is the only consumer (so trust tiers and audit trails are not load-bearing). This is a real architecture, not a toy. It is also genuinely small. It does not generalize to enterprise corpora at the millions-of-documents scale, and it does not survive the moment a regulator or auditor asks “where did this number come from.”

The second is the single-source agent that retrieves from one well-curated, well-structured store. A customer-service agent that answers from a single knowledge base with a single trust tier and no multi-hop questions does not need a KG. The cost of building one would not pay back. Vector RAG with prompt-cited sources is the right architecture.

The KG-for-agents architecture earns its complexity when at least three of the following are true: the corpus is large and heterogeneous; the questions require multi-hop reasoning across entities; the answers must be auditable; the underlying facts change over time; the evidence comes from sources with different trust tiers; the agent runs long enough that episodic and semantic memory diverge meaningfully. If only one or two of those is true, the simpler architecture is the right architecture. The series is for the cases where five or six of them are true, which is most enterprise-scale agent deployments.

Seven Failure Modes That Show Up in KG-for-Agent Deployments

Each of these has been observed in production deployments reported in the 2025-2026 GraphRAG and agent-memory literature, including Microsoft’s VeriTrail provenance work and the Atlan ai-memory-vs-rag analysis.

Failure	What it looks like	Root cause
Trust-tier laundering at retrieval	Agent confidently cites bronze evidence as if it were gold (the Apex Capital incident)	Retrieval surface treats all evidence as a flat similarity score; tier metadata not propagated
The chunk-shaped graph	The graph was built by extracting entities from chunks, so the graph’s “entities” are really chunk fragments; no entity resolution behind them	Construction skipped the entity-resolution stage from Part 5; the graph looks structured but is not
Schema-drift-induced hallucination	The ontology was renamed in a refactor (the Part 8 Sentinel Mutual incident); the agent’s prompts still bind to old terms; queries return empty; agent confabulates	No data contract between the agent and the KG; ontology version not pinned
Over-retrieved context	The retrieval planner returns hundreds of triples for safety; the prompt overflows; the lost-in-the-middle effect destroys answer quality	No retrieval budget; no relevance ranking inside the graph result set
Stale episodic memory	Agent recalls facts from past sessions that have since been corrected in the underlying source; episodic memory was not bridged to semantic-memory updates	No invalidation flow from semantic memory to episodic memory; episodes treated as immutable
Multi-hop blow-up	A traversal that should be three hops becomes seven because the graph has too many weak edges (LLM-extracted relationships without provenance discipline)	Construction emitted relationships without confidence scores; retrieval did not prune low-confidence edges
Missing audit trail at the agent boundary	The agent’s response cites facts; the human cannot trace the citation back to a source; regulator finding	No PROV-O chain at the response surface; the agent emits prose, not citation IRIs

The pattern across all seven is the same as the failure pattern of pre-agent KGs from Part 8: the metadata that production needed was not made first-class in the architecture. The fix in every case is to push the missing metadata down into the retrieval, memory, or response substrate so that policy can be enforced mechanically rather than relied on as discipline.

A Decision Tree for the Agent-KG Layer

Use this when you are scoping or reviewing an agent that will retrieve from (or write to) a knowledge graph.

1. What is the smallest question your agent must answer that vector RAG and long context together cannot answer? If you cannot name one, you do not need a KG yet. If you can (multi-hop, multi-entity, multi-tier, multi-time), continue.
2. Which slice of your retrieval surface needs entities and relationships, and which slice can stay as vector chunks? Most production architectures are hybrid; do not graph the whole surface. Graph the slice where multi-hop matters.
3. Are your entities resolved before they enter the graph? If construction extracts entities from chunks without ER (the Part 5 discipline), the graph will be a chunk-shape graph. Block the deployment until ER is in place.
4. Does every triple carry a trust tier? If not, your agent will laundered-tier eventually. Add the tier as a first-class field before any agent goes to users.
5. Which GraphRAG variant matches your cost and query mix? Microsoft GraphRAG for sensemaking with budget; LightRAG for entity-centric and cost-sensitive; LazyGraphRAG for mixed with cheap indexing; HippoRAG 2 for multi-hop accuracy where the ecosystem maturity is acceptable.
6. Which CoALA memory layers does your agent need? Working only (the prompt) covers single-conversation use cases. Working + semantic covers most enterprise agents. Working + semantic + episodic covers stateful, learning agents. Working + semantic + episodic + procedural is frontier.
7. Which memory framework matches your memory pattern? Letta for OS-paging tiers and skill accumulation; Mem0 for fast time-to-production with light graph augmentation; Zep/Graphiti for temporally rich domains.
8. What is your retrieval policy per query type? Strict-tier-floor for any answer that names a specific fact; tier-segregated for thematic; tier-explicit-citation for user-facing. Default to strict.
9. Does your retrieval planner enforce the tier policy in the query, the prompt, and the response post-processing? If only in the query, the agent will eventually escape the floor. Enforce all three.
10. Can your agent reproduce the same answer next month after the underlying source changed? If the answer is “no,” your agent has no audit trail. The bitemporal model from Part 8 plus PROV-O on every cited fact is the architecture that makes the answer “yes.”

A scoping document that has answers to all ten is a scoping document that production can absorb. A scoping document missing any one of them is a scoping document that will surface an incident later, usually in the form of a question from a regulator, an auditor, or a user who caught the agent in an avoidable mistake.

What This Article Did Not Cover

Three agent-KG topics deserve more depth than fits here.

• Agent-driven graph writes, where an agent does not just read from the KG but updates it. This crosses into the construction discipline from Part 6 (the three discipline points: fixed ontology, dedup/ER, SHACL gate) and the operations discipline from Part 8 (every write must preserve trust tier and provenance). The full treatment belongs in a follow-up piece on agent-as-knowledge-engineer patterns.
• Multi-agent retrieval coordination, where several agents share a graph and must coordinate read and write access without trampling each other. The multi-agent systems guide covers the coordination layer; the KG-specific concurrency patterns (per-agent named graphs, per-agent trust-tier views, conflict resolution at write time) are an open area.
• Cost modeling for KG-backed agents, where the indexing cost, query cost, and storage cost interact with usage patterns. Appendix B covers cost modeling; the agent-specific cost shape (where the agent’s read amplification and write amplification dominate) is its own topic.

This article has covered the retrieval architecture: why vector RAG and long context together hit a ceiling, what KGs add for agents specifically, the GraphRAG family (Microsoft GraphRAG, LightRAG, LazyGraphRAG, HippoRAG 2) and how to pick among them, the CoALA four-layer memory model and its KG mapping, the production memory-framework landscape (Letta, Mem0, Zep/Graphiti), the trust-tier-aware retrieval pattern that prevents the Apex Capital failure, and the seven failure modes that show up when any layer is skipped.

Do Next: Agent-KG Discipline Tier List

Priority	Action	Why it matters
Now (this quarter)	Audit your top three production agents for the one question vector RAG and long context together cannot answer. If you find it, scope a graph slice for that subdomain. Do not graph the whole surface.	Selective graphing is what works; whole-surface graphing is what stalls. The right unit of investment is the smallest slice where multi-hop matters.
Now (this quarter)	Add a trust tier as a first-class field on every fact your agent retrieves. If your agent currently has no tier metadata, fail closed on any high-stakes query until it does.	The Apex Capital incident is the failure mode you have not yet had. The fix is mechanical, not behavioral. Bronze that escapes its tier is the source of confident hallucination.
Next (next two quarters)	Pick a GraphRAG variant that matches your cost and query mix (Microsoft GraphRAG for sensemaking, LightRAG for entity-centric cost-sensitive, LazyGraphRAG for mixed, HippoRAG 2 for multi-hop accuracy). Resist the urge to deploy whichever one shipped first.	Cost differences are an order of magnitude across these variants. The wrong default burns budget for years.
Next (next two quarters)	Map your agent’s memory pattern onto CoALA’s four layers (working, episodic, semantic, procedural). Pick a memory framework that matches the pattern (Letta for OS-paging and skills, Mem0 for fast time-to-production, Zep/Graphiti for temporal facts).	”We need agent memory” is not a requirement; it is a category. Pick the layer and the framework deliberately, not because of the first vendor demo you saw.
Soon (next year)	Enforce trust-tier policy at all three layers (retrieval planner, prompt assembly, response post-processing). Block deployments that only enforce one.	Single-layer enforcement always leaks. Triple-layer enforcement is what survives a year of production.
Soon (next year)	Bridge episodic memory to semantic memory invalidation. When a semantic fact changes, mark dependent episodes as stale rather than allowing them to be recalled as if still true.	Stale episodic recall is the second failure mode after trust-tier laundering. It is the one that surfaces during a customer-service incident, not an audit.
Eventually (when stable)	Add a PROV-O citation chain at the agent’s response boundary. Every cited fact must be traceable from the response IRI back to its source IRI, through the activities that produced it.	This is the audit-trail discipline that VeriTrail and the broader provenance literature point at. Until it is in place, “show me where this came from” is a tribal-knowledge question.

Up Next

Part 10 turns from agents to governance. The same KG that holds entities, relationships, trust tiers, and provenance for the agent is also the substrate that holds lineage, CDEs, and master-data golden records for the Data Governance program. Part 10 covers Knowledge Graphs for Data Governance: lineage as a graph (with OpenLineage as the bridge), CDEs as a graph (re-framing the existing CDE meta-model series), MDM golden records as nodes, and the regulatory cross-walks that turn a governance KG into a defensible answer to “how do we know this number is right.”