Does Context Engine replace the CMDB?

For over twenty years, the industry has been chasing the perfect CMDB: a single repository where all infrastructure, components and services come together to represent an enterprise's digital estate. The theory is sound. An accurate CMDB is genuinely the foundation for impact analysis, risk assessment and service control. But in practice, most CMDBs have quietly become compliance anchors. Organisations pay to maintain them, rarely trust them, and the people resolving incidents at 2 a.m. are usually working from Slack threads and tribal knowledge rather than the ownership model someone spent six months defining.

Take ownership as the obvious example. An organisation spends months declaring that "Brian" in Finance owns the technical payment service. Payment goes down at 2 a.m., and the war room reveals the real owners: three engineers nobody got around to documenting. The CMDB was right on paper and useless in the moment.

The hidden cost of keeping the model alive

The harder problem is that achieving CMDB maturity is labour intensive, ad-hoc and cumulative. The work never really stops.

Organisations are still spending heavily on CMDBs, but the value equation is under pressure. Mordor Intelligence estimates the global CMDB and IT Discovery Software market at USD 5.28 billion in 2025, projected to reach USD 5.98 billion in 2026. The same research notes that enterprise CMDB rollouts routinely exceed budgets by up to 100 percent once integration, data cleansing and training are factored in, with Fortune 500 programmes surpassing USD 10 million over three years. And yet the direction of travel is telling: in October 2025, Forrester analyst Charles Betz declared that Forrester is deprecating the term CMDB entirely, in favour of the IT management graph, arguing that the industry needs to move beyond static repositories towards graph models that can represent exposure, impact, lineage and dependency. The issue is not that organisations are underinvesting in configuration data. It is that much of that investment is still anchored to systems designed for yesterday's operating model.

The licensing line is the easy part to see. The harder cost is the hundreds, sometimes thousands, of internal hours spent describing services that change faster than the model can absorb the changes. Every hour spent reconciling a CMDB is an hour not spent on something that actually moves the operating model forward. Few executives genuinely understand that trade off, because the cost shows up as headcount and time rather than as a line item.

Why the CMDB falls behind

The CMDB was designed for a world where change was slower and ownership was less fluid. It depends on a model defined in advance and kept in sync with reality. Developers now release in sprints, cloud teams stand up services in minutes, and ownership shifts as teams reorganise around products rather than systems. When reality moves faster than the model can adapt, the system falls behind, and once that happens, trust breaks down.

The industry hasn't stood still. We automated discovery, integrated systems, built relationship maps, reduced the manual burden considerably. But the underlying constraint hasn't gone anywhere. Every answer in a CMDB is the result of a decision someone made in advance about what to model, which relationships matter, and how to represent reality. If nobody anticipated the question, the CMDB has no answer to give.

Context beats configuration

And so I was recently asking myself the question: what relevance does the CMDB actually have in a world where AI agents are doing the reasoning?

Context, in this sense, is not a relational database. It is the ability to answer questions like "what depends on this?", "what breaks if this changes?", "who actually owns this decision?" and "what revenue is exposed right now?" The answers are not modelled in advance. They are inferred from whatever signals are available at the moment the question is asked.

The question is not "do we have a better CMDB?" It is "do we have a layer that lets agents reconstruct context on demand?"

This is where graph databases become interesting. A graph is a real-time fabric of nodes and edges that is fast to traverse and can absorb new data sources without redesigning the schema or adding new classes. A relational CMDB requires you to know the question upfront. A graph allows agents to navigate relationships step by step, adapting their paths based on what they find.

The practical difference matters. When an agent needs to assess the business impact of a system failure against a CMDB, it depends on predefined service mappings, semi-manually maintained relationships, and explicit links to business context. If any of those are missing or stale, the answer degrades, and the engineer asking the question stops trusting the tool.

A graph based context layer behaves differently. The agent starts at the infrastructure layer, moves across the application stack, identifies the services it supports, links to business processes, expands into customer context, and correlates live signals like incidents and ongoing changes. It can pull in indirect or previously undefined edges, and enrich the path with additional sources such as billing data or risk controls. The answer is constructed in real time rather than retrieved from a fixed structure.

Recent research from REVA University, published as "Autonomous Multi-Agent System for Integrated SRE and Self-Healing in Cloud-Native Environments", found that by correlating context across logs, infrastructure and services, agents reduced end-to-end incident resolution time from hours to under 30 minutes and achieved 96% accurate root cause analysis. Resolution speed is no longer constrained by how well systems are modelled upfront, but by how effectively the system can reconstruct context and coordinate decisions in the moment.

The CMDB doesn't go away

I should be clear that this is not a "burn your CMDB" argument. Graph databases have genuine limitations. They are effective for agent reasoning, blast radius analysis, memory and context traversal. They are weaker on the things the CMDB has always done well: auditability, ownership tracking, structured reporting and compliance. If you need to answer "how many P1 incidents were raised on service X in the past four days", a graph database is the wrong tool.

What changes is the role the CMDB plays. It stops being the centre of the operating model and becomes a critical data source feeding into a broader context layer. Enterprises that have taken their foundation data seriously have a real advantage as they move into agentic AI, because graphs alone are not enough to structure incidents, changes and records.

ServiceNow's recent context engine release, which extends CMDB data and effectively any other system record into a context graph, is probably the clearest signal of where the larger vendors are heading. The CMDB persists. It just stops being the answer and starts being one of the inputs.

What this means for IT leaders

The CMDB is not the enemy. Treating it as the centre of the operating model probably is.

Here is a practical test worth running. Pick one critical service. Ask your CMDB "what breaks if this fails?" Then ask the engineers who actually run it the same question. If the answers don't match, the gap you have found is not a data problem. It is a context problem.

The next move is to bridge it. Pick one live data source, deployment events or logs or change records, and connect it to your CMDB data inside a graph structure. Measure whether the answer comes back faster and more accurately. That is the difference between a system that stores data and one that supports decisions.

In 2020, a mature CMDB put you in the top decile of IT operations. By 2026, treating the CMDB as the answer rather than as a data source increasingly puts you on the wrong side of the curve. The leaders aren't abandoning their CMDBs. They are extending beyond them and treating them as one input among many in a context layer that agents can actually reason over.

Further reading

• Charles Betz, "'CMDB' Is Dead — Long Live The IT Management Graph," Forrester, October 22, 2025.

• Mordor Intelligence, "Configuration Management Database (CMDB) and IT Discovery Software Market Size & Share Analysis — Growth Trends and Forecast (2026–2031)."

• REVA University, "Autonomous Multi-Agent System for Integrated SRE and Self-Healing in Cloud-Native Environments."