What looks complete is being held together by people.
Most CMDBs are wrong in small ways. Some are wrong in large ones. Either way, the gap between what the data says and what is actually deployed has been survivable for years, because experienced operators quietly correct for it.
That correction has a name now: the human compensation layer.
It is the thing that keeps the wheels on when the asset record, the configuration relationship, and the running system do not quite agree. An engineer looks at a dependency map, recognizes two relationships as stale, ignores one, mentally updates the other, and reasons forward from what they know to be true.
AI agents do not do that.
At Team '26, Atlassian made Rovo Ops generally available as the out-of-the-box operations agent for Jira Service Management. The Rovo Ops agent summarizes incident context, surfaces likely root causes, drafts post-incident reviews, and connects directly to observability tools like New Relic and Dynatrace.
Behind it: the Incident Command Center for AI-assisted real-time investigation, and the Incident Prevention Center for proactively assessing change risk before it becomes an incident. Assets is getting purpose-built updates aimed at smarter, more usable asset management.
The Teamwork Graph, now exposed through the Atlassian MCP, means AI systems outside of the Atlassian Cloud will also reason against this data.
This is no longer theoretical. The agents are arriving, and they will reason against whatever the operational graph says.
That distinction matters. Asset management tells you what exists. Configuration management tells you how those things relate, depend on each other, and behave as part of a service. Most organizations blur that distinction in practice, because the same tool, the same CMDB conversation, and often the same team carries both concerns.
Humans have been quietly absorbing the consequences.
An experienced operator who sees an incorrect CI relationship pauses, questions it, and routes around it. They know the server exists, but they also know the dependency shown in the CMDB has been wrong since the last migration. They know the application record is current, but the upstream service relationship is not. They know the documented owner is technically correct and operationally useless.
An AI agent treats those things as ground truth and keeps going — faster than anyone can interrupt.
The wrong relationship does not slow the investigation down. It misdirects it, confidently, before a human is in the loop.
Bad CMDB data has always been a liability. It now has an execution path.
Most CMDB conversations are framed inside-out: do our assets and configuration items accurately reflect what we have?
It is a reasonable question, and it is not the question that matters most.
The CSX question is outside-in. Does our operational data accurately reflect how services are experienced by the people who depend on them?
Those are not the same thing. A CMDB can be technically tidy — every device documented, every application present, every relationship populated — and still describe a system that has very little to do with how a service actually behaves under load, after the last three changes, in front of the people using it.
The inside-out view optimizes for inventory accuracy. That matters. You need to know what exists, who owns it, where it lives, and whether it is still in use. But service experience depends on more than existence. It depends on relationships, dependencies, failure paths, ownership realities, support boundaries, and the practical knowledge operators use when the documented model is almost right but not quite right enough.
That is where configuration data either becomes useful or dangerous.
AI agents will reason from whichever view your data reflects. If your asset and configuration model was built to satisfy audit, it will produce audit-shaped answers. If it was built to reflect service experience, it will produce answers that connect to what the business actually cares about.
The first reflex on reading this is to ask what to clean up first. That is the right instinct, and it is also where most organizations have stalled for the better part of a decade.
The CMDB hygiene conversation is not new. It used to be a quality-of-life problem. Now it is an operational risk control.
A few things are worth being honest about. Most CMDBs were built around technology categories, not services. They describe inventory more naturally than experience. Most dependency mappings have decayed since the last change-management cycle that took them seriously. And most organizations have, until very recently, been quietly fine with that, because the humans on the keyboard knew where the gaps were.
None of that is a tooling problem by itself. It is a discipline problem.
AI does not fix it. AI removes the cover it has been hiding under.
That does not mean every organization needs to boil the ocean and rebuild its CMDB before using AI in operations. That is not realistic, and it is not how this work happens. But it does mean teams need to stop treating asset and configuration maturity as back-office cleanup. The data underneath operational AI is now part of the blast radius.
Treat it that way.
This article is not the playbook. The point is more basic: your CMDB has always been amiss. It just had a translator.
Currently, CSX Masters has an ongoing series on this topic. Assets Masterclass, with Gaurav Gupta, Atlassian Solution Architect, covering how Atlassian Assets can power real operational workflows across IT, HR, Facilities, and other business functions.
Events like this one is where the "what to do about it" lives. And if you miss any of them, they are recorded and the recordings are available on the event page after the fact.
This article is part of a "Beyond ITSM" series, written by the Atlassian Community Champions behind the virtual Atlassian Community Events chapter, CSX Masters.
See also…
Dave Rosenlund is an Atlassian Community Champion and the founder of the virtual Atlassian Community Events chapter, CSX Masters (fka ITSM/ESM Masters). He also helps out with the Program/Project Masters chapter and the Boston ACE.
In his day job, he works for Platinum Atlassian Solution Partner, Trundl.
Dave Rosenlund _Trundl_
0 comments