A few years back, I ran an exercise with a customer that I still think about today. We pulled the application definitions out of their CMDB, every app, the ports it was supposed to use, the systems it was supposed to talk to, and loaded them into their flow analysis platform as custom application definitions. The goal was housekeeping. If the reports were going to be labeled with real application names instead of port numbers, the definitions needed to match what the CMDB said. 

Then we ran a report on everything that didn’t match and filtered the report by the unknown. 

The unknown traffic was enormous. 

Not a rounding error. Not a handful of forgotten services. A serious share of their traffic didn’t fit any definition in their system of record. Applications were using ports nobody had written down. Those apps were talking to sources and destinations that weren’t in the entry. Some definitions described things that hadn’t been true in years. 

Nothing was broken. Everything worked. Their record of what they’d planned to build and what they had actually built had drifted apart over time, and nobody had ever run the comparison that would have shown it. 

What sticks with me is how ordinary that turned out to be. Ask an engineer whether the CMDB is right and watch the engineer’s face. Everybody knows it’s stale. Nobody can tell you which parts. 

It’s almost never negligence, either. People built the record, and nothing updates itself. It’s a document, not a living thing. It captured somebody’s intent on a Tuesday two years ago, and it’s been drifting ever since. 

For a couple of decades, that was a documentation problem. Chronic, annoying, survivable, because the humans reading it knew to discount it. Now we’re wiring agents into those same records. An agent that won’t question or discount anything they read. It has no idea that the CMDB has a reputation. 

So, let’s be precise about what these systems are. Your IPAM, your CMDB, your asset inventory, your diagrams: none of them record your network. They record what you meant your network to be. That’s not an insult. It’s just what they are: a source of intent. 

The network is the only thing that knows what actually happened and what is happening. 

Four things your record claims and your traffic can settle 

Is it alive? Your IPAM says this address is assigned to a host. Fine. Has anything come from it in 90 days? Assignment isn’t existence. An address that’s documented, allocated, and completely silent is either a decommission nobody finished or something sitting patiently. The record can’t tell those apart. Flow can, in an afternoon. 

Is it what it says it is? The record describes what was installed. Behavior describes what it turned into. Those diverge constantly, and nothing in the record notices because a device’s documented identity doesn’t change when its actual role does. 

Is your segmentation real? This one should worry people. Segmentation lives in your documentation as zones that aren’t supposed to talk to each other. Until someone looks at traffic crossing between them, that isolation is a design intention, not a control. The policy can be perfectly correct and the behavior wrong for a year, and the record will never raise its hand because it describes the policy. 

Are your applications behaving? This is the one I saw fail. The CMDB says an application uses three ports. The traffic says it’s also using a fourth, at three in the morning, to a host that isn’t on any diagram. And this is where aggregated data quits because a port number is a claim too. Something listening on 443 is asserting that it’s doing TLS. Only the packets can determine whether that’s true. 

The sequencing nobody wants to hear 

Most conversations about AI in operations right now are about the agent. Which one, how autonomous, how many, where it sits in the workflow. 

I’d flip it. The agent isn’t the hard part anymore. 

The hard part is that we’re about to hand an agent—one that’s fast, tireless, and extremely confident—a stack of documents that every human in the building has known were wrong for years. The agent will act on them without pausing. We spent 20 years building organizational instincts to compensate for bad records. Those instincts don’t transfer to an agent. 

Before you automate the SOC, automate the reconciliation. Not the record. The comparison between the record and observed behavior. 

The useful part is that this skips what usually kills these efforts: getting everyone to agree on a standard first. You don’t need consensus on tagging before you start. You need one comparison that flags where the document and the traffic disagree. Then you argue about the exceptions with evidence instead of opinions. 

What’s actually changed 

Back when we ran the original exercise, the remapping was done manually. We found the drift, and then people sat down and reconciled it by hand, entry by entry. It was worth doing. 

It was also the reason nobody did it twice. The finding was valuable. The labor made it a project, not a practice. That constraint is the one that has genuinely lifted. Running the comparison was never the hard part. Living with the results was.  

Don’t let an agent go to work with out-of-date documentation. Instead, make the agent’s first assignment to validate and sync your documentation with reality. Otherwise, you get an agent working at machine speed off a document nobody has checked since the last audit, finding out which parts were wrong the way we always have … during the incident.