
.avif)
Almost every ITSM tool on the market ships with a CMDB. The tin promises you full configuration tracking, change history on every CI, real-time updates. Then you open the product, and you’re looking at a list of laptops.
Every IT forum thread about CMDBs has this complaint on repeat. Teams have IT asset management — things are tracked, serials are current, warranties are logged. What they don’t have is the thing they were sold: a live picture of every configuration item, how it relates to everything else, and which business services depend on it.
The difference matters more than the vocabulary suggests. A CMDB is the relationships, the CI classes, the business applications and services that sit on top of them, and the people who own them. ITIL is deliberately flexible here, which means no two organizations need the same kind of CMDB — what matters is what your environment actually requires, and whether it’s still accurate next week. (Learn more about CMDB vs asset management.)
Staying accurate is the hard part. So we built an AI Coworker whose only job is to help you with that.
This demo environment I built looks like most real ones. The asset library holds a little over 1,000 records — laptops, MDM-connected devices, Windows machines, applications, cloud resources. It also holds duplicate assets, duplicate services, and retired VMs sitting right next to live ones.
That’s what ITSM tools hand you today, and it’s genuinely useful. However, it’s not enough because it’s just inventory. Retired items have no business being in a CMDB, because nobody is going to configure or change them.
CMDB Architect is an AI Coworker with one job: maintaining a living CMDB. On its first run it builds the CMDB from your asset library and produces a full report. After that, it keeps it current. It also takes input on what belongs in the CMDB and what doesn’t, and tunes itself on that feedback.
Kicking it off took one request: “Build me a full CMDB and also get me a full interactive report.” The request routed to IT Operations Management, and CMDB Architect picked it up on its own.
It checked for an existing CMDB first to compare the existing model against live infrastructure and recent changes — devices added, removed, replaced, retired, or damaged.
Then it used its memory to create the CMDB model — Configuration Item, CI Relationship, CMDB Class, Business Application, and Business Service types — and deduplicated records from 989 source assets. It built out CI classes and relationships for printers, desktops, servers, virtual machines, network devices, app services, and software packages, each with counts, owners, and links to the users and devices they belong to. Applications deployed in Azure came in with lifecycle status and subscription IDs, grouped into business applications by resource group.
The report itself is built for drilling down. A Sankey view traces each resource group down through compute, VMs, and network interfaces. Composition shows every live CI by layer and class. Software usage shows who has what installed, with license data where it exists — in the demo environment it surfaced consumer apps pulled from the Windows Store onto work machines, which is its own conversation. Where assets carry cost data, the report rolls it up: roughly $774K in hardware purchase cost here, with warranty status and age alongside it.
Honestly, the most useful section isn’t any of the above. It’s the gap report.
Asset coverage came in at 23.4% — 238 of 1,016 assets — with a data quality score of 63 and a breakdown of exactly what’s missing, including cloud resources with incomplete details. A tool optimizing for a good demo would have buried that. A coworker you’re going to run every week should tell you where your source data is broken, because that’s the list you actually act on.
The first run is the easy part. The value is in what comes after.
Schedule CMDB Architect as a weekend or weekly maintenance task and your configuration data stays current without anyone blocking out a Friday for it. When an auditor asks who changed an asset, or which deployment touched a service, the answer is already there — and change management gets a lot easier when the dependency map underneath it is real.
If you’d like to see how AI Coworkers like this get built and governed, come talk to us and bring your messiest inventory.