Context Graphs at Agent Scale: Happy Writers, Happy Readers
July 13, 2026
"I didn't have time to write a short letter, so I wrote a long one instead." – Mark Twain
As we help engineering teams bring more and more context pipelines into production, it's gotten me thinking about a writing principle I've learned and relearned over the years: "be reader-serving."
The natural state of a writer is self-indulgence: put your thoughts down as they come and let the reader use their brainpower to sort out what you mean.
Reader-serving writing flips this approach on its head: do the heavy lifting of structuring, editing, and massaging your writing up front so your readers can get to the point. The cognitive load, and work, moves off the reader and onto the writer.
Engineers building context pipelines for agents are wrestling with a version of this same tradeoff. Every system has to choose where the work gets done: at write time, at read time, or somewhere in between. Someone has to pay that cost, whether in developer effort, compute, or tokens that are increasingly blowing up R&D budgets.
Relational databases serve the writer: clean, correct writes, one fact in one place. The agent reader, or a tool it calls, then uses SQL to join, aggregate, and otherwise transform those writes every time it needs to assemble even the most basic context before deciding how to act.
Search indexes and document stores are reader-serving infrastructure. They precompute and organize data into shapes readers want so retrieval stays fast. It's why we're seeing vector and search APIs become so popular in agent context retrieval pipelines. The problem is that keeping those indexes and documents fresh becomes exponentially harder as data and retrieval patterns evolve. Every day we hear how, at agent scale, the writer burden of keeping all these agent readers well-served with fresh, correct context becomes untenable.
Imagine the pipeline required just to handle a user getting added to a new team in a complex org chart: how do the access-control attributes update across a library of potentially billions of documents?
Agents aren't deterministic; new tools come online, new shapes get requested; so even if you get a pipeline right after many weeks or months of effort, agents and the humans that create them will want new reader-serving documents faster than you can build pipelines to create them.
Connecting the firehose of what's happening to the needs of every context-hungry agent reader is more than a full-time job.
The pattern emerging is effectively creating a well-indexed library of always-current, trustworthy contextual building blocks: a live context graph. This lets writers write freely and flexibly, while simultaneously letting readers assemble what they need without burning excessive resources making sense of free-form writes.
The way to build flexible, up-to-the-second context graphs in production is to put an incremental transform layer in between. One that turns unstructured and potentially siloed raw writes into real-time, governed data products with semantic links between them. When built right, these become composable, contextual building blocks that can be defined once and composed infinitely, transforming into the shape an agent needs with minimal work.
When end-to-end write-to-context latency drops to single-digit seconds, your agents become interactive; writes and their results are visible in the same live conversation. That's an important foundation for tight feedback loops and more reliable and compelling agent experiences.
The writers get to be self-indulgent; they just write what comes naturally. The readers quickly (and token efficiently) assemble fresh, clean context. The heavy lifting happens in between, in the live context graph that compounds in capability over time.