What Is a Live Context Graph?

Engineers building context pipelines for agents all face the same conundrum: every system must decide where the necessary data transformation work gets done. Whether at read time, at write time, or somewhere in between, a cost must be paid in the form of developer effort, compute, or tokens — and many teams are learning the hard way that agentic systems can be very, very token hungry.

Read-time transformation: Relational databases reliably provide clean, correct writes, one fact in one place. Here, the context work falls on the agent itself, or a tool it calls: it must write and run the queries itself, burning tokens to join, aggregate, and otherwise transform those writes to assemble even the most basic context before it can decide how to act.

Write-time transformation: There are two possibilities for pre-inference data transformation that agents can read from: data warehouses, or search indexes and document stores. Tokens are saved, but write-time transformation still incurs a tradeoff cost, whether data freshness or pipeline complexity.

• Data warehouses have everything pre-transformed and in one place, but the data the agent sees may be minutes or hours behind reality because warehouses are updated in batches rather than continuously.
• Search indexes and document stores similarly precompute and organize data into formats the agent wants to consume, so retrieval stays fast. Vector and search APIs in particular are gaining popularity as pre-inference agent context engines within retrieval pipelines. The custom streaming pipelines feeding them are complex to build and cumbersome to change, however, and the difficulty of keeping data up to date increases exponentially as data changes and retrieval patterns evolve. At agent scale, the developer effort required to create and maintain fresh, correct context becomes untenable.

In-between-time transformation: Read-time and write-time transformation architectures leave teams to ship agent context that is token-heavy, stale, or expensive to maintain. The architectural pattern that has emerged to solve all three of these problems takes the form of a live context layer, sitting in between agent reads and writes, whose linked data products form a live context graph.

A live context graph is a shared set of governed real-time data products, each modeling a core business entity (such as a customer, an order, or a merchant), with the relationships between entities maintained as part of the model. Every data product is kept incrementally up to date as source systems change, and all of them reflect the same point in time, which keeps the whole graph consistent with itself.

An evolution of the data mesh pattern, the context graph emerged to meet the needs of engineering teams working with agents. It has the data mesh's shared, reusable data products, but adds an ontology of maintained links between these products that agents can navigate during inference.

A context graph turns unstructured (and, frequently, siloed) raw writes into real-time, governed data products with semantic links between them. Agents treat those data products as ready-made building blocks, composing and filtering them on the fly over MCP or SQL to get exactly the context a task needs. And because the graph is kept up to date with the upstream data within seconds, an agent can observe the result of its own actions moments after it acts.

Agents can also navigate the graph to figure things out for themselves. Following the links between entities lets agents discover and reason about how entities connect more easily, enabling them to act more autonomously as a result. This is why agents become much more capable when they are grounded in a context graph, taking on broader tasks that would otherwise each require their own development work.

(Note: The graph isn't only for agents. The same governed data products that ground an agent's reasoning also serve dashboards, reports, and application queries, all reading from one continuously updated source of truth. Build the context layer once, and every consumer, AI or app, gets fresh, correct, ready-to-use data without its own custom pipeline.)

Context graph architecture simply adds a transformation layer to standard data stacks. There are two elements of transformation that take place in this layer: the initial incremental view maintenance (data products) themselves, and then the combining and filtering that agents can do against those data products.

Materialize is the ideal engine behind this live context layer, providing optimal and efficient context for AI agents. With Materialize at the heart of context graph data architecture, developers can build real-time data products on top of operational data, just using SQL.

The architecture looks like this: your operational data sources and event streams are the source of truth; Materialize ingests them over CDC, Kafka, and webhooks, and joins and transforms the data into real-time data products. Agents can then use MCP or SQL to discover, query, and combine these Materialize data products to assemble the context they need to do their work. Materialize can also push deltas out over Kafka to keep search indexes and other downstream systems in sync, as well as to power event-driven workflows.

Companies are already shipping context graph architecture in production. One loyalty and rewards platform built a live context graph in Materialize to unify context across hundreds of microservices into a single, continuously updated source of fresh context. Their AI customer service agents use these real-time data products to reliably solve complex requests and perform tasks for customers. As a bonus, the agents can run on smaller, less-expensive models because they have instant access to fresh, transformed data in the exact form they need to take fast, accurate actions.

Day AI, an AI-native CRM that agents keep up to date by listening in on emails and meetings, has also harnessed context graph architecture. Day AI agents store observations as 'facts' in a Postgres instance, which are then reconstructed into deals, accounts, and other business objects on demand. Materialize operates as their live context layer, maintaining these objects as a graph of real-time data products. As the upstream database changes, Materialize incrementally updates each data product and pushes deltas downstream to their Turbopuffer search index, so when an agent writes a new fact, every agent sees the updated picture in less than a second. All of this is done with just SQL, enabling a compact team to ship like a bigger one. Read the full Day AI case study for more technical implementation details.

No team builds a context graph in one step. Most start with a single challenge like moving heavy agent reads off a production database or keeping a search index fresh. They gradually add new use cases, each adding data products to a shared foundation the next one builds on. The graph fills out until the same live context layer can power every agent and application in the business. To learn more, speak to our team and book a demo.