top of page
Search

Why Agentic AI Is Only as Good as Your CMDB and Foundation Data

Sep 16
11 min read

Agentic AI is only as trustworthy as the data it acts on. This article explores why CMDB and foundation data – the records of people, sites, services and ownership that sit beneath every enterprise platform – ultimately decide whether an agentic AI programme succeeds or stalls.



Matt Austin | Client Portfolio Lead | Automiq

Author:

Matt Austin

Client Portfolio Lead



For most of the last decade, the configuration management database (CMDB) has been a hygiene factor in large enterprises - useful for change and incident impact assessments, often a key factor in evidencing regulatory compliance - but only becoming a boardroom topic during periods of significant business disruption or high-profile audit findings.


Agentic AI has changed that. When an AI agent can query a system, decide what to do, and act – resetting an account, rerouting a workflow, provisioning access, closing a ticket – it is determining its course of action based on your CMDB and foundation data. If that data is wrong, the agent does not know it is wrong. It simply acts on it, at machine speed, before anyone notices.


While the promise of AI will continue to grab headlines and executive attention, a large contributing factor to its success is a far less glamorous, decades-old discipline that most enterprises have never fully mastered: keeping an accurate model of who owns what, where it sits, and how it all connects.


This article looks at why agentic AI raises the stakes on data quality, what goes wrong when the data is untrustworthy, and what enterprises should do about it.


Contents



Key facts at a glance


  • The foundation matters more than the model. Every leading service management vendor is converging on the same message: agentic AI performance is gated by the quality of the CMDB and foundation data beneath it, not by which large language model is doing the reasoning. [5][6]

  • The stakes have changed, not just the workload. A person working from a stale CMDB record usually catches the error before it becomes a decision. An agent acting on the same record actions it instantly, and often across several systems at once.

  • In most organisations, the data is not ready. Industry estimates put average CMDB accuracy at around 60%, and Gartner has long observed that most CMDB investments fail to deliver their intended value. [8] Gartner separately predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear value and inadequate risk controls - not model capability. [1]

  • The scope of data is not limited to technology. Foundation data explicitly includes people, locations, groups and companies - not just servers and applications. [4] Agentic AI depends on all of it, not just the technical layer.


The foundation data challenge


The challenge is rarely that foundation data doesn't exist somewhere in the organisation - it's that it isn't mastered inside the platform where agentic AI operates. Your ITSM or ITOM platform is the system of action: the place where agentic workflows execute, decisions get made, and changes get triggered. But the true system of record for foundation data usually sits elsewhere - HR platforms hold the definitive view of people and reporting lines, facilities or real estate systems hold sites and locations, and finance systems hold companies and cost centres - with the problem often further compounded by multiple instances of each of these toolsets in the case of complex global enterprises.


As a partner, there are a few common trends we tend to find when it comes to foundation data:


  1. People data is, on the whole, fairly reliable - whether the integration is directly between your system of action and HR system of record, or via your identity provider - every organisation has arrived at the conclusion that the effort involved in maintaining user records in a way that isn't automated simply isn't worth it. The administrative burden is simply too high. With that said - user records do not independently provide the complete picture an AI agent needs in order to act in a reliable manner.


  2. Some "integrations" are manual - during its initial implementation, the service management platform was populated with a one-off export of sites and locations, because how often do we add a new office anyway? Historically, a new office not existing in the system or an office that exists but has been shut down would, at most, cause a minor frustration within the fulfiller team needing to act on the request. This approach made sense in a world where a human was always the one tasked with applying judgement before acting. Agentic AI has removed that safety net.


  3. The integrations exist, but the data governance does not - the record itself updates reliably, but nobody has defined what should happen downstream when it does. A site gets marked as closed in the source system but the open tickets, scheduled maintenance and pending deliveries still tied to it are never reassigned or closed out. A user's line manager leaves and gets deactivated on schedule, but the approvals already sitting in their queue don't automatically fail over to whoever picks up their responsibilities - they simply stall, waiting on an approver who no longer exists.


Agentic AI, in this context, is AI that plans a sequence of steps, calls the systems needed to carry them out, checks the result, and decides what to do next, largely without a human in the loop. That is the shift that matters here: with GenAI we have an assistant that tells a person what it found, and the human makes a judgement call on what to do next. With Agentic AI however we have an actor that will autonomously make decisions on its own, at speed, based on the data available to it.


Why most CMDBs aren't ready


The unfortunate and somewhat uncomfortable truth is that - for a lot of organisations - the CMDB isn't fully trustworthy to begin with. Industry research puts average CMDB accuracy at around 60%, and Gartner’s often-cited assessment is that the majority of CMDB implementations fail to deliver the promised business value, a conclusion a subsequent Forrester analysis has pushed back on in part, while still acknowledging the scale of the underlying problem. [8]


Two familiar failure patterns explain most of the gap:


  • Incomplete and incorrect discoverable data. Configuration items that persist in the CMDB long after the underlying asset has been retired, replaced or reconfigured. Duplicate records that originated from differing discovery sources and haven't been reconciled. Live infrastructure that was provisioned outside of a formal change process and isn't been discovered or actively managed.


  • Missing or outdated non-discoverable data. Service owners that left the organisations several months prior. Business apps with automatically-discovered infrastructure and app-to-app dependencies but no linkage to upstream business services. Maintenance windows that are either empty or incorrect. SLAs that were correct once upon a time, but weren't updated when a new contract was signed.


A human agent troubleshooting an incident can often mitigate by cross-checking elsewhere before taking action. That compensating judgement is what disappears when an agent is given the same record and asked to act on it directly.


Analyst commentary on ITSM AI deployments increasingly reaches the same conclusion: the constraint on value has moved from the AI model to the data underneath it. As one recent industry analysis put it, the organisations getting real value from AI in service management are not the ones with access to better models, but the ones who did the unglamorous work of making their data trustworthy first. [9]


What happens when AI agents act on bad data?


The risk is not hypothetical, and while most errors are easily recoverable, the time and effort involved in the recovery erodes the benefits Agentic AI was tasked with delivering.


We have written elsewhere about what happens when agentic AI is allowed to act without the guardrails that good service management provides – including two documented, real-world incidents in which the absence of proper controls turned an AI system’s error into serious damage: Is IT Service Management still necessary in the age of agentic AI?.


The scale of the exposure is significant. According to Deloitte’s 2026 State of AI in the Enterprise report, 74% of enterprises expect to be using AI agents by 2027, yet only 21% report having mature governance in place to manage them. [10] 


That gap – between the appetite to deploy agents and the maturity of the data and governance beneath them – is where most of the risk in agentic AI programmes currently sits.


The same principle applies directly to security and vulnerability remediation. As we discussed in Patching Vulnerabilities in the Age of Frontier AI, the speed at which modern AI can find and exploit vulnerabilities means rapid, automated remediation is no longer optional – and that remediation is only as fast and safe as the asset data telling the agent what to patch, and what depends on it. Our article on Vulnerability Operations (VulnOps) dives into detail regarding the operating model of the discipline, rather than treating it solely as a technical solution that automates patching.


The governance and regulatory dimension


Regulation has not yet caught up fully with agentic AI, but the direction of travel is one that reinforces the importance of well-managed data, and the governance, guardrails and controls that are needed for Agentic AI to operate safely.


The EU AI Act sets specific obligations on providers of high-risk AI systems around data governance and record-keeping: Article 10 requires that training, validation and testing data be relevant, sufficiently representative and, as far as possible, free of errors, while Article 18 requires automatically generated logs to be retained to ensure traceability and accountability across the system’s lifecycle. [7]


Few Agentic AI deployments for IT Operations will meet the Act’s threshold for “high-risk” but what matters for enterprises today is the underlying discipline the Act is pointing towards: accurate, well-governed data and a demonstrable audit trail of what a system knew and did.


For enterprises already managing operational resilience obligations – a topic we explored in What is Service Mapping, and why does it matter to enterprises? – this will feel familiar. Regulators are, once again, formalising a requirement to demonstrate an evidence-based understanding of your estate that good practice should have delivered regardless. The CMDB and Foundation data accuracy are a cornerstone in meeting this regulatory obligation.


What enterprises should do now - and how Automiq can help


The starting point is rarely new tooling. Most enterprises already own a CMDB and systems of record with more than enough capability – the work is instead focused on improving that data quality within those systems, ensuring they are integrated with up/downstream impacts considered, building an operating model that incorporates ownership and governance to keep things operating smoothly:



If the driver is to start showing value from investments in AI sooner rather than later - pick a partner that can work with you to deliver meaningful value whilst addressing data and governance considerations in parallel - not as an afterthought: Real-world, Business-led Enablement of Service Automation AI Functionality.


The bottom line


Agentic AI does not fail because the models are not capable enough. It fails, or stalls, because the data beneath it – the CMDB, the foundation data, the record of who owns what, where it sits and how it all connects – simply isn't trustworthy enough in most organisations to allow autonomous agents to operate.

The organisations that get real value from agentic AI will not be the ones with the most advanced models. They will be the ones who did the unglamorous work of making their foundation data trustworthy first – and treated that as a leadership priority, not an IT clean-up job.

That work is not exciting or new, and it is not specific to any single platform - it is the discipline that CMDB and foundation data programmes have been striving for. Agentic AI has simply made it non-negotiable.


Frequently asked questions


What is foundation data in a CMDB?

Foundation data is the core referential data that everything else in a CMDB is built on – typically locations, companies, business units, user records, groups and contracts. Whilst often not mastered within the CMDB directly (as the data is typically sourced from specific systems of record), it is imperative the data be accurate to enable safe agentic operations.


Why does agentic AI need accurate CMDB and foundation data?

An AI agent cannot apply human judgement to sense-check a record before acting on it. If the CMDB tells the agent an asset exists, is owned by a particular person, or has certain dependencies, the agent acts on that basis – so any inaccuracy in the data becomes an inaccurate, and potentially harmful, action.


What happens if AI agents act on bad CMDB data?

Common outcomes include failures when attempting actions against assets that no longer exist, notifying or seeking approval from the wrong owner, missing the true blast radius of a change, and breaching data residency or jurisdictional constraints that were never visible in the record.


Is a CMDB the same thing as a service map?

No. A CMDB or asset register tells you what you have; a service map shows how those components combine to deliver a business service, and what happens if one of them fails. A service map is typically a business-aware view built on top of accurate CMDB and foundation data, not a replacement for it – see What is Service Mapping, and why does it matter to enterprises? for a fuller explanation.


Which CMDB or ITSM platforms support agentic AI?

Most major platforms – including ServiceNow, Freshworks (Freshservice), Atlassian, and BMC Helix among others – have agentic AI capability that can leverage (and in some cases, help to manage) CMDB and foundation data. The right platform depends on an organisation’s existing estate, and the technology choice matters far less than the accuracy of the data feeding it.


How accurate does a CMDB need to be before deploying agentic AI?

There is no single industry-agreed threshold, and demanding perfection can itself stall a programme indefinitely. The more useful approach is to take a risk-based approach to prioritise accuracy and currency for the specific services, assets and dependencies an agent will actually touch, and expand deliberately from there – rather than attempting to perfect the entire CMDB before starting.


Where should an enterprise start if its CMDB is not ready for agentic AI?

Start with an honest assessment of data quality and ownership for the specific services and assets the first agentic use cases will touch, rather than the estate as a whole. Fix ownership and dependency data for that scope, embed the processes that keep it current, and expand agent autonomy only as far as the underlying data can be trusted.


Sources and further reading


Automiq logo light
bottom of page