Context graph: what it is, how it differs from a knowledge graph, and how to build one an agent can trust

A context graph is a connected record of the facts an AI agent needs before it acts. The nodes are entities such as customers, accounts, systems, policies and people, and the edges are the relationships between them plus the decisions already taken. Each fact carries where it came from, when it was last true, and who may see it.

Key facts

Definition

A context graph joins company entities and the decisions already taken on them, and every fact carries its source, the date it was last true, and who may see it.

How Bigcircle does it

On DocVerse, Bigcircle keeps a knowledge graph next to vector search and checks a new filing against the knowledge base so a restatement shows up as a flag.
On Solarpunk, Bigcircle compares the agent's claimed completion with the state of the application, and plans completed with no person rose from roughly 55% to 80% once local retrieval and planner memory landed.
On Skionis, Bigcircle measured template errors before deploy falling from around 10% to 4% once a validation loop checked each template against the live account.

Comparison

A knowledge graph maps entities and the links between them, while a context graph adds provenance, freshness and permissions on every fact and is written back to as the agent works.

Key number

Google Cloud's own benchmarks for Knowledge Catalog, in its 29 October 2026 announcement of expanded semantic model support, put accuracy at nearly 4x, latency at up to 33% lower, and tokens at up to 75% fewer.

Bigcircle already builds those properties into the systems we ship. A claim without a citation does not appear, access is scoped to the person the agent acts for, and a check in code runs before a tool call leaves.

The run writes a trace rather than overwriting the record, and a context graph is those records joined so the agent can walk them instead of reconstructing the picture from a pile of tools.

Agents give wrong or unexplainable answers when that record is scattered. The CRM knows the account owner, a ticket system knows the open incident, a policy lives in a document, and a person remembers last quarter's exception. The agent reads one of those, or all of them without knowing which is current, and then acts.

On DocVerse, the ESG filing system we built, we already keep a knowledge graph next to vector search for this reason. Pure vector search cannot express "the same subsidiary two years earlier", and a graph alone cannot find a narrative claim that was never turned into a field.

We also check a new filing against what the knowledge base already holds, so a restatement shows up as a flag instead of as two figures that both look true.

This guide is the agent sense of a context graph. It covers what one is, how it differs from a knowledge graph, how an agent uses it in production, how to build it, and when to skip it. Metric definitions stay on the semantic layer for AI agents, graph-based retrieval stays on GraphRAG, and agent memory is the store one agent keeps about its own work.

What is a context graph?

Treat a context graph as the layer of company facts an agent reads before it acts, and writes back after. A node is a thing the business already cares about, such as a customer, an account, an open ticket, a policy or a person, and an edge is a relationship or a decision.

Every node and every edge keeps three tags: the source system, the date it was last true, and who may see it.

A small example is enough to see the shape. The customer and the account owner sit in the CRM. An open ticket sits in the helpdesk, and last week's exception sits in nobody's system until someone writes it down. Join those four and tag each one, and an agent can answer who owns this account, what is still open, and what we decided last time, without guessing.

The figure shows that path. Sources on the left feed one graph. The agent on the right reads source, date and permission before it acts, then writes the decision back as an edge rather than overwriting the record.

A context graph is not the CRM, and it is not a dump of documents into a prompt. It is not authorization for the action the agent wants to take, and it is not agent memory for one user's thread.

Gupta and Garg, writing at Foundation Capital in December 2025, named the missing piece decision traces: the exception, the override and the approval that never made it into the system of record. We already write that kind of record on the agents we ship. The graph is the decision to keep those traces on the same entities the agent reads.

Context graph vs knowledge graph

A knowledge graph maps entities and the links between them. A context graph starts from that map and adds the tags an agent needs before it can trust a hop: provenance, freshness, who may see it, and a place to write the decision back. Drop those tags and the agent has a map it cannot audit.

We learned the cost of a missing tag on DocVerse. The dangerous failure is a correct number under the wrong entity, period, unit or framework, and everything downstream then passes.

That is why we carry those four as hard metadata from parsing, and never infer them at query time. A context graph applies the same rule to every fact an agent might act on, not only to extracted filings.

	Context graph	Knowledge graph
Purpose	Facts an agent needs for a task, plus the decisions already taken	A map of entities and how they relate
Built for	Agents that read, act and write back	Search, analytics and people browsing a map
Provenance	On every fact	Optional, often added later
Freshness	When the fact was last true	Often omitted
Permissions	Inherited from the source, checked on the read	Often a separate layer
Write-back	Decision traces stay on the entities	The reader rarely writes
Typical store	A graph, tables, or both	Usually a graph database

Do not buy a graph database because the word graph is in the name. The shape that matters is the connection plus the tags, and on DocVerse we pair a graph with vector search because each fails alone. Document intelligence for agents is the longer account of that pairing on a filing packet. GraphRAG is the retrieval pattern that walks those links, and a context graph is the record that retrieval reads.

Neo4j, on its own account, splits a context graph into long-term enterprise knowledge, short-term interaction history, and reasoning memory. We keep those three jobs as properties of the same record rather than as three products. Long-term facts are the entities and links. Short-term state is the current task, and reasoning memory is the trace we already write per run.

How AI agents use a context graph in production

The loop is locate, traverse, check, act, write back. Locate the entities the task names, traverse the links that join them, and check source, date and permission on each hop. Act only through a tool that has already passed its own check. Write the decision back as a new edge rather than as an edit that erases what you believed yesterday.

Skip the check and the hop looks like knowledge, which is the DocVerse failure: a confident extraction of a correct number under the wrong metadata that then passes every later test. Check source and date on the hop, and a stale owner or a restated figure is visible before the agent drafts a reply. Check permission on the hop, and a fact the current user may not see never enters the prompt.

On Solarpunk, the desktop agent we built for executive operations, we stopped giving the model the whole tool registry. Each step queries it for the few contracts that step needs.

Plans completed with no person rose from roughly 55% to 80% once local retrieval and planner memory grounded the agent in the user's workspace. A context graph is the same move for company facts: the agent reads a few connected, tagged records instead of reconstructing them from a hundred tools.

On Google Cloud's own account, expanded semantic model support in Knowledge Catalog, generally available on 29 October 2026, puts Looker LookML, dbt MetricFlow, Snowflake Semantic Views, Databricks Metric Views and SAP CSN into one context graph. Those sit next to schema, lineage and glossary terms. Overlapping definitions stay side by side, each labeled with its source.

On its own benchmarks it puts accuracy at nearly 4x, latency at up to 33% lower, and tokens at up to 75% fewer. Use that as a dated example of the loop, not as a target to copy. The metric definitions themselves still belong on the semantic layer.

GitLab Orbit, generally available on 29 October 2026 on GitLab's own account, is a context graph over code, merge requests, pipelines, vulnerabilities and ownership. GitLab's own testing puts retries at up to 45x fewer and tokens at up to 4.5x fewer when the agent queries the graph instead of crawling files.

The useful part for a buyer is the loop, not the multiple. Ask the graph, check permission on the hop, then act.

Zep's docs put one graph per subject and access boundary, and keep external actions authorized separately, which is the split we already make. On a current engagement for a telecom marketing platform, we scope each agent to the entitlements of the person it acts for. Prompts stay a user-experience layer that no policy check depends on. The graph inherits that scope rather than replacing it.

How to build a context graph

Start with one domain and one access boundary, so a sales graph and a finance graph can share an account node and still refuse each other's tickets. Put unrelated subjects, or data with different access rules, in one graph and the permission tag becomes a hope.

Zep's docs make the same split. We make it because a shared agent that keys memory only by the tenant already leaks one person's facts into the next person's prompt, which is the failure AI agent memory isolation exists to stop.

Pick the sources the domain already trusts: systems of record, the documents document intelligence already parses, and the semantic models the semantic layer already owns. Do not recopy a metric formula into the graph; point at the owned definition.

Google Cloud's earlier preview, on 22 October 2026 on its own account, adds self-learning enrichment and Knowledge Studio. A person reviews proposed graph changes before they publish, and governed context sets sit per domain. Keep that review even if you never buy the product. A graph that updates itself without a steward will invent a join the business never agreed.

Resolve entities before you attach facts. Two CRM rows that look like one customer, or a filing entity that does not match last year's subsidiary, produce a coherent graph about the wrong thing. On Prospex, our own research engine, entity resolution is the failure that passes every later check, because the profile is well sourced and about the wrong human. Spend the time here, since everything downstream inherits the mistake.

Put provenance and freshness on each fact at write time. We carry entity, period, unit and framework as hard metadata from parsing on DocVerse, and we record the mapping version on the mapped fact rather than holding it globally.

A later comparison can then separate a real change from a change in how we read the source, and you cannot add that trail afterwards. On FinSight, the fund operations system we built, lineage is a property of the data: a restatement creates a new linked record, because an audit asks what you believed at the time.

Inherit permissions from the sources, because the graph should not grow a second access model. On Solarpunk the agent can act only through systems someone registered, and credentials sit in a vault injected at the call.

On the insurance voice agent we built, permission checks and required disclosures live in the tool contract, so a failing request escalates instead of degrading into something close. Give the agent retrieval tools against the graph, and keep the write tools behind the same checks.

Put a person on changes to the graph. Low-confidence extraction on DocVerse routes to review rather than passing downstream as fact, and the tuning work is making sure that low confidence actually fires. Proposed joins, retired definitions and conflict flags want the same gate.

Then measure whether answers improved, with the eval order in how to build LLM evals. A graph you never score is a second index you cannot defend.

Budget for upkeep, because entity resolution, freshness and the review queue are the ongoing cost, not the first load. A graph that is a month behind the CRM is worse than no graph, because it looks authoritative. Watch break rates the way we do on FinSight: a sudden drop in conflicts is as suspicious as a spike, because it often means a source changed shape and the mapping kept running.

Do you need a context graph?

Skip it when one well-structured source already answers the questions, and the agent only reads. RAG over that source, or a semantic layer over its metrics, is enough. Adding a graph so the architecture looks complete creates a second copy of the same facts, and the two copies drift.

Build it when the agent has to join more than one system, take a multi-step action, or leave an audit trail a person can replay. Those three show up together on the work we already do. DocVerse joins filings across years. Solarpunk reaches more than 100 tools and had to stop pasting the registry into the prompt.

Skionis, the DevOps agent we shipped on a live AWS account, keeps one record from the request through every validation failure to the resources that now exist, because an untagged change is archaeology six months on.

Ask whether a person can already point at the fact, the source, the date and the last decision for the task in front of them. If they can, and they do it from one system, you do not need a graph yet. If they open four tabs and still cannot say which owner is current, the graph is less work to keep than the reconstruction the agent will otherwise attempt on every run.

What stays out of the graph

Keep authorization of the action in the system of record. The graph can tell the agent that a customer is in arrears and that last quarter's exception was approved, but it cannot decide whether this refund may run. That check sits in AI agent permissions and, for MCP servers, in MCP authorization. A graph rule that tried to copy it would be a second, staler version of the same check.

Keep confirmation of an irreversible step with a person. On Skionis an engineer approves an architecture diagram before anything applies, and on the telecom engagement, deploying a campaign sits behind an approval gate. Human in the loop for AI agents covers what that approver should see. The graph can attach the last approval as a trace, and it should not be the place the next one is granted.

Keep metric definitions on the semantic layer. A context graph may point at "net revenue" and at the version in force. The formula, the level of detail and the owner live on the semantic layer for AI agents. Recopy the formula into a node and you have two definitions again, which is the sprawl that layer exists to stop.

AI agent monitoring still watches the run: latency, refusals, tool errors and whether the claimed completion matches the system the agent changed. The graph is one input to that picture, not the observability stack.

How Bigcircle builds it

We keep the list of entities and how they relate as its own layer, separate from the documents and from the metric definitions. On DocVerse that layer is the knowledge graph: entity, period and framework as traversable links, with vector search beside it for the claim that was never structured.

We do not ship a named product for this; we build the layer inside the system the agent already uses.

Every fact we put on that layer carries source, date and permission. On DocVerse the source is the page, the mapping version sits on the fact, and low-confidence fields route to a person. On Prospex a claim without a supporting retrieved passage does not appear, not softened, not hedged, absent.

On Skionis we measured template errors before deploy falling from around 10% to 4% once a validation loop checked each template against the live account. The same stance applies to a graph write: a hop that will not come clean does not become a node.

We write the decision back as a trace. Solarpunk keeps a record per run from the goal through the tools discovered to the final state of the application, and compares the agent's claimed completion with that state. Skionis links the request to every resulting resource.

The insurance voice agent we built keeps a structured record of turns, tools, disclosures and outcome. A context graph is those traces stored on the entities they touched, so the next run can find last week's exception without asking someone to remember it.

Give the agent tools that search and traverse the graph, not the raw systems behind it. We already do that for tools: Solarpunk queries a registry per step, and Skionis wraps provider APIs with purpose-built tools and no general shell. The graph tools are another typed contract, and RAG systems and document intelligence are the services that build the retrieval and the parse this layer sits on.

Common questions

What is a context graph?#

A context graph is a connected record of the facts an AI agent needs before it acts. Nodes are entities such as customers, accounts, systems, policies and people, and edges are relationships and the decisions already taken. Each fact carries its source, the date it was last true, and who may see it, and the agent writes a new decision back as an edge.

Is a context graph the same as a knowledge graph?#

No. A knowledge graph maps entities and the links between them. A context graph adds provenance, freshness and permissions on every fact, and it is written back to as the agent works. Without those tags the agent has a map it cannot audit, which is why a correct number under the wrong metadata is the failure we design for on DocVerse.

What is an agentic context graph?#

An agentic context graph is a context graph built around what an agent needs in a task, not around a human browsing a map. The agent locates entities, traverses links, checks source, date and permission, acts through a checked tool, and writes the decision back. The store can be a graph database, tables, or both; the loop, not the store, is the agentic part.

Do you need a graph database for a context graph?#

No. You need connections you can traverse and tags you can check. A graph database is one store that makes those hops natural. Tables with explicit relation records, plus a search index, can do the same job. On DocVerse we pair a knowledge graph with vector search because each fails alone, not because a vendor required a graph product.

How is a context graph different from RAG or GraphRAG?#

RAG retrieves passages and puts them in the prompt, while GraphRAG retrieves along entity links when the question is relational. A context graph is the record those retrievers read: sourced, dated, permissioned facts and the decisions already taken. Build RAG or GraphRAG against that record, and do not treat a fresh index over raw documents as a substitute for the tags.

How do you keep a context graph up to date?#

Inherit writes from the systems of record, and put a person on proposed joins, retired definitions and conflicts. Record freshness on each fact at write time, and watch the conflict rate per source, because a sudden drop often means a feed changed shape and the mapping kept running. A graph that is a month behind the CRM is worse than no graph, because it looks authoritative.