One of our customers has 157 separate ingestion sources feeding server data alone.
Scanners, cloud connectors, agent-based discovery, manual imports, homegrown scripts somebody wrote five years ago and nobody's touched since.
All of it eventually has to land as one coherent picture of what a server actually is in that environment. That's the job the CMDB has always had, and it doesn't get easier as the number of sources climbs. It gets harder, and it gets more important at the same time.
Now add AI agents to that list of sources, because that's already happening whether we ship anything or not. I've talked to customers who built their own MCP servers on top of our CMDB well before we had an official one, stitching together access however they could, because their agents needed a way to query and act on configuration data and waiting wasn't an option.
I understand the instinct. I also understand the risk: an agent interacting with your CMDB through a homegrown integration has no obligation to respect the reconciliation rules, the identification logic, or the governance you spent years building. Data can go in, or come out, divorced from the context that made it trustworthy in the first place.
That's the problem this quarter's release is actually about: making sure every source, human, script, or agent, has to earn its way into the CMDB the same way.
CMDB MCP Server — Governed Access for the Agents Already Showing Up
The CMDB MCP Server, now in controlled availability (open to select customers now, with broader rollout to follow), is our answer to the DIY integrations customers were already building. It's a scoped set of tools: CMDB Search, get application service topology, create a CI, get an impact graph, and a handful of others, sitting behind OAuth, with admins deciding exactly what an agent can touch. Read-only for teams that just want agents reasoning over the data. Full create-and-update access for teams that are ready to let an agent act on it directly.
Here's the part that actually matters: it doesn't bypass IRE. Whatever discipline you've built into how CIs get created and reconciled still applies, whether a human is filling out a form or an agent is calling an API through MCP. That's the whole difference between this and the homegrown version most of those 157-sources customers were cobbling together. The homegrown version has no idea what your identification rules are. Ours does, because it's built on the same facilities everything else in your CMDB already respects.
I'll be straight about where this stands. It's controlled availability for a reason. Setup takes real effort, OAuth configuration included, and I've hit rough edges demoing it myself. If you're already building agent workflows against your CMDB, or fielding requests to, this is worth getting on your radar now. The governance underneath it is the reason to wait for this instead of creating your own.
Dynamic IRE Rule What-If Analysis — Testing Before You Trust
Which brings me back to those 157 sources, because that's exactly the kind of scale where IRE tuning gets genuinely hard. Every new source can mean revisiting identification rules across the board, attribute by attribute. I've sat in calls where we spent thirty minutes on a single attribute. That doesn't scale, and pretending otherwise doesn't help anybody.
Dynamic IRE is the long-term answer to that problem, built to process identification and reconciliation against live context instead of requiring you to hand-curate every rule. It's not generally available yet. What ships this quarter, available now, is the what-if analysis: a way to run a real payload through dynamic IRE and compare the result against what your current, manually configured IRE would do. You get a parity score, something like 99% in the example I've seen, plus a breakdown of exactly where the two diverge. There's also an AI summary option if you'd rather not comb through the raw comparison line by line.
The value is that you can test the future state against the present one before committing to anything operationally. Same principle as the MCP Server, honestly: don't let something new touch your CMDB until you know exactly how it behaves.
De-Dupe Task Remediation Agent — Getting You to the Decision Faster
More sources also means more duplicates, and if you've used the de-dupe wizard before, you know the drill. Pick your main CI. Decide which attributes to keep. Sort out relationships. Repeat for every CI in the pile. Piles happen, six, seven, ten duplicate CIs isn't unusual, and each one means research to figure out what's actually correct.
The remediation agent, available now, does that research for you. It looks at the details of each duplicate CI and pre-populates the wizard: main CI selection, which attributes to keep, which relationships survive. Then it jumps you straight to review and gives you the reasoning behind each call. Used this attribute because it was the most recently updated. Kept this relationship because that CI had more current connections.
You still get the final say. Nothing merges until you confirm it. De-duplication is one of those areas where a wrong automated decision doesn't just create noise, it can quietly delete something you needed. I've described this phase as self-driving with your hands still on the wheel, and that's exactly where we are. The long-term direction is full autonomous de-duplication. That's not what ships this quarter, and I'd rather tell you that directly than let you assume otherwise.
CMDB Success Advisor for Foundation — A Health Check That Points Somewhere
The 3 C's report—Completeness, Correctness, Compliance—has been around forever, and if you've used it, you know it has a way of boiling the ocean. It gives you data, but figuring out which data needs immediate attention and which can wait in your specific environment has always been a separate lift.
The Success Advisor for Foundation, a store plugin available now, closes that gap. It looks at the basics: principal classes set up correctly, management groups that aren't missing, the foundational stuff everything else depends on. You get outcome-oriented scoring, and clicking into a health issue takes you straight to the CIs that need attention.
This is the first in a series. Advisors for software asset management, change, and incident are coming, each looking at CMDB health through the lens of a specific outcome. Foundation is where it starts because foundation is what everything else builds on, agents included.
A quick note on CSDM 5.1
Worth mentioning even though it's not a feature you install: we're publishing new CSDM guidance on how to model AI agents across their full lifecycle, going beyond what AI Control Tower's governance layer already covers. Non-human identity. Agent-to-agent communication. Which platform an agent actually lives on, whether that's Bedrock, Azure AI Foundry, Vertex AI, Copilot Studio, or somewhere else entirely, and CSDM 5.1 is built to model all of them the same way.
That consistency is the point. Right now, every vendor and every enterprise is inventing its own answer to "what is an AI agent, structurally speaking," and those answers don't talk to each other.
CSDM has spent years becoming the closest thing the industry has to a shared language for what a business service, an application, or an infrastructure component actually is. Extending that same discipline to AI agents means an agent modeled in one environment means the same thing in another, whether that environment runs on our platform or not. About 80% of the customer conversations I'm in these days touch this in some form, and what people are really asking for isn't a ServiceNow feature. It's a standard they can trust, one that's already been proven at scale across a few hundred thousand implementations of CSDM before agents ever entered the picture.
If you're trying to figure out how to represent agents in your CMDB today, or how your organization is going to talk about agents with partners, auditors, or other platforms down the road, this paper is worth your time now, whether or not every element in it applies to your environment yet.
Smaller updates worth a mention
- New and updated Service Graph Connectors for Dynatrace SaaS, Tanium Endpoints, Google Chromebooks, Confluent, and Apigee Edge
- CMDB Workspace refinements
- CI Class Model updates including new AI data model entities; and
- a new Data Foundations Mainline Certification if you're looking to formalize your team's CMDB fundamentals.
Broader Impact
157 sources was already a hard problem before agents entered the picture. Now the CMDB has to hold the line against sources that don't just feed data in, but reason over it and sometimes act on it directly. The MCP Server, the IRE testing tool, the de-dupe agent, and the Success Advisor are four different answers to the same underlying requirement: whatever's touching your CMDB, human or agent, has to go through the same governance everything else already does.
CSDM 5.1 takes that same requirement and points it outward. It's one thing to get your own CMDB in order. It's another to hand the industry a model that says here's what an AI agent is, here's how it relates to everything around it, and here's how to talk about it consistently, no matter which platform it runs on or which company wrote the software. That's a bigger claim than any single feature in this release, and it's the one I'd bet on mattering most a few years from now.
Closing Reflection
157 sources, and counting, because agents are the newest source and they won't be the last. The instinct to just wire something up and let it run is understandable. I've felt it myself.
Here's what I keep coming back to: the CMDB has always been about making sure whatever lands there means the same thing to everyone and everything that touches it next, and now that includes a model the rest of the industry can build on too. Get that right, and it won't matter how many sources show up next quarter, or which platform they run on. There will already be a common answer for what they are.
