Large enterprises pull configuration item data from Discovery, SCCM, Intune, Dynatrace, and other sources, and the overlaps between them create duplicate Computer CIs that quietly erode CMDB trust. Service mapping breaks, and incident and change decisions end up built on the wrong record without anyone realizing it.
The team behind KeenStack’s 3rd place StackUp solution, built an AI agent that finds those duplicates, explains why it thinks they’re duplicates, and recommends which record to keep, all before anything actually merges. Detect the duplicates, explain them, and act, with a human in the loop the whole way.
How it works
The workflow moves through four stages. Detect automatically flags duplicate Computer CIs using serial number and matching logic. Analyze hands the candidate pair to an AI agent that explains why the records match, then returns a confidence score, a likely root cause, and the business impact if both records stay active. Recommend identifies the safest primary CI to retain out of the group, typically the record with the cleaner canonical name rather than a clone-style variant. Sync writes the finding back to ServiceNow as a formal Duplicate Candidate record and pushes the relationship into a Neo4j graph database for visualization.
Nothing gets merged or deleted automatically. Every duplicate candidate lands in ServiceNow with an explicit recommendation to retain a tentative master record and route the pair for human CMDB review before any merge or retirement decision. The explanation reads like something a person would actually write: which fields match, which don’t, and why the tie was broken the way it was.
Why it matters
Manually investigating a suspected duplicate today means pulling up both records, comparing fields by hand, and guessing at which one is authoritative. The team’s own estimate puts the reduction in that manual investigation work at 80 to 90 percent, which is less about speed for its own sake and more about engineers no longer needing to context-switch into detective work every time two records look similar.
The graph layer is what turns individual duplicates into a bigger picture. A duplicate pair on its own is a minor cleanup task. The same relationship visualized alongside dozens of others in Neo4j exposes clusters and high-risk patterns that would be invisible looking at one CMDB record at a time, which is what lets a team catch a systemic naming or import problem instead of just patching the same duplicate over and over.
What the pilot showed
Running against a live CMDB, the pilot surfaced 90 total duplicate candidates, 70 still requiring action and 20 already resolved with AI assistance, with 20 duplicate CIs retired to date. Root causes broke down across a handful of clear patterns: duplicates created during SCCM imports, serial numbers matching an existing record, asset tag conflicts, and inconsistent naming conventions, each visible on its own in the analytics dashboard rather than buried in free text.
In one representative case, two records sharing the serial number DUPSER004 came back with a duplicate score of 96 and a recommendation to retain the record without the “-CLONE” suffix, reasoning that included the shared timestamp, blank IP and MAC fields on both records, and the naming pattern as the deciding factor. That level of detail, on every flagged pair, is what makes the recommendation something a reviewer can actually trust rather than take on faith.
AI-Powered CMDB Duplicate Detection is one way to bring trustworthy deduplication to a CMDB. If yours could use the same solution, reach out to KeenStack.
Built by
Mohamed Hafiz
Deepthi Swarnaa
Varshine Thirunavukkarasu