A two-years-later follow-up to ServiceNow And Atlassian: The Rise Of IT Management Platforms (July 2024) and a continuation of Context Graphs Are A Convergence, Not An Invention (April 2026)
Most public discussion of enterprise AI still fixates on models, GPUs, and benchmarks. That focus misses where durable value is actually being created. The hard work sits higher in the stack: in semantics, ontology, and the operational data enterprises have been accumulating for decades. Every large organization carries myriad siloed, disparate definitions of core data — “customer,” “portfolio,” “service,” what have you. Models reason cleanly only when that mess is resolved.
Vendors capable of organizing this operational reality into machine-usable context may capture enterprise AI value comparable to the model providers themselves. This is why attention should be on the platforms that already host the data, relationships, and workflows where delivery and operational work actually happen.
In July 2024, after returning from the ServiceNow Knowledge and Atlassian Team conferences, I argued that we were watching a structural realignment: ServiceNow and Atlassian had reached a level of dominance in IT management that no other competitor was likely to catch. I called it a bipolar world.
Next week, ServiceNow Knowledge 2026 and Atlassian Team ’26 kick off (both on May 5). Both events will showcase further announcements. The headline is already visible from each vendor’s recent moves: The context graph is now the center of gravity of the IT management platform.
ServiceNow announced its Context Engine on April 9, fusing Service Graph (CMDB), Knowledge Graph, the recently completed Armis cyber asset graph, and the Veza access graph into a unified intelligence substrate for AI agents. (An alert analyst, noting the recent acquisition of Traceloop, would probably also list it as a likely part of the Context Engine.) The company cites 85 billion workflows and 7 trillion transactions annually flowing through ServiceNow as the operational corpus that the Context Engine learns from.
Atlassian’s Teamwork Graph has surpassed 100 billion objects and connections, the data layer that makes Rovo’s search, chat, and agent experiences work. The numbers are not apples-to-apples (workflow events versus graph objects), but the directional point holds: Both vendors operate at a scale of structured enterprise context that no startup or hyperscaler can credibly claim.
As usual, I need to make my routine point that Atlassian and ServiceNow have long transcended mere IT boundaries. This has been going on for 10 years. Both focus on enterprise service management. They run production workflows for customer service, human resources, many other operational areas, and collaborative work management generally.
They are not the sole platforms used by enterprise operations, of course; there are many, many others. But they do support end-to-end decision-making in the purely business sense, and they also have the catalogues and delivery data of the technical resources that underpin these decisions. These inventories (now strongly data-aware, via acquisitions like data.world and Secoda) are critical, because this is where the data management layer lives: from ontological to physical. This is where we understand things like data and definitions.
This is the IT management graph convergence I called out last year and elaborated on (in terms of “context graphs”) three weeks ago, playing out with Atlassian and ServiceNow as centers of gravity. The feedback loop continues to accelerate, the data-rich platforms are getting richer faster, and the war for AI value rewards the operational corpora these two have been accumulating since the early 2000s. My definition of “context graph” does not yet line up with Foundation Capital’s framing; I think the firm undersells the law-of-available-data problem, which I will address in research. But in one narrower case, I agree: Traces are now both available and required for agentic workloads — more on that below.
Same Destination, Opposite Directions
Both vendors arrived at the same architectural destination from opposite ends of the SDLC. ServiceNow comes from the structured workflow and entity-grounding end — what I called layer one in the convergence post — with 22 years of CMDB lineage as the foundation. Atlassian comes from the discovery and development end with Jira “issues as decisions in flight” and Confluence pages as reasoning artifacts. Neither has the full graph yet. Both will continue trying to add what the other already has. Atlassian’s December acquisition of Secoda is exactly that move: a data catalog and semantic cataloging tool that adds a corporate ontology to the Teamwork Graph, plugging Atlassian’s structured-data weakness in the same playbook ServiceNow ran with data.world and Salesforce ran with Informatica.
Traces Are Both Available And Required Now
One area where I do agree with Foundation Capital: Agent decision traces are about to become mandatory artifacts of running agentic workloads. Agents executing in production generate traces of their reasoning, tool calls, and decisions as a byproduct of execution — the same way APM instrumented application code two decades ago. The difference is that you cannot govern, debug, or improve an agent without those traces. They are required for compliance, for incident review, for fine-tuning, and for the basic “What did the agent decide and why?” question that auditors and CIOs are already asking. OpenTelemetry-style instrumentation extends naturally to this. This is why ServiceNow’s acquisition of Traceloop matters.
The implication is straightforward: The logging and monitoring category — Splunk, Datadog, Dynatrace, New Relic, the open-source observability stack, and the broader APM and SIEM markets — is about to absorb a meaningful new workload. Every agent in production is a new source of traces, and the volume scales with autonomy. This is good news for incumbent observability vendors that can extend their existing instrumentation to agent reasoning and decision telemetry — and that sell logging ingestion capacity by volume. It is harder news for CIOs, whose observability budgets are about to grow whether or not they planned for it.
The Unresolved Questions
If two vendors both claim to host the canonical context graph, how do those graphs interoperate? Both may bet on MCP as the substrate. MCP alone will not solve it. Vendors provide data containers; customers populate them. When ServiceNow’s CMDB calls something an “application” and Atlassian’s Teamwork Graph calls a related thing a “service,” those are not the same node — and worse, what counts as an “application” in one customer’s ServiceNow instance will not match what counts as an “application” in another’s. The semantic mapping is not just vendor-to-vendor. It is customer-by-customer, on top of vendor-to-vendor. An agent stitching across two graphs in two enterprises will get wrong answers in subtly different ways at every customer.
Thus, the context graph conversation can sound a little naïve to veterans of the EA and CMDB wars who have been struggling with the meaning, provenance, completeness, and currency issues of these precursors to context graphs for about 25 years or so. AI may well make these problems worse before better. Both vendors inherit decades of stale-data problems and now layer decision traces on top, which means entity staleness and reasoning decay compounding. AI plus context graphs will make the cost of not doing data quality and governance show up faster, in the form of agents producing confident, plausible-sounding nonsense at machine speed — hallucinations as an artifact of data quality, not just LLM architecture.
The center of gravity has shifted from workflows to graphs. The next chapter is about who owns the graph, who governs it, and whose semantic model wins when graphs collide.
