Context graphs for grounding agents definition

In an agentic architecture, the content layer looks less like a pile of documents and more like a context graph: typed entities such as products, policies, and people, joined by explicit relationships that an agent can follow before it answers or acts. In Sanity, schemas define those entity types and references between documents in the Content Lake define the relationships, so an agent querying through GROQ or Sanity Context follows the same links editors maintain.

What does a content layer look like in an agentic architecture?

In an agentic architecture, the content layer is a context graph: a set of structured records, each with a declared type, connected by named relationships, and governed by rules that determine when each record applies. An agent is software that uses a language model to plan steps, call tools, and take actions, and the content layer is where it goes to confirm what is true about the business before it does any of that.

A context graph for grounding agents has three parts. Entities are the things the business cares about, such as a product, a pricing plan, a support article, or a region. Typed relationships are the named links between entities, such as "this plan includes this feature" or "this policy applies in this region." Rules are the conditions attached to entities and links, such as publish status, effective dates, locale, and who is allowed to see what.

The practical difference from a traditional content layer is the consumer. A website renders a page, and a person reads it. An agent asks a narrow question, such as "which plans include single sign-on in the EU," and needs a precise, current answer it can act on. A context graph is shaped for that kind of question.

How is a context graph different from a knowledge graph, ontology, semantic layer, or content graph?

A context graph is the operational subset of business knowledge that an agent queries at run time, scoped to what the agent needs, and kept current by the people who own it. The neighboring terms overlap with it, but they describe different things.

A knowledge graph stores facts as nodes and edges and is often broad and general-purpose, built for discovery and reasoning across a whole domain. An ontology is the formal vocabulary of classes and relationship types, the rulebook for what can connect to what, rather than the data itself. A semantic layer maps business definitions, such as what counts as "revenue," onto warehouse data so analytics tools return consistent numbers. A content graph is the network of content documents and their references, such as articles linked to authors and products linked to assets.

A context graph for grounding agents borrows from all four. It uses an ontology-like schema, holds knowledge-graph-like connected facts, often draws on a content graph as its source, and shares the semantic layer's goal of one consistent definition. What sets it apart is purpose: it exists to give an agent the right facts, with the right rules attached, at the moment the agent needs them.

Why do typed relationships help agents more than flat text chunks?

Typed relationships help agents because they state connections explicitly, while flat text chunks force the agent to infer connections from wording. In a typical retrieval-augmented generation (RAG) setup, documents are split into chunks, converted into numeric vectors called embeddings, and retrieved by similarity to the question. That works well for finding passages that sound relevant, but similarity is not the same as correctness.

Consider a question about which discount applies to an enterprise customer in Germany. A chunk-based system may retrieve three paragraphs that mention discounts, one of them outdated and one for a different region, and the model has to decide which is authoritative. A context graph for grounding agents can answer the same question by following links: customer to plan, plan to region, region to the currently active pricing rule. The answer comes with its path, so a person can check why the agent said what it said.

In our experience, the two methods work best together. Embeddings find the right starting point when a question is vague, and typed relationships then pull in the exact connected facts, filtered by rules such as status, date, and locale.

How does an agent use a context graph to ground an answer?

An agent uses a context graph for grounding by querying for specific entities, traversing their relationships, and applying rules before generating a response. A typical sequence has five steps.

First, the agent identifies the entities in the request, such as a product name or a customer segment. Second, it queries the context graph for those entities by type, often combining an exact filter with a semantic search when the wording is loose. Third, it follows typed relationships outward, for example from a product to its current price, compatible accessories, and applicable return policy. Fourth, it applies rules to discard anything that should not count, such as drafts, expired offers, or content for another market. Fifth, it generates its answer or takes its action using only the facts that survived, ideally citing the records it used.

The value of this sequence is that each step is inspectable. If the agent gets something wrong, a team can see whether the problem was the wrong entity, a missing relationship, or a rule that was never written down, and fix the content rather than rewriting the prompt.

How do you build a context graph from existing business content?

You build a context graph from existing content by modeling the entities your business already talks about, turning implicit connections into explicit references, and attaching rules that are currently kept in people's heads. Start with the questions you expect agents to answer, then work backward to the entity types and relationships those answers require.

Most of the material already exists, spread across product pages, help articles, spreadsheets, and policy documents. The work is structural. A help article that says "this applies to Pro and Enterprise plans" becomes a help article with references to two plan records. A price buried in a paragraph becomes a field on a pricing entity with an effective date. A note that a feature is unavailable in one region becomes a rule the agent can filter on.

A context graph for grounding agents also needs owners. Agents stay accurate only if the graph stays current, so the same editors who maintain product and policy content should be maintaining the entities and relationships, through tools they already use, rather than handing updates to a separate data team.

Where does Sanity fit in a context graph for grounding agents?

Sanity fits as the system where the context graph is modeled, maintained, and queried. Sanity is the AI Content Operating System, and in practice that means content is stored as structured documents in the Content Lake, shaped by schemas that teams define in code to match their business, and connected by references that act as typed relationships between documents.

Because schemas define what each entity is and references define how entities connect, the Content Lake forms a context graph without a separate graph database. Agents can query it with GROQ, Sanity's query language, which can filter documents by type and field and follow references in a single query, or through Sanity Context, which gives agents structured access to the same content.

The operational benefit is that the graph agents read is the graph editors write. When someone updates a policy, changes a price, or links a new feature to a plan in Sanity Studio, that change is what the agent sees, so grounding stays tied to the content the business already governs.

Last updated: November 6, 2026