The Context Graph and Modern Software Engineering

We have spent the decade getting extraordinarily good at instrumenting individual parts of our systems. Code lives in version control with full history. Infrastructure is declarative and diffable. Telemetry is structured and searchable. Incidents are tracked, Deployments are logged, dependencies are mapped, ownership is documented. By any reasonable measure, we have more data about our software than any generation of engineers in history. Most engineering orgs are investing in AI agents right now. Coding agents. Monitoring agents. Review agents…

And yet, when something breaks in production, most still reconstruct what happened by hand.

This is the contradiction at the heart of modern engineering. The code lives in GitHub. The behavior lives in Splunk. The infrastructure lives in AWS and Terraform state. The customer impact lives in a ticket or Slack threads. The institutional memory lives in retired engineers and a system (or a document) nobody can find. We have all the data and almost none of the connections.

Each system is a perfect record of one slice of the truth, and the truth itself lives in the spaces between them -assembled, painfully, by humans, in real time, every time something matters. I have started calling the thing that fills those spaces a Context Graph. I want to make the case for why it is the most important piece of infrastructure your engineering organization is not currently building.

What it is

A Context Graph (or Engineering Graph) is a unified, queryable, temporal model of how the entities in your engineering system relate to each other.

Here is simplest form of how this may look like- not a finished spec, and the actual model in your environment will look different. But it is useful to make the shape concrete

Source systems on the left feed entities and relationships into the graph. The orange path shows one traversal: a new incident walked back through telemetry, deployment, code change, and infrastructure — with a similar past incident and its postmortem surfaced by pattern match. The faint background edges are the rest of the graph; the agent only walks what is relevant.

The entities are the things you already track in your existing tools -services, deployments, code changes, infrastructure resources, telemetry signals, incidents, tickets, postmortems, owners. The relationships are the edges between them -this service depends on that one, this deployment shipped that code change, this alert fires on that metric, this incident was caused by that PR, this postmortem documents that failure mode. The temporal layer means every node and every edge carries history -you can ask what the system looked like at any moment in the past, not just what it looks like now.

Two properties make it qualitatively different from anything you already have.

First, it is not a separate database that humans maintain by hand. It is built from the change streams your existing systems already emit -GitHub webhooks, AWS events, Terraform state diffs, observability APIs, incident system updates. It is downstream of reality, not parallel to it. When a service is deployed, the graph knows. When an alert is created, the graph knows. When an incident is resolved, the graph knows. Nobody has to remember to update anything, because nobody is updating anything.

Second, it is not designed to be queried by humans writing structured queries. It is designed to be traversed by language models and agents, which means the schema can be sparse, the data can be partial, and the value compounds in a way that older graph systems never managed.

That last point is the one that changes everything, and it is the reason this is a 2026 conversation rather than a 2018 one, the year I joined Salesforce :) The best decision of my professional career!

Why now

The idea of a unified model of an engineering system is not new. AIOps promised it. Service catalogs and configuration databases have been attempting it for two decades. Every few years, a vendor announces a “single pane of glass” and engineering leaders nod politely and continue debugging in seven tabs.

These efforts failed for a specific, structural reason: the graphs were only useful if they were perfect, and they were never perfect. Coverage gaps were exactly where the failures lived, and humans could not tell which parts were missing until they got burned by it. Rule-based correlation engines required exhaustive ontologies and broke on any edge case the ontology did not anticipate. Query languages required experts. Integration was a multi-year program. The data was stale within a week.

Every single one of those failure modes has changed in the last twenty-four months.

Modern language models can traverse messy, partial, cross-domain context in a way that no rule engine ever could. A Context Graph does not need to be perfect anymore. It needs to be good enough that an agent can reason about it, and “good enough” is a much lower bar than “comprehensive.” Missing edges get inferred. Ambiguous relationships get ranked by likelihood. The graph degrades gracefully instead of catastrophically. This is the unlock.

The integration work has collapsed in parallel. What used to be a dedicated platform team writing custom connectors for every system is now a small group writing MCP servers in a quarter. Coding agents themselves accelerate the work -Claude Code can stand up a new graph connector in an afternoon that would have taken a sprint two years ago. The economics that made AIOps a doomed enterprise initiative have flipped.

And finally, the consumers of the graph are different. Earlier attempts were queried by humans writing reports. The Context Graph is queried by agents running in the loop of actual engineering work -in the IDE, in the CI pipeline, in the incident channel, in the deployment flow. The graph does not need to surface insights to dashboards anymore. It needs to surface context to the AI tools your engineers are already using. That is a much easier delivery problem.

The technology to actually build this just became available, and most engineering organizations have not noticed.

What it changes day-to-day

Three things in your engineering org get measurably easier the moment a Context Graph exists. Each of them is something your team did this week, painfully, by hand.

Debugging. Today, when production breaks, the first thirty minutes+ of every incident is the same activity: someone is gathering context. What changed recently? Which deploys went out? Which monitors are firing? Has this happened before? Who owns this service? Seven tabs, three Slack threads, two dashboards. That whole phase disappears. The agent grounded in the graph has already assembled the relevant subgraph -the failing service, the recent deployments, the infrastructure changes, the past incidents with similar signatures, the owners -and proposed a ranked hypothesis with the traversal attached as evidence. The on-call engineer audits the reasoning instead of performing it. The incident starts where it used to start after the first one hour.

Testing. Today, when an engineer opens a PR, the tests that run are the tests someone thought to write when the code was originally added. They have no memory of what has broken in production since. With a Context Graph, the PR is checked against the failure history of the code paths it touches. “This change touches a X library that caused INC-2284 in April 2026. The regression test added after that incident does not exist in this service. Here is the test.” The test suite stops growing by accident and starts growing by lesson. The failures your organization has already paid for stop repeating themselves.

Deploying. Today, the deploy button is a green button on a CI page. It tells you the tests passed. It tells you nothing about blast radius, nothing about which monitors will fire first if this regresses, nothing about how similar changes have gone in the past. With a Context Graph, the deploy button is annotated. “This change affects three downstream services. The monitor most likely to fire first is XYZ. Two past changes resembled this one -one rolled back, one was clean. Here is the rollback plan tailored to this change.” Confidence stops being a feeling and becomes a property of a known graph state.

None of these are speculative. Each of them falls out, almost mechanically, the moment an agent can traverse the connections between systems that previously could not see each other. The Context Graph is the substrate that makes the AI tools you are already deploying actually competent at the work you are already asking them to do.

What it makes possible that nothing else does

Here is the part that I think most engineering leaders are going to miss, because it does not look like a feature.

A Context Graph compounds. Every incident your organization resolves writes a new annotated subgraph back into the substrate -the symptoms, the hypothesis, the actual cause, the fix, the test that should have existed. The next time a similar pattern appears, the graph recognizes it. Not because someone updated a runbook. Because the resolved incident is now part of the model, and similarity is something the embedding layer figures out on its own.

This means your organization, for the first time, gets systematically smarter every time something breaks. The institutional memory that today lives in the heads of your three most senior engineers -the ones who remember which configuration change caused which outage in 2022, who know which service has the brittle dependency, who can pattern-match a new alert against three old ones -that memory stops being a personnel risk. It becomes infrastructure.

This is the asset that nothing else in your stack produces. Better dashboards do not produce it. Better agents in isolation do not produce it. More observability data does not produce it. It only emerges when the connections themselves are first-class, when they are queryable, when they accumulate, and when they are exposed to systems that can learn from them.

The engineering organizations that build this in the next eighteen months are not going to win because their MTTR is lower or their deploys are safer. They are going to win because their senior engineers’ knowledge stops walking out the door when those engineers leave. They are going to win because every incident they survive makes the next one cheaper, and their competitors are still paying the same tuition over and over.

What to do about it

If you are convinced -and I recognize that this is a strong claim made quickly, the path is more pragmatic than it sounds.

You do not need to model your entire organization. You need one tier-one service, six entity types, four relationship types, and three source systems wired in. You need a small graph store that supports embeddings, an event-driven ingestion path so the graph is never more than seconds stale, and an MCP server that exposes the graph to whatever AI coding tool your engineers already use. You need the discipline to write resolved incidents back into the graph as structured artifacts, every time, without exception. That feedback loop is what separates a Context Graph from another stale inventory nobody trusts.

Ninety days of focused work from a small team gets you a credible v1 against one service. The next quarter expands coverage. The quarter after that, the graph starts surfacing patterns nobody asked it to look for, and you realize the asset you have built is larger than the sum of what you put into it.

The hardest part is not technical. The hardest part is keeping v1 small enough to ship, and keeping the feedback loop honest enough to compound.

The layer that was missing

Every era of engineering infrastructure has introduced a layer that, in retrospect, was obviously missing. Version control. Continuous integration. Infrastructure as code. Distributed tracing. Each of them felt optional until it became unthinkable to operate without it.

The Context Graph is the next one. It is the layer that makes the AI tools we are already deploying actually capable of reasoning about our systems instead of just our files. It is the substrate that turns institutional memory from a liability into an asset. It is the connection layer that fifteen years of point-tool investment has been quietly demanding and never quite received.

The teams that build it first are going to look, in three years, like they figured out something obvious. They will not have. They will have figured it out while everyone else was buying agents.