Misaligned Attention to Context Graphs
TL;DR
- Context graphs are outdated: they impose rigid schemas on something that should be dynamic.
- They add cost and brittleness: migrations, sync, and maintenance without real payoff.
- Runtime context wins: CodeAct + MCP lets agents pull exactly what they need, when they need it.
Context Graphs?
There is a recent surge of interest in “context graphs” as a foundation feature for AI agents. While context acquisition and management are indeed central to any agentic system, the current push toward dedicated context-graph stores is both strategically misaligned and conceptually underpowered for the problem it is attempting to solve.
The articles (on LinkedIn and elsewhere) almost universally advocate for the creation of yet another centralized data store - a “context graph” - that aggregates systems of record alongside ancillary context sources such as execution logs, Slack messages, and Zoom transcripts. This is fundamentally 2015-era thinking: capture more data, normalize it into a new schema, and hope downstream systems extract value later.
This approach mirrors the limitations seen in ReAct architectures versus more modern CodeAct execution models. A layered, intermediary datastore inevitably constrains expressiveness to the abstractions, schema design, and query language chosen upfront. As a result, the system hard-codes assumptions about what “context” is and how it should be accessed - precisely the opposite of what dynamic, task-driven reasoning systems require.
The practical downsides are substantial. Introducing a new graph layer implies non-trivial migration costs, ongoing synchronization overhead, schema evolution challenges, and operational drag, even for greenfield deployments. Worse, it creates a long-lived architectural dependency that becomes increasingly brittle as new data sources, tools, and reasoning patterns emerge.
Computed Context
A more modern and materially more powerful alternative already exists: CodeAct + MCP-based tool access. MCPs are available today for virtually all relevant enterprise data sources - databases, logs, Slack, Zoom, ticketing systems, and internal APIs. Instead of forcing data into a new canonical store, LLMs can dynamically reason over the task at hand, discover relevant tools, and construct data access paths on the fly for a given task at hand.
This approach has several decisive advantages:
- No data migration or duplication
- Minimal upfront and ongoing cost
- Far greater expressive power, unconstrained by a fixed schema
- Better alignment with how LLMs reason, adapt, and evolve
- More future-proof, as new tools and data sources can be added without re-architecting the system
In short, context should not be pre-modeled into yet another datastore. It should be computed dynamically through reasoning and tool use at execution time. Treating context as a static asset rather than a runtime construct underestimates both the capabilities of modern LLMs and the direction in which agentic systems are clearly heading.