← Research

Research · Sep 6, 2026

The context graph is not a knowledge graph

Agents fail on stale, contradictory, and polluted state—not on a shortage of documents to retrieve.

Shikhar Mishra · Co-Founder & CEO, EGI

Context graphs and knowledge graphs solve related but distinct problems. A knowledge graph represents entities and relationships for query and retrieval. An execution context graph additionally tracks which records, policies, and workflow positions are current and eligible at a specific action checkpoint.

Many production failures originate in stale, contradictory, or over-broad state rather than missing documents. A superseded vendor record can produce a well-cited but incorrect action; a session-wide vector preload can obscure the policy relevant to the current checkpoint. Persisting all model output does not solve this problem because useful memory requires freshness and eviction.

State, not a library

EGI’s context graph is continuously refreshed enterprise state across structured and unstructured systems. It is the common context layer in the architecture: a lean, tenant-scoped index of entity handles, policy refs, and workflow position—not an embed-everything corpus and not a session-wide preload.

Three lifecycle operations matter. Addition brings new operational signals into the graph. Updating replaces superseded owners, inventory positions, and approval thresholds. Eviction removes context that is invalid, outside policy, or no longer relevant to the active workflow step.

A context graph needs explicit addition, update, and eviction semantics. Without eviction, stale records remain eligible for future actions.

RAG can supply documentary evidence, but execution also needs current tenant state and an explicit policy boundary. EGI’s binding gate resolves a narrow slice at the checkpoint—such as one record, clause, or workflow position—and releases it after use. State is hydrated at execution time rather than preloaded for the full session.

Why this is the difference on ERP

ERP workflows expose state errors quickly. Entity assignments change, purchase orders expire, receipts alter inventory before every downstream ledger is synchronized, and vendor terms can lag contract amendments. A static representation of the purchasing process can still allow a posting to the wrong subsidiary, at a superseded price, or into a locked period.

Bruce uses process documentation as evidence, not as operational state. At each checkpoint it resolves which records are live, which tools are permitted, which policy applies, and whether a prior action already changed the ERP. The context graph supplies that state to the execution graph.

A graph without production-backed addition, update, and eviction can still support search and analysis. It is not sufficient as the state layer for controlled execution.

Enterprise execution agent

Bruce

The model is a dependency. Bruce is the agent that keeps the job correct—intent through completion on messy, heterogeneous ERPs. The serious work is posting, receiving, and closing.

Related