CMDB Intelligence Engine

The Case Against Visible Features

When I joined FuturePath.AI to lead the TechOps platform, I could have built the thing everyone wanted first: the AI agent that resolves incidents. It demos well. It's easy to explain to a prospect. It would have gotten us into pilots faster.

I built the CMDB Intelligence Engine first instead.

Nobody asked for it. There's no dashboard that shows the user "your CMDB is now trustworthy." There's no moment where an enterprise customer opens a browser tab and sees the product working. It runs underneath everything, invisible, fixing data that was wrong before any agent ever touches it.

This is the story of why that was the right call — and what it took to build something that the market didn't know it needed.

Why AI in IT Operations Keeps Failing

The numbers on enterprise AI in IT operations are grim, and they've been getting grimmer as more deployments reach the post-PoC stage:

• 30% of generative AI projects abandoned after proof of concept (Gartner, 2024)
• 95% of enterprise GenAI pilots fail to deliver measurable P&L impact (MIT)
• 40%+ of agentic AI projects will be cancelled by end of 2027 (Gartner, 2025)
• 64% of IT teams haven't adopted AI at all — with data quality cited as the #1 barrier

The vendors selling these AI solutions have a narrative for why they fail: organizations aren't ready, change management is hard, adoption takes time. That's a convenient narrative if you're a vendor. It's not the real answer.

The real answer: the data is broken, and AI makes broken data move faster.

An AI agent that auto-resolves incidents needs to know which configuration items are affected, what their current state is, how they relate to each other, and which changes happened recently. It gets all of this from the CMDB — the Configuration Management Database that's supposed to be the single source of truth for enterprise IT infrastructure.

Except it isn't.

Only 17% of organizations say their CMDB is fully accurate (Flexera). Less than half of enterprises trust their CMDB data at all. Forrester declared CMDB dead in 2025. And this isn't hyperbole — it's the mathematical consequence of how CMDBs work: periodic discovery cycles that go stale within weeks, CI relationships that are manually maintained and rarely updated, cloud infrastructure that spins up and terminates faster than any discovery scan can track.

When your AI agent runs on a CMDB that's 83% fiction, it produces confident answers to wrong questions. The AI isn't failing. The foundation is failing.

The Three Compounding Blockers

I spent time before building anything mapping the actual failure mode. Not "CMDB inaccuracy" as a catch-all, but the specific, compounding ways bad data cascades through enterprise IT operations.

Blocker 1: The CMDB Doesn't Reflect Reality

The math here is straightforward and damning. Eight of the highest-value ITSM AI features — blast radius analysis, change risk assessment, incident auto-routing, dependency mapping, alert correlation, asset lifecycle management, automated remediation, and post-incident review — all require accurate CMDB data. If only 17% of CMDBs are accurate, 83% of enterprises are running these features on data that actively misleads the AI.

The underlying cause: CMDBs were designed for quarterly discovery cycles in stable on-prem environments. Modern infrastructure — hybrid cloud, containerized workloads, microservices — changes continuously. The CMDB was built for a world that no longer exists.

The cost isn't just wrong AI outputs. Inaccurate CMDB costs enterprises $50K–$300K annually in maintenance and renewal fees alone (IP Fabric) — licensing for assets that no longer exist, missing renewals for assets that aren't tracked, manual investigation time that compounds with every new incident.

Blocker 2: Alert Noise Has Become Structurally Unmanageable

SOC teams are fielding 4,484 alerts per day on average, with 67% ignored (DataBahn). Enterprises run 45–83 separate security and monitoring tools. 500+ cloud security alerts per day, with 20–40% false positives.

The problem isn't that there are too many alerts — it's that AI correlation agents trying to reduce alert noise are ingesting that noise as signal. If your entity resolution is wrong (the same server appears as three different identities across your monitoring tools), then alert correlation produces confident groupings of events that aren't actually related. Garbage in, confident garbage out.

Blocker 3: Nobody Has Solved Entity Resolution

The average enterprise runs 15–20 monitoring tools, each with its own alert format (Syslog, CEF, LEEF, JSON), its own naming conventions, its own severity scale. The same physical server might be called prod-app-01.internal in CMDB, 10.0.1.50 in SolarWinds, and APP01 in the ticketing system.

Every AI tool that skips entity resolution produces outputs that look impressive in a demo environment — where the data is clean, the naming is consistent, the entity graph is already solved. In production enterprise environments, they collapse within weeks.

The compounding effect is the point. Fix any one of these blockers and the other two still break the output. Isolated AI features fail not because the AI is poor — but because they're standing on eight broken foundations simultaneously.

The Product I Designed

Before any CoResolve AI product could work reliably, the data layer had to be fixed. I designed the CMDB Intelligence Engine as the prerequisite: a 10-engine system that continuously cross-references CMDB data against three sources of truth more reliable than the CMDB itself.

The three authoritative sources:

1. Live traffic patterns — NetFlow, SNMP, packet-level data. What's actually communicating with what, right now.
2. Monitoring tool telemetry — SolarWinds, DNAC, Datadog, Zabbix. What the tools watching your infrastructure actually see.
3. Incident correlation patterns — When the same two CIs appear together in incident tickets repeatedly over months, that's evidence of a dependency no one documented.

The core product vision: take a Fortune 100 company with 50,000+ CIs across hybrid infrastructure, connect to every data source that knows what's actually happening, and systematically detect every discrepancy the CMDB is hiding — then surface them for human-approved remediation.

Ten Engines, One Architecture

Every architectural decision in the CMDB Intelligence Engine was made to solve a specific failure mode I'd identified. This isn't ten features — it's ten interdependent systems where the sequence matters.

Engine 0 — Entity Resolution: "One Asset, One Identity"

This runs first, before anything else, and it's the most important thing in the entire system.

If the same server appears as three different identities across your data sources, every downstream engine produces false positives. "Server X missing from CMDB" fires — but Server X exists, it's just called something different everywhere else. False positives in week one destroy trust in the product permanently. Trust death equals product death.

Engine 0 ingests every identifier an asset might have: hostname, FQDN, IP address, MAC address, serial number, CI ID, cloud instance ID, container ID. It builds a master identity graph using fuzzy matching for hostname variants and hard anchors on IP and MAC addresses (which don't change when hostnames do). Cloud instances get tracked by instance ID through IP address changes. Kubernetes workloads are tracked at service level — not individual pods, which are ephemeral by design.

This engine runs silently before any finding is generated. It's the reason the other nine engines can be trusted.

Engine 1 — Discovery: "What Actually Exists"

The Reality Inventory — a continuously updated snapshot of everything that's actually alive in the environment. Not what the CMDB says exists. What actually responds to monitoring polls, appears in network controllers, is running in cloud consoles, is mentioned in recent tickets, resolves in DNS.

Sources: SolarWinds polling, Cisco DNAC, AWS/Azure/GCP APIs, ServiceNow ticket references, DNS/IPAM, VMware vCenter, Kubernetes cluster APIs.

Every asset in the Reality Inventory carries a "last seen" timestamp and a source count — how many independent systems confirmed its existence. An asset seen by six sources at high confidence is very different from an asset seen by one source three months ago.

Engine 2 — Relationship Mapper: "What Talks to What"

The CMDB records relationships as they were documented at discovery time. Engine 2 builds the Reality Graph — relationships inferred from observed behavior. These are more current and more accurate because they're derived from what's actually happening, not what was documented.

Sources: NetFlow and traffic analysis (actual packet flows between assets), incident correlation patterns (CIs that co-appear in incidents repeatedly), change correlation (when a change on Asset A is consistently followed by incidents on Asset B, that's a dependency), load balancer and F5 configurations (pool definitions reveal which backends serve which applications), and APM tracing (Dynatrace or AppDynamics trace actual request paths through the application stack).

Every relationship in the Reality Graph carries a confidence score and a list of evidence sources. This traceability is essential — when a relationship is flagged as wrong, an administrator needs to see exactly what evidence led to that conclusion.

Engine 3 — Gap Analyzer: "Where the CMDB Is Lying"

Engine 3 does the diff. It compares the Reality Inventory and Reality Graph against what the CMDB currently says, and produces four types of findings:

Stale CIs (Ghost Assets) — Configuration items in the CMDB that no monitoring tool, no cloud console, no DNS record, no recent ticket has seen in 90+ days. The infrastructure is gone. The CI remains. Licenses are being paid. Change windows are being scheduled. Blast radius calculations are including assets that don't exist.

Wrong Relationships — The CMDB says Application A depends on Database B. NetFlow shows Application A's traffic consistently flowing to Database C. The documented dependency is wrong. Incident triage for Application A failures is pointing engineers in the wrong direction.

Missing Relationships — No CMDB record of any relationship between Server X and Server Y. But NetFlow shows consistent, high-volume traffic between them. A dependency exists that was never documented — and every blast radius calculation for both assets is missing a critical connection.

Shadow Assets — Live infrastructure with no CMDB record at all. Developers provisioned a cloud instance directly. A network engineer stood up a device that never went through the CMDB onboarding process. These are risk vectors: unknown assets running in production with no lifecycle management, no change governance, no security review.

Engine 4 — Confidence Scorer

Not all findings are equally certain. Engine 4 applies a multi-source evidence model:

• 1 source confirming: 60–70% confidence — flag for investigation, low priority
• 2 sources confirming: 75–85% — recommend human review
• 3+ sources confirming: 90–99% — recommend batch remediation

The confidence threshold determines the remediation path. High-confidence findings (a CI not seen by six independent tools in 90 days) go into the auto-approve queue. Medium-confidence findings (a relationship discrepancy detected in NetFlow but not confirmed by APM) go to a review queue. Low-confidence findings are flagged for investigation without recommendation.

This was one of the more important product decisions: don't present all findings with equal urgency. Alert fatigue in monitoring tools taught us that when everything is equally important, nothing is.

Engine 5 — Remediation Workflow

The daily health report is the product's primary user interface, and designing it correctly was largely a political problem.

More on that later. The mechanics: a health score (overall CMDB accuracy percentage, trending up or down), a count of new findings by type, a remediation queue organized into three buckets (auto-approve at 95%+ confidence, review at 75–94%, flag at 60–74%), and a trend line showing improvement over time.

The "Day 1 Experience" design constraint: a customer connects their first data source and the engine runs overnight. The next morning, they see a complete audit with a health score. No waiting weeks for the system to "learn." Immediate, specific, actionable output from day one.

Engine 6 — Ephemeral Infrastructure Adapter

Modern infrastructure broke the traditional CMDB model because cloud and container workloads are intentionally transient. A Kubernetes pod that lives for 40 seconds isn't a CI — it's a runtime instance of a service. An auto-scaling group that expands from 3 to 47 instances during peak load isn't 47 new CIs — it's one logical unit executing at scale.

Engine 6 classifies infrastructure as persistent (full CMDB lifecycle applies) or ephemeral (tracked at service/template level). Auto-scaling groups are tracked as their launch template, not their current instance count. Kubernetes workloads are tracked at service level — the service persists; the pods don't.

Without this engine, every container orchestration environment produces thousands of false "missing from CMDB" findings daily — and the product becomes noise.

Engine 7 — Drift Prevention Engine

Engines 0–6 fix the current state. Engine 7 prevents it from breaking again.

Real-time monitoring hooks watch for: new assets appearing in any data source that don't have a CMDB record (immediate shadow asset alert), CIs absent from all monitoring for 7+ consecutive days (flag for decommission review), significant traffic pattern shifts that suggest a relationship has changed (flag for relationship update), and change records that close in ServiceNow without any corresponding update to CMDB attributes (the most common source of drift).

The last one is where most CMDB decay actually happens: engineers execute changes correctly, close the ticket correctly, and forget to update the CMDB record. Engine 7 catches this systematically rather than waiting for the next discovery cycle.

Engine 8 — Evidence Engine: "Show the Receipts"

Enterprise IT administrators don't trust findings they can't verify. And they shouldn't — a system that says "this CI is stale" with no evidence is asking for blind trust, which is exactly what breaks when the first false positive appears.

Every finding generated by the CMDB Intelligence Engine is backed by auditable, timestamped evidence. A stale CI finding shows: which six tools were checked, the last confirmed date from each tool, links to the relevant dashboard records, and the last ticket where this CI was referenced. A wrong relationship finding shows: NetFlow packet data, F5 configuration entries, incident correlation timelines, all with source links.

Engine 8 also closes the feedback loop: when an administrator marks a finding as incorrect (this is a DR server, intentionally dormant — not a stale CI), that rejection teaches the system. The finding type is suppressed for that asset. The environment learning model updates. False positive rates decline over time.

Engine 9 — Environment Learning Engine

The most important engine for product trust, and the one that required the most restraint to build.

Every enterprise environment has quirks. Naming conventions that don't follow standards. DR servers that intentionally appear dormant. Test environments with legitimate stale CIs. IP address ranges that overlap in ways that confuse entity resolution. If you run any of the other eight engines against a new environment without understanding these quirks first, week one produces findings that are technically correct but contextually wrong — and technically correct findings that seem wrong are the fastest way to lose a customer.

Engine 9 implements a 1–2 week observation period before generating any findings for a new environment. During this period it asks the customer a focused set of questions: which asset categories are intentionally transient, which naming conventions apply to which environments, which monitoring gaps exist by design, which systems have known data quality issues that pre-date the product. It builds a customer-specific model that all other engines query before generating findings.

The cost is a slower "Day 1." The benefit is that day-one findings have extremely low false positive rates — which makes trust possible.

The Political Problem I Had to Solve

None of the engineering above matters if the product destroys the relationship with the person who owns the CMDB.

Think about the situation. A CMDB administrator has maintained this system for 5–8 years. It's their domain. It represents years of work — discovery jobs configured, CI relationships documented, lifecycle processes built. Then our product runs overnight and surfaces a health score of 41%.

The technically accurate framing: "Your CMDB is 41% accurate." The politically catastrophic framing: you just told someone their five years of work is mostly wrong, and you did it in front of their manager.

I designed the Day 1 report to open with: "340 infrastructure changes detected in the last 90 days not reflected in your CMDB."

Not a health score. Not an accuracy percentage. Infrastructure changes — things that happened to the environment that the CMDB hasn't caught up to yet. The framing shifts ownership of the problem from the CMDB admin (who maintained the system correctly given the tools available) to the infrastructure itself (which changed faster than manual processes could track).

This isn't spin. It's accurate. CMDB decay isn't usually caused by negligent administration — it's caused by infrastructure that changes faster than discovery cycles can keep up with. The reframe is true, and it's the reframe that makes remediation possible instead of triggering defensive politics.

The Integration Timeline Problem

The CMDB Intelligence Engine needs access to 6+ enterprise systems to reach full accuracy: monitoring tools, network controllers, cloud consoles, DNS/IPAM, virtualization platforms, and the CMDB itself. Each of those systems is owned by a different team. Each requires its own security review, its own API credentials, its own access approval process.

Full integration takes 3–6 months. If the product only works at full integration, you lose 3–6 months where the customer sees nothing and has no reason to stay engaged.

I designed the architecture to work with partial data from day one — and to be transparent about what partial data means for confidence scores.

With ServiceNow alone, the engine can detect: stale CIs via ticket correlation (CIs mentioned in tickets years ago but never recently), orphaned CIs (assets with no recent change activity or incident references), and duplicate CIs (same asset registered twice with different identifiers).

Confidence scores adjust automatically based on available sources. With ServiceNow only: maximum confidence of 70%. Add SolarWinds: 85%. Add NetFlow: 95%. The customer sees findings immediately, understands exactly why confidence is lower, and has a concrete roadmap for what connecting each additional source will unlock.

This turned an integration timeline that could kill momentum into a value delivery roadmap that builds it.

Competitive Positioning

The market landscape for data quality in IT operations looks superficially crowded but has a specific gap that no existing product addresses.

ServiceNow Discovery does agent-based and agentless discovery well. It finds what exists. It doesn't validate whether what it found is still true, whether the relationships it documented still match observed behavior, or whether the environment has drifted since the last discovery cycle. CMDB IE doesn't compete with Discovery — it consumes Discovery's output as one input among many and validates it against live reality.

AIOps platforms (BigPanda, Moogsoft, PagerDuty) correlate alerts intelligently. They reduce noise at the alerting layer. They don't fix the underlying CMDB data quality issues that make alert correlation less reliable than it should be. They're building a smarter faucet; we're fixing the water supply.

Virtual agents (Moveworks, Aisera) deflect tickets through natural language interfaces. They work for known, well-documented issue types. They fail on anything requiring cross-system context — which requires accurate CMDB data they're not fixing.

The gap nobody fills: auto-discovering CMDB relationships from actual traffic patterns, with evidence-backed confidence scoring and human-in-the-loop remediation. That's what CMDB Intelligence Engine does, and as of this writing, no other product in the market does it end to end.

Why This Had to Be Built Before Everything Else

Every AI agent in the CoResolve suite — every automation that resolves incidents, every chat agent that answers "what's the blast radius of this failure?", every structured agent that generates post-incident reports — pulls from ServiceNow and the CMDB via MCP tool calls.

The data quality problem cascades precisely and predictably:

• A wrong CI relationship means an agent identifies the wrong affected systems.
• A stale CI means the blast radius calculation is off.
• A missing dependency means the root cause investigation points in the wrong direction.
• A shadow asset means a change is executed without understanding what depends on it.

The AI is not the problem. Confident AI on bad data is the problem. And confident AI on bad data in enterprise IT operations doesn't just produce wrong answers in a report — it executes wrong remediation actions on production systems.

I built the CMDB Intelligence Engine before any CoResolve product because it's the trust layer that makes autonomous IT operations possible, not just impressive in a demo. FuturePath's unique positioning is the only platform in the market that fixes the data and runs AI on top of it. Without CMDB IE, that positioning doesn't exist — we're just another AIOps platform running confident agents on unvalidated infrastructure data.

What This Taught Me

The invisible product is sometimes the most important product.

Every product instinct says: build what users can see and feel. Build what demos well. Build what procurement can point to in a slide. CMDB IE doesn't demo well. You can't show a prospect the absence of bad data the way you can show them an agent resolving an incident. Building it first anyway — and defending that sequencing internally — required being certain about the thesis: AI quality is bounded by data quality, always.

Product design is political design.

The most important decision in the CMDB IE roadmap wasn't an architecture decision — it was the Day 1 report framing. "340 infrastructure changes detected" versus "41% accuracy score." Same data, completely different adoption trajectories. Product design that ignores organizational politics produces technically correct products that nobody uses.

Start narrow, build trust, unlock depth.

The tiered onboarding model — full value from ServiceNow alone, incrementally more accuracy as each source connects — was a product principle before it was an architecture decision. Enterprises don't give you full access on day one. Design for that reality, or you'll spend three months waiting for credentials while your champion loses internal momentum.

The prerequisite is the moat.

Every AIOps company has agents. Nobody has a systematically clean data foundation for those agents to run on. CMDB Intelligence Engine doesn't just improve the CoResolve suite — it makes FuturePath's AI qualitatively different from alternatives. The moat isn't the AI. The moat is the infrastructure underneath the AI that makes the AI trustworthy enough to automate at scale.

Conceived, architected, and owned as part of the TechOps AI Orchestration Platform at FuturePath.AI. The CMDB Intelligence Engine is the data quality foundation for all nine products in the TechOps portfolio.