AGENTIC AI · CMDB DECISION WALKTHROUGH

How the agent checks, decides, and communicates.

Pick a scenario below to walk through the full decision flow — every check the agent runs, how it weighs conflicting evidence, what it decides, and how it communicates the outcome to stakeholders.

APP-WEB-042
Class
Linux Server
Environment
Production
Owner field
— Empty —
Last updated
428 days ago
OWNERSHIP MISSING
1Detect
→
2Gather Evidence
→
3Reason
→
4Resolve Conflicts
→
5Score Confidence
→
6Decide
→
7Communicate
1
Detect — Why was this CI flagged?
Discovery Agent · Governance scan, run 2026-05-18 02:00 UTC
FLAGGED
✗
Required field check
cmdb.ci.owner IS NULL
Owner field is empty
RULE
!
Currency check
days_since(last_verified) {`>`} 365
428 days since last update
RULE
ⓘ
Criticality signal
production tag + customer-facing
High priority — escalate
RULE
2
Gather — What does each source say?
Ownership Agent · Queried 8 sources in parallel · 2.4s total
8/8 RESPONDED
✓
ServiceNow ITSM
tickets WHERE ci=APP-WEB-042 LAST 180d
Rajesh Patel filed 8 tickets
Top contributor
MED
✓
Active Directory
SSH/sudo access on host
3 users: Rajesh P., Maria S., svc-deploy
Mixed signal
MED
✓
Jenkins CI/CD
pipelines deploying to host
Pipeline owner: Team Phoenix
Last deploy 4 days ago
HIGH
✓
AWS Tags + Billing
resource tags on i-0a4b9...
cost-center: CC-4420
project: customer-portal
HIGH
✓
PagerDuty
alert routing for host
Routes to Customer Portal On-Call
12 incidents in 90d
HIGH
✓
Workday HR
CC-4420 → team → manager
Team: Customer Portal
Manager: Maria Santos
HIGH
!
Old CMDB note
historical owner field (audit log)
John Smith (left company 14 months ago)
Stale — disregard
LOW
✓
Dynatrace APM
application dependency map
Hosts: customer-portal-web
Calls: orders-api, auth-svc
HIGH
3
Reason — How does the model interpret the evidence?
Model Plane · Reasoning LLM with knowledge graph context
REASONED
🧠 AGENT REASONING
Six of eight sources point to the Customer Portal team (a.k.a. Team Phoenix). The AWS cost center CC-4420 is the strongest anchor — it maps unambiguously through Workday to a single team and manager. The Jenkins pipeline owner, PagerDuty rotation, and APM application name all corroborate this independently.

For the accountable owner, the right person is Maria Santos (team manager via HR org chart) — not Rajesh Patel, who is the most active engineer but reports into Maria. Rajesh should be recorded as technical contact.

The historical CMDB owner field showed John Smith, but HR confirms he left 14 months ago. This is why ownership decayed — no successor was assigned. Disregarded from the decision.
⚠ Conflict detected & resolved
CMDB historical record
John Smith
Workday HR (current)
Maria Santos
Resolution: Source of Truth Registry rule SOT-OWNER-01 — when CMDB conflicts with HR for ownership, HR wins if the CMDB record is older than 90 days. CMDB record is 428 days old → HR data prevails.
4
Score — How confident is the agent?
Confidence Scorer · Weighted by trust score of each source
92% CONFIDENCE
AWS cost center (CC-4420)
0.95
Workday → Manager mapping
0.93
PagerDuty alert rotation
0.90
Jenkins pipeline ownership
0.88
APM application mapping
0.85
ServiceNow ticket activity
0.60
Weighted aggregate confidence
Threshold for auto-apply: 90%
92%
5
Decide — What action does the agent take?
Policy Plane · Confidence 92% ≥ 90% threshold → Auto-apply with notification
AUTO-APPLIED
✓
Owner assigned with notification
Auto-applied at 02:14 UTC · Reversible for 24h
BEFORE
Ownerempty
Technical contactempty
Owning teamempty
Cost centerempty
Last verified428d ago
→
AFTER
OwnerMaria Santos
Technical contactRajesh Patel
Owning teamCustomer Portal
Cost centerCC-4420
Last verifiedToday
6
Communicate — Who hears about it and how?
Notification Service · Tailored message per audience
3 NOTIFICATIONS SENT
To Maria Santos · From CMDB Agent
EMAIL
Subject: You've been assigned as owner of APP-WEB-042 — please confirm
Hi Maria,

Our CMDB cleanup agent has assigned you as the accountable owner of APP-WEB-042 (Linux production web server, part of the Customer Portal application).

Why you? Multiple authoritative sources point to your team — the AWS cost center CC-4420, the Jenkins deployment pipeline, the PagerDuty rotation, and your team's APM application all map to this server. Workday confirms you as the manager of the Customer Portal team.

Technical contact: Rajesh Patel (most active engineer on this server)

Confidence: 92% — assignment is provisional and you can correct it.

Action needed: Please confirm within 7 days. If this isn't right, click "Reassign" and the agent will re-evaluate.
To Rajesh Patel · From CMDB Agent
SLACK DM
👋 Hi Rajesh — you've been recorded as the technical contact for APP-WEB-042. This is based on your ticket activity and SSH access. No action needed from you, but Maria Santos (your manager) has been asked to confirm overall ownership. You'll be the routing target for technical questions on this CI going forward.
To CIO Office · From Governance Agent
WEEKLY DIGEST
Included in this week's executive digest as one of 247 ownership resolutions auto-applied. Aggregate metrics: 92% avg confidence, 0 rollbacks, 14 escalations to managers, 3 pending CC owner approvals. Estate ownership coverage moved from 86% → 91% this week.
7
Audit Trail — Every action recorded
Evidence Ledger · Immutable · 7-year retention
8 ENTRIES
02:00:14disc-agentFLAG ci=APP-WEB-042 reason=owner_missing,stale
02:00:18orchDISPATCH task=owner_resolve target=ownership-agent
02:00:21own-agentQUERY sources=[snow,ad,jenkins,aws,pd,workday,cmdb-hist,apm]
02:00:23own-agentRECEIVE 8/8 responses · evidence_id=EV-2026-051847
02:00:25modelREASON conflict_detected=cmdb_vs_hr resolved_by=SOT-OWNER-01
02:00:26scorerSCORE confidence=0.92 threshold=0.90 verdict=auto_apply
02:00:28corr-agentWRITE cmdb.owner=maria.santos technical_contact=rajesh.patel
02:00:30notifSEND email→maria.s slack→rajesh.p digest→cio_office
prod-db-01 (×3)
Suspected dupes
3 records
Class
Database server
Detected by
Embedding similarity
DUPLICATE SUSPECTED
1Detect Similarity
→
2Compare Attributes
→
3Verify Live
→
4Merge Plan
→
5Decide
→
6Communicate
1
Detect — Why are these suspected duplicates?
Discovery Agent · Vector embeddings flagged 3 records with similarity {`>`} 0.85
3 CANDIDATES
!
CI-77831: "prod-db-01"
Created 2021-03 · Source: manual entry
IP: 10.4.2.18 · MAC: 00:1A:...:7E
Owner: empty
SUSPECT
!
CI-92104: "proddb01.acme.local"
Created 2023-01 · Source: SCCM discovery
IP: 10.4.2.18 · MAC: 00:1A:...:7E
Owner: DBA-Team
SUSPECT
!
CI-104522: "PRODDB-01"
Created 2024-06 · Source: AWS discovery
IP: 10.4.2.18 · MAC: 00:1A:...:7E
Owner: Cloud-Ops
SUSPECT
2
Compare — Attribute-by-attribute reconciliation
Entity Resolver · Match on hardware identity, then differentiate on metadata
SAME PHYSICAL HOST
✓
MAC Address
unique hardware identifier
All 3 records: 00:1A:4F:B2:9C:7E
MATCH
✓
Serial number
BIOS / hardware serial
All 3: VMW-564D2A1B-...
MATCH
✓
IP Address
current network IP
All 3: 10.4.2.18
MATCH
!
Hostname
DNS / display name
Variants: prod-db-01, proddb01.acme.local, PRODDB-01
Same host, different naming conventions
VARIANT
🧠 AGENT REASONING
All three records share the same MAC, serial, and IP — they are unambiguously the same physical host. The hostname variations are naming convention drift across discovery sources (manual entry used a hyphen, SCCM appended the FQDN, AWS uppercased). The three records were created by three different discovery methods over three years; none ever reconciled.

Plan: Keep CI-92104 as the canonical record (it has the most complete metadata and an assigned owner). Merge the other two into it, preserving relationships and history.
3
Merge plan — Which attributes survive?
Source of Truth Registry · Best-source-wins per attribute
PLAN READY
3 SEPARATE RECORDS
CI-77831No owner, stale
CI-92104DBA-Team, complete
CI-104522Cloud-Ops, partial
RelationshipsScattered (14 total)
IncidentsSplit across 3 IDs
→
1 CANONICAL RECORD
CanonicalCI-92104
OwnerDBA-Team
Hostnameproddb01.acme.local
RelationshipsUnified (14, dedup'd)
Retired CIsCI-77831, CI-104522 → aliased
4
Decide — Auto-merge or human review?
Policy Plane · Bulk merge requires human approval (CAB rule)
REVIEW REQUIRED
⚠ Policy gate: structural changes need approval
Confidence is high (97%) but the policy POL-MERGE-01 requires human approval for any action that deletes or retires CI records. Routed to CMDB administrator queue with full evidence package.
5
Communicate — Approval request & impacted teams
Notification Service · Targeted to decision-makers
3 NOTIFICATIONS
To CMDB Admin Queue · From Discovery Agent
APPROVAL REQUEST
Action requested: Merge 3 duplicate CIs into canonical record CI-92104
Evidence summary: All 3 records share identical MAC, serial, and IP — physically the same host. Created independently by manual entry (2021), SCCM (2023), and AWS discovery (2024).

Recommended canonical: CI-92104 (most complete metadata, owner already set to DBA-Team)
To be retired: CI-77831, CI-104522 (will become aliases pointing to canonical)
Relationships preserved: 14 dependencies merged, deduplicated to 11
Confidence: 97%

Rollback: One-click reverse for 7 days post-merge.
To DBA-Team, Cloud-Ops · From Discovery Agent
FYI · SLACK
Heads up — a CMDB merge is pending review that will consolidate 3 records for proddb01 into a single canonical CI. Your team is listed as an owner on one of them. No action needed from you; we'll notify when the merge completes. Full evidence: [link]
LEGACY-APP-SVR-19
Class
Windows Server 2012
Last verified
2 years 3 months ago
CMDB status
Active
STALE — DECOMMISSION?
1Detect Stale
→
2Liveness Check
→
3Usage Analysis
→
4Impact Reasoning
→
5Decide
→
6Communicate
1
Liveness check — Is this server even running?
Discovery Agent · Multi-method liveness probe
NOT RESPONDING
✗
ICMP ping
3 attempts to 10.8.14.205
No response · Host unreachable
HIGH
✗
Nmap port scan
tcp/22, 80, 443, 3389
All ports closed/filtered
HIGH
✗
SCCM agent check-in
last heartbeat
Last seen: 814 days ago
HIGH
✗
DNS resolution
A record lookup
NXDOMAIN — record was removed
HIGH
✗
VMware inventory
vCenter VM list
VM not present · Likely deleted
HIGH
2
Impact reasoning — Is anything depending on this?
Impact Reasoner · Graph traversal across CMDB relationships
ZERO DEPENDENCIES
✓
Active incidents (90d)
tickets referencing this CI
0 incidents
CLEAR
✓
Application dependencies
APM + relationship graph
No app traffic in 18 months
CLEAR
✓
Change tickets
change requests against CI
Last change: 26 months ago
CLEAR
✓
Backup activity
Commvault job history
No backups since 2024-Q1
CLEAR
🧠 AGENT REASONING
Every liveness signal confirms this host is gone — not just sleeping. The VM is no longer in vCenter, DNS was cleaned up, and SCCM hasn't heard from it in over 2 years. Impact reasoning shows zero downstream dependencies: no traffic, no tickets, no backups, no change activity.

This is a classic "zombie CI" — the asset was decommissioned, but the CMDB record never got updated. Cost: this CI still consumes monitoring license slots and is included in patch compliance reports as a "non-compliant" host, inflating risk metrics.

Recommendation: Retire the CMDB record with status "Decommissioned (inferred)".
3
Decide — Retire or hold?
Policy Plane · Retirement requires owner sign-off if owner exists
OWNER CONFIRMATION REQUESTED
Liveness signals (5 sources)
0.99
Zero dependencies confirmed
0.97
No recent activity (24 months)
0.95
Decision: Retire with owner courtesy notice
High confidence, but policy requires 7-day notice to owner
97%
4
Communicate — Notice with grace period
7-day window to object before auto-retirement
NOTICE SENT
To Legacy Apps Team · From Governance Agent
EMAIL · 7-DAY NOTICE
Subject: Notice — LEGACY-APP-SVR-19 will be retired from CMDB in 7 days
Hi team,

Our CMDB cleanup agent has determined that LEGACY-APP-SVR-19 (Windows Server 2012, IP 10.8.14.205) appears to have been physically decommissioned but its CMDB record was never updated.

What we checked:
• Host has not responded to ping, port scan, or SCCM in 814 days
• VM is no longer present in vCenter
• DNS record was removed
• Zero application traffic, incidents, or change activity in 24 months
• No backup jobs since Q1 2024

What will happen: Unless you object within 7 days, the CMDB record will be marked "Decommissioned (inferred)" and removed from active monitoring & patching compliance scope.

Why this matters: Retiring this record will improve your team's patch compliance score by 2.4% and recover 1 monitoring license.
api-gateway-prod-03
Class
EC2 instance
Drift detected
7 attributes
Change ticket
None
UNAUTHORIZED DRIFT
1Compare State
→
2Classify Drift
→
3Check Authorization
→
4Reason
→
5Decide
→
6Communicate
1
Compare — What's different between CMDB and reality?
Governance Agent · CMDB record vs live cloud API state
7 ATTRIBUTES DIFFER
≠
Instance type
CMDB: t3.large · AWS: m5.2xlarge
Upsized 4x · ~$280/mo cost increase
DRIFT
≠
Security group
CMDB: sg-prod-api · AWS: sg-dev-open
⚠ Dev SG attached to prod instance
DRIFT
≠
Public IP
CMDB: none · AWS: 54.x.x.x assigned
⚠ Public IP exposed
DRIFT
≠
OS version
CMDB: Ubuntu 20.04 · AWS: Ubuntu 22.04
In-place OS upgrade · No change ticket
DRIFT
≠
Tags
environment tag changed
CMDB: prod · AWS: staging
DRIFT
≠
EBS volumes
attached storage
2 new 500GB volumes attached
DRIFT
≠
IAM role
instance profile
Role changed to AdminAccess (broad)
DRIFT
2
Check authorization — Is there a change ticket?
Cross-reference with ITSM change records
NO MATCHING CHANGE
✗
ServiceNow change records
CHG WHERE ci=api-gw-prod-03 LAST 30d
0 approved changes found
UNAUTHORIZED
ⓘ
CloudTrail audit log
who made the changes
Actor: iam-user:dev-intern
Time: 2026-05-16 14:23 UTC
EVIDENCE
!
SOC2 control SC-7
prod changes require CAB approval
Control violation
COMPLIANCE
🧠 AGENT REASONING
This is a high-severity drift, not a benign update. A production API gateway was modified by a dev intern's IAM credentials with no change ticket — almost certainly a console mishap (the dev SG, public IP, and AdminAccess role suggest someone was debugging and "borrowed" the wrong instance).

Security risk is real: a production gateway is currently sitting on a permissive dev SG with a public IP and admin role. This isn't a CMDB problem first — it's a security incident that should trigger immediate remediation.

Action: Do not auto-update the CMDB to reflect drift. Instead, alert SecOps, the application owner, and the CISO digest. Hold the CMDB record at its expected state until the drift is investigated and resolved.
3
Decide — How to handle a security-relevant drift
Policy: never accept drift as authoritative when security controls fail
ESCALATED TO SECOPS
!
Security incident raised — CMDB held at known-good state
P2 incident · Owner notified · 24h SLA
WHAT THE AGENT DID NOT DO
Update CMDB to drift state❌ Refused
Auto-revert AWS changes❌ Out of scope
→
WHAT IT DID DO
Raised P2 incident✓ INC-2026-8841
Notified SecOps + owner✓ Slack + email
Logged drift evidence✓ Full forensics
Held CMDB unchanged✓ Awaiting verdict
4
Communicate — Right message, right channel, right urgency
Multi-audience: SecOps (action), owner (awareness), CISO (visibility)
4 NOTIFICATIONS
To SecOps On-Call · From Governance Agent
PAGERDUTY · P2
Incident: Unauthorized production drift on api-gateway-prod-03
Severity: P2 · SLA: 24h
What happened: Production EC2 instance api-gateway-prod-03 was modified by IAM user dev-intern at 2026-05-16 14:23 UTC. No change ticket exists.

Risk indicators:
• Production instance now on dev security group (sg-dev-open) — overly permissive
• Public IP attached (54.x.x.x) — previously private only
• IAM role changed to AdminAccess — privilege escalation

Recommended response:
1. Revert SG, IP, and IAM role to previous values (snapshot at evidence link)
2. Audit dev-intern's other recent actions in CloudTrail
3. Open SOC2 control deviation record

CMDB status: Held at last known-good state. Will update only after authorized change ticket closes.
To API Platform Team (CI owner) · From Governance Agent
SLACK · URGENT
🚨 Heads up — your prod instance api-gateway-prod-03 has drifted.

We detected 7 attributes changed without a change ticket. SecOps has been paged (INC-2026-8841). The change appears to come from a dev intern's IAM credentials — likely a mistake, but it has security implications (public IP + AdminAccess role on production).

Your action: Coordinate with SecOps on rollback. Once resolved, file the retro change ticket so we can sync the CMDB.
To CISO Daily Digest · From Governance Agent
EXECUTIVE BRIEF
Drift summary (today): 142 drifts detected · 138 benign (auto-reconciled) · 3 require change tickets · 1 security-relevant (INC-2026-8841 raised). SOC2 control SC-7 deviation logged.
AGENTIC AI · CMDB DECISION WALKTHROUGH · CHECK → REASON → DECIDE → COMMUNICATE → AUDIT