The agent believes the CMDB in a way your change managers never did

The first time I watched an agent draft a change impact assessment in ServiceNow, the assessment was wrong and the reasoning was flawless. It pulled the affected CI from the change request, walked the Depends on and Runs on relationships in cmdb_rel_ci, found nothing downstream, and recommended a standard change with no CAB review. The server in question ran the payment gateway. Its relationship to the application service had been attached to a duplicate CI created by an import four years earlier.

A human change manager would never have made that call, because every change manager I have worked with knows the CMDB is partly fiction and applies judgement on top. They ring the app owner. They remember the last outage. An agent has none of that. It reads the tables, trusts the relationships, and writes a confident paragraph. Whatever quality your configuration data has today is the quality of every impact statement, every risk score, and every proposed remediation the agent produces.

So before anyone on the ServiceNow AI agents side gets to demo change impact or incident correlation, the CMDB has to survive being read literally. Most instances I review cannot. What follows is the pass I run to get them there.

Three ways a stale CMDB turns into a confident wrong answer

Duplicates are the most common. Discovery creates cmdb_ci_server records with the hostname it observes. An earlier import from the asset tool created the same servers with the hostname in upper case and the serial number formatted with dashes. Identification did not match them, so you have two of every box. Relationships accumulate on whichever copy someone happened to pick in a reference field. The agent walks one copy and reports a clean tree.

Retired CIs that nobody retired are the second. A cluster decommissioned last year still sits in an Operational state with forty relationships, because the decommission change closed without anyone touching the record. Now every change near its network segment looks high risk. The agent asks for CAB on a certificate renewal, and after the third time the change manager stops reading the assessments at all.

Missing relationships are the quiet one. The application service exists, the servers exist, but the Runs on edge was never created because Service Mapping was never finished for that service and the app team was never asked. The agent finds a server with no dependents and says so. Missing data reads as safe, which is the opposite of what you want the default to be.

Discovery fills fields, it does not settle arguments

When I ask who owns the CMDB, the answer is usually the platform team, and the platform team means the ServiceNow admin who runs the Discovery schedules. That person can tell you when the last scan ran. They cannot tell you whether the database cluster listed under the HR service is the right one, because that is a fact about the business, and Discovery only reports what it could reach on the night it ran.

Every CI class the agent will read needs a named person who answers for its accuracy. For servers that is probably the infrastructure lead. For application services it is the app owner, the same person who ought to appear on the service catalog entry as the escalation contact. For network gear it is whoever runs the network, and if they say the CMDB is your problem, that is the first meeting to have, before any agent work starts.

What I actually say in that meeting is short. I put the list of CIs for one service on the screen and ask which person will sign their name to it being correct. A scan cannot sign anything. Somebody always winces at one row, and that row is the first defect on the list.

Nobody has opened the identification rules since go-live

Two sets of rules decide what the agent will find. Identification rules tell the Identification and Reconciliation Engine which attributes make two incoming records the same CI. Reconciliation rules tell it which data source wins when those records disagree on a field. Both were configured during the original implementation, usually by a partner, usually under time pressure, and I have almost never seen either reviewed since.

The usual finding is that the identification rule for servers uses serial number as the first criterion and name as the fallback, which is sensible, and that one of your data sources sends serial numbers in a different format or sends them blank. A blank serial falls through to name, and the name differs in case or domain suffix. New CI every time. The durable business keys guide covers this exact problem in other systems, and it bites harder in the CMDB because nobody notices the duplicates until something reads them.

Reconciliation goes wrong more quietly. During migration the spreadsheet import was given top priority for most fields because it was the only source that existed. Three years later Discovery sees the truth every night and loses to a spreadsheet last uploaded before the current infrastructure lead joined. Open the reconciliation definitions, read the data source priorities, and ask each owner from the previous section which source they would trust today. Then set it that way.

Audit ten services by hand before you widen

The temptation is to open CMDB Health, get a completeness score, and start a programme. I have watched two of those programmes stall at the steering committee stage. The approach that works is smaller and less comfortable. Pick the ten application services the first agent will actually touch, and go through their CIs and relationships one at a time with the owner in the room.

The order matters. Fix the identification rule that caused the duplicates before you merge the duplicates, or the next Discovery run recreates them. Retire the retired. Add the missing Runs on relationships with the app owner watching, because they will correct you. Keep a list of every defect and the rule or process gap that produced it. The record fixes are the cheap part. The rule fixes are what stop it happening again on service eleven.

Ten services takes a small team two to three weeks in my experience, and by the end the rule fixes cover most of what the next fifty services would have surfaced. That is the point at which widening is cheap. Before that, widening spreads the same defects thinner.

  • Export the CIs and relationships for the service and put them in front of the owner.
  • Mark each row as correct, duplicate, retired, or missing, and note the data source that produced it.
  • Trace every duplicate and wrong value back to an identification or reconciliation rule and fix the rule first.
  • Merge, retire, or create the records only after the rule change is in.
  • Rerun Discovery for that service and confirm the fix holds overnight.
  • Have the owner sign off the corrected list and record the date on the service.

Two questions to ask before the agent goes live

The agent readiness check covers owners and recovery for the workflow itself. For the CMDB specifically, add two questions. For each class the agent reads, who signed off the data and when. And when the agent gets an impact assessment wrong, which it will, does the review step show the person the CIs and relationships it relied on, so the defect goes back to the record and the rule rather than to a prompt tweak.

The second question is the one I push hardest on. An agent that shows its sources turns every wrong assessment into a CMDB defect report, which is the best data quality programme you will ever run. An agent that hides them turns every wrong assessment into an argument about the model. The same holds for MCP tools that act on ServiceNow data, which is why the ordinary controls on that data matter more once agents are reading it.

Book the first ten-service session this week. Bring the CIs and the relationships, the identification and reconciliation definitions, and the person who will sign. If you cannot name that person for a service, the agent is not ready to read it either.