Agentic AI For CMDB Accuracy: A Practical Use Case

3 min read
Sep 24, 2026, 9:00:01 AM

The most practical use of agentic AI for configuration management database (CMDB) accuracy today is evidence-gathering on work that's already queued: de-duplication tasks, stale configuration items (CIs), unanswered ownership certifications. An agent can collect the facts an analyst would check, propose a decision, and hand it to a person for approval. That shortens the slowest part of the job without letting an AI change your CMDB unsupervised. The design work is in the evidence, the guardrails and the measurement.

Why de-duplication is a good first use case

De-duplication backlogs grow large, and each task needs the same investigation. On one estate we worked on, misconfigured identification and reconciliation rules had left more than 50,000 de-duplication tasks unworked. Clearing them took two analysts eight weeks.

Most of that time goes on repetitive checks before a decision can be made. For each duplicate pair, an analyst looks at:

  • which source created each CI, and when each was last updated
  • which record has open incidents, changes and vulnerability items
  • which record carries the relationships and service map membership
  • whether the pair sits in the same class
  • which identifying attribute they share, and whether it's a placeholder value

Those checks follow rules, draw on data already in ServiceNow, and end in a decision a person can verify quickly. That's the shape of task agents handle well.

Designing the agent's job

Inputs. An open de-duplication task and read access to the CIs, their related records and their source history.

Evidence. A structured summary of the checks above, for every CI in the task, written into the task record.

Proposal. A recommended surviving CI, the attributes and relationships to carry across, and a confidence level with its reasons.

Escalation. Tasks the agent should never propose on: pairs in different classes, CIs in critical services, or pairs matching on a known placeholder value. These go straight to an analyst, flagged with the reason.

Output. Nothing changes in the CMDB until a person approves. Approved proposals are then executed through the standard remediation route, the same as a manual merge.

Stage Agent does Person does
Gather Collects evidence and writes it to the task Nothing
Propose Recommends a surviving CI with reasons Nothing
Decide Nothing Approves, amends or rejects
Execute Nothing, or runs the approved merge Spot-checks results

Guardrails that make it safe

Start read-only. Run the agent on evidence and proposals alone for several weeks, with analysts deciding as normal. Compare the agent's proposals with what analysts chose.

Earn approval thresholds. Only once agreement is consistently high for a class, consider allowing batch approval for high-confidence proposals in that class. Keep one-by-one approval everywhere else.

Log everything. Every proposal, its evidence, the approver and the result go into an audit trail you can show to an auditor.

Fix the cause alongside. The agent clears the backlog. It doesn't stop new duplicates arriving. Placeholder values, weak identifier entries and mapping errors still need fixing, as our article on ambiguous CI matches describes.

Measuring whether the agent is helping

Track key performance indicators (KPIs) that show both speed and quality:

  • agreement rate between agent proposals and analyst decisions, by class
  • time from task creation to decision, before and after
  • merges later reversed, split by agent-proposed and analyst-originated
  • tasks escalated by the agent, and the reasons

A falling agreement rate in one class usually means that class's data has changed in a way the agent's checks don't cover. Review the checks before expanding scope.

Record in the RACI (responsible, accountable, consulted, informed) who owns the agent's rules, who approves proposals, and who reviews reversals. Put changes to the agent's checks and thresholds through change management.

Other queues that suit the same pattern

The same gather, propose, decide pattern works on:

  • Stale CIs. Gathering the last discovery date, recent tickets and relationships, then proposing retirement or investigation.
  • Unanswered certifications. Checking whether the owner is still active, and proposing a successor from the service or management chain.
  • Unmatched vulnerability findings. Searching for likely CIs by partial identifiers, and proposing a match for an analyst to confirm.

Each depends on the CMDB already being reasonably sound. Our AI readiness article covers how to judge that.

How Apex helps

Our data quality assessment measures your CMDB against weighted critical success factors, key performance indicators and metrics, and shows where de-duplication, normalisation and reconciliation are failing and why. It's the right starting point for deciding which queues an agent could help with, and which causes need fixing first. We scope it with you at an initial consultation.

Book a CMDB diagnostic call or arrange a meeting with a consultant.

Frequently asked questions

Should an AI agent be allowed to merge CIs on its own?

Not at first. Start with evidence and proposals, measure agreement with analysts, and only consider batch approval for classes where agreement is consistently high.

Will an agent fix our duplicate problem?

It can shorten backlog work. New duplicates will keep arriving until identification rules, placeholder values and source mapping are fixed.

What data does the agent need access to?

Read access to the CIs, their source history, related tickets and relationships. Write access only through the approved remediation route.

How do we explain agent decisions to auditors?

Keep the evidence, proposal, approver and outcome for every task in an audit trail.

 

 

Written by Iain Moone, Apex Configuration Group.

 

 

Get Email Notifications