Cassie Shum Lays Out Four Knowledge-Graph Patterns for Production AI Agents

The engineer argues that retrieval-augmented generation alone cannot ground agentic systems, and proposes context bundling, decision provenance, code as truth, and agent visibility as the fix.
Agentic AI systems are hitting a wall that plain retrieval-augmented generation was never built to clear, according to Cassie Shum, who presented a set of architectural patterns for grounding agents in knowledge graphs at an industry conference covered by InfoQ. Her argument is that once a model stops answering single questions and starts taking multi-step actions, the retrieval layer underneath it has to carry structure, not just text chunks. Shum walked through four patterns she says teams need before an agent can be trusted in production.
The first, context bundling, treats the unit of retrieval as a package of related facts rather than an isolated passage, so an agent receives the surrounding entities and relationships it needs to act without issuing a chain of follow-up lookups. That matters for token budgets as much as accuracy: fewer round trips to a vector store means less prompt bloat and lower latency per decision. Shum framed the knowledge graph as the place where those bundles are assembled and versioned, which turns retrieval into a repeatable engineering step instead of an ad hoc prompt trick.
Decision provenance is the second pattern, and it addresses a problem that grows as agents gain autonomy. When an agent chooses an action, the system records which graph facts informed that choice, producing an audit trail that survives beyond the session. For teams in regulated industries, that record is the difference between a demo and a deployable system, since it lets reviewers reconstruct why an agent did what it did without re-running the model.
The third pattern, code as truth, pushes executable logic out of the model and into deterministic code that the graph can reference. Shum's position is that anything an agent must get right every time, such as a calculation, a policy check, or a state transition, belongs in code rather than in a probabilistically generated answer. The fourth, agent visibility, covers what the agent can see about its own state and the state of the graph, which Shum ties to reliability: an agent that cannot observe the consequences of its last action cannot correct course.
Shum demonstrated an engineering harness built on top of a knowledge graph that ties these patterns together, using it to tighten feedback loops, cut token consumption, and keep behavior stable across runs. The harness is less a product than a reference architecture, but it points at a broader shift in how teams are treating the graph layer, as infrastructure for agent memory and control rather than a search index bolted onto a chatbot.
The open question is whether knowledge graphs can keep pace with the speed at which agent frameworks are changing, and whether teams will invest in graph maintenance when a larger context window looks like a cheaper fix. Shum's answer is that context windows do not provide provenance, and that the cost of a wrong action in production dwarfs the cost of curating the graph. Watch for whether the four patterns get adopted as a common vocabulary, or stay one engineer's framework.