We’ve Been Building The Foundation For 40 Years

A year ago, I wrote about the graphic future of IT management — IT management platforms converging on graph architectures to create a digital twin of the IT organization. The governance question I raised: Who owns this graph?

Nine months later (December 2025), Foundation Capital declared that the next trillion-dollar platforms will be built on “systems of record for decisions” — what they call context graphs. VCs rushed in. Glean, Graphlit, and TrustGraph all scrambled to position. This week, ServiceNow announced Context Engine: enterprise context for every AI decision.

When a VC firm puts out a note like this, readers may think “greenfield opportunity.” In this case, it’s not. Many disciplines have been building pieces of this graph, in isolation, for decades.

  • Enterprise architecture (EA) has maintained entity graphs — what exists, who owns it, what business function it serves — since Zachman (1987).
  • ITSM (ITIL v1) started calling for CMDBs in the 1990s.
  • Application performance monitoring (APM) built runtime execution traces starting in the early 2000s.
  • Process mining reconstructed actual workflows from event logs (Celonis, 2011).
  • ChatOps (2013) moved operational decisions into logged, searchable channels. Incident analysis tools such as PagerDuty structure post-incident decision chains into escalation topology and AI-generated postmortems.
  • Organizational network analysis mapped informal communication structure from collaboration metadata (Microsoft Viva Insights, SWOOP Analytics).
  • FinOps and technology business management mapped cost to services to capabilities.
  • Software bill of materials mandates created component-level dependency graphs.
  • Architecture decision records document the “why” of the IT estate’s most significant decisions.
  • Currently, Atlassian markets its Teamwork Graph, one of the clearest implementations of the core thesis, including motivations and decisioning extracted from Jira records as a “System of Work.”

Currently, no-one builds more than two or three of these layers. Named entity resolution of logical entities and their dependencies is hard. Dynatrace knows the service topology but has no idea what business capability it serves. Jeli knows why the incident was hard to resolve but can’t see the architectural decisions that made the system fragile. Celonis knows how work actually flows but has no visibility into service ownership. EA knows the capability map but couldn’t tell you what happened at 3 a.m. when the billing system went down.

Foundation Capital is right that these need to converge. What they didn’t credit was that some of this convergence is already underway. They argue that decision traces “currently live in Slack threads, deal desk conversations, escalation calls, and people’s heads.” But Atlassian’s Teamwork Graph is already extracting motivations and decisioning from Jira records — a decision trace layer built on an existing entity graph. Jeli (acquired by PagerDuty in 2023) structured post-incident decision chains — who escalated to whom, what was tried, what reasoning drove the response — precisely because those traces were the institutional knowledge that walked out the door after every incident.

The decision trace layer isn’t missing. It’s fragmented. That’s a different problem than greenfield, and it’s one that favors incumbents with existing entity graphs over startups building from scratch.

EA Is The Practice That Connects The Layers

Enterprise architecture is the major discipline primarily responsible for this kind of cross-layer sensemaking.

EA was always supposed to maintain the interpretive overlay that connects technical reality to business meaning: capability maps, application-to-capability assignments, target-state architectures, technology standards, rationalization strategies. These aren’t runtime objects. In the old Buddhist saying, a finger pointing at the moon is not the moon. These are sensemaking abstractions that humans use to navigate a complex estate and decide what to do about it.

That’s what a context graph is: a queryable layer of sensemaking abstractions that connects entity state to decision rationale across systems and time.

EA and related disciplines have been building layer one — entity, ownership, capability — for 40 years. This is the foundation most context graph proposals skip, which is why their agents hallucinate: They’re trying to reason about decisions without solving the entity-grounding problem first.

What EA never captured is why decisions were made. Why was the migration deferred? Why do we have three CRM systems? The reasoning lived in architects’ heads and walked out the door when they left. Architecture decision records have started to surface this, but they’re still largely textual.

This is the new contribution that the context graph movement offers: layer two, the decision trace layer — the reasoning that shaped the estate, made queryable. “How did we handle this before?”

Neither layer works in isolation. Decision traces without entity grounding float unmoored: You know a decision was made but can’t connect it to a specific application or business capability. Entity graphs without decision traces are accurate enough as inventories but incomplete for figuring out what to do next. The context graph is the reunification: EA’s entity foundation plus the decision trace layer, in one queryable graph.

The Fidelity Problem Nobody Escapes

Every EA team knows: The map is always wrong. The configuration management database (CMDB) is stale. The capability model was baselined ten years ago and is stale. The application inventory misses the shadow IT. The dependency map was accurate last quarter.

Calling the map a “context graph” doesn’t change this. Adding decision traces makes it worse — now you have entity staleness and reasoning decay.

Our technical debt workbench research identified a reinforcing doom loop we call observability decay: Low investment in estate visibility leads to stale data, which leads to misallocated investment, which leads to debt in invisible corners, which leads to surprise incidents, which erodes trust in the data, which leads to less investment in maintaining it.

The context graph startups will hit this wall. Foundation Capital assumes that agents sitting in the execution path will naturally accumulate decision traces. But persistence is never the hard part — fidelity is. Every CMDB and EA initiative hits it. Fidelity requires sustained governance investment and people committed to maintaining the sensemaking layer. AI will help, but in sensemaking work of this kind a human still needs to look at it and say “yes, this is good,” or “no, try again” (speaking as someone currently using Claude to maintain a 2,000-node capability hierarchy).

Data governance makes or breaks this. The entity layer needs authoritative sources, ownership, and lifecycle management — who is allowed to say “this application is retired” or “this capability maps to that service”? The decision trace layer needs provenance, versioning, and access control — who made this decision, under what authority, and is this trace still valid or has it been superseded? Without governance, the context graph becomes a write-only log: everything goes in, nothing gets curated, and agents learn from stale precedents. The CMDB vendors learned this the hard way. The context graph startups will learn it again — unless they treat governance as a core product capability rather than a customer problem.

Why “Context Graph,” Not “Digital Twin”

The industry also frames this as a “digital twin” — a perfect copy of reality you operate on instead of the original. That framing gets the problem wrong.

The copy is never perfect (that’s the fidelity problem above). But more important: The copy isn’t just a copy. Business capabilities, technology categories, rationalization strategies, decision traces — none of these are in the running systems. They’re human sensemaking enriching the map. The IT management graph doesn’t “twin” the data center; it classifies the data center using abstractions that exist only there. Servers and their workloads exist; applications and services are a sensemaking layer that has no source of truth to sync from.

“Context graph” is the more honest framing. Some of that context is derived from reality (apps, servers, dependencies). Some of it is created by humans doing EA work (capability maps, decision traces, target-state architectures). Maintaining that human sensemaking layer is what EA has always been for.

What This Means

For EA leaders: You’ve been building context graphs since before the term existed. Your entity graph is the foundation. Decision traces are the layer you need to add. The developer portals, AIOps platforms, and incident tools are building adjacent layers. Your job is to connect them.

For CIOs: The context graph is an organizational capability you build, the same way EA has always been built — through sustained investment, governance discipline, and people committed to maintaining the map. AI agents will be extraordinary but only if they have a high-fidelity graph to learn from.

For context graph startups: You’re building on top of 40 years of EA practice, APM infrastructure, IT service management workflow data, and organizational knowledge scattered across a dozen tools. If you can’t integrate with the existing EA foundation, your decision traces will float without grounding.

The context graph is a convergence whose time has come — because AI agents need the unified view that no single discipline provides. EA built the foundation. Now it’s time to complete the graph.

This is a follow-up to The Graphic Future Of IT Management (March 2025).

 

Postscript: Two limits worth watching

First, the decision traces that today’s tools capture are overwhelmingly grounded in digital artifacts: Jira tickets, Git commits, incident timelines, Slack threads. But most consequential business decisions — credit overrides, supply chain substitutions, vendor escalations, regulatory interpretations, pricing exceptions — happen in phone calls, hallway conversations, and meetings that may or may not produce notes. The reasoning that shaped those decisions remains dark matter unless organizations start transcribing and harvesting everything (ALL emails and phone calls… ???), which raises governance and cultural questions that, umm, make CMDB fidelity look simple. Foundation Capital’s thesis is strongest where decisioning is already digitally instrumented (software delivery, incident management, workflow automation). It gets much thinner in the channels where many of the highest-value decisions are made.

Second, Palantir’s Ontology layer deserves attention. It is architecturally a general-purpose context graph: entities, relationships, and business logic, with a “context engineering” pipeline explicitly designed to feed AI agents. Palantir is approaching this from defense and intelligence rather than IT operations, but the ontology doesn’t care what domain it models. The question is whether a horizontal platform that lacks ServiceNow’s core IT management depth or Atlassian’s developer activity can bootstrap the fidelity needed to compete. History suggests the incumbent with the data wins — but Palantir’s growth trajectory and government foothold make it a credible dark horse.