You all know I don’t have the infrastructure and network automation chops that you have. In my world (Sales, GTM, and Operations) I’m managing pipelines of a different kind.
But even I can see your AI agent problem.
Over the past six months, I’ve sat in enough rooms with enough technical teams to know that the same scenario is playing out everywhere: managers are handed an AI mandate, they pressure their teams to “start using agents,” engineers roll their eyes.
It’s not that they don’t get that AI is the future. It’s that they know agents need accurate data, clear instructions, and business context. And right now, that data is all over the place.
I’ve seen the same thing happen on the GTM side. Ask anyone who’s tried to layer AI on top of a CRM with incomplete records, no ownership, fields used differently by every rep. It didn’t accelerate anything, it just automated the mess. The faster you put garbage in, the faster you get garbage out.
Network infrastructure is no different. Except the stakes are considerably higher than a botched outbound sequence.
Here are six lessons we’ve learned from our customers that’ll help you make that case – signs that your data model isn’t AI-ready and why you need to fix it before you ever attempt to deploy an agent.
1. Adding a Field Takes Weeks (Even Months)
Say you need to track a new device type, a new relationship between a circuit and a service, a piece of metadata your team has been managing in a spreadsheet. Should be easy, right?
Not if you don’t own the source of truth. If that’s the case, you need to:
- Open a ticket
- Fill in all the required fields
- Add plenty of justification to avoid a pointless meeting
- Wait for the other team to review it
- Wait for the other team to prioritize it
- Wait for it to finally show up in the schema
The whole process could take weeks.
The team managing TikTok’s global edge network lived this exact scenario. Their incumbent instance had been forked by another team, rewritten, and turned into something they no longer controlled – and it made even the smallest requests a time sink.
Per Mufaddal Presswala, Network Engineer at TikTok:
“It was taking 6 months to go from raising a request to a shipped schema change. For something as simple as adding a new field. It was very, very slow for us.”
This is an annoying problem for any network engineer, but it’s also a problem for agents.
They need a complete, current picture of your infrastructure to make good decisions. With a data model six months behind your network, you can’t automate confidently, let alone hand them the keys.
2. You’re Making Some Very Hacky Workarounds
One network automation team we spoke to at a global financial technology and payment processing company was running their service catalog on ServiceNow.
It had no version control and took 2-3 minutes for a screen to load. Naturally, engineers did what engineers do, and hacked their way around the wait, with a custom UI and Git bolted on top, Python scripts connecting everything together.
Sure, it was faster. But the toolchain was so complex that only senior developers could understand it. And it meant YAML files were so unwieldy that nobody outside the core team could touch them without breaking something.
For agents, a Frankenstack setup is a non-starter. They need a clean, consistent connection to your data. Schema changes should be written, reviewed by a human, then pushed to a shared data model in a matter of minutes.
3. Automations Break Whenever Your Schema Changes
At companies with big network teams, it’s not uncommon for their data model and their templates to be maintained by two different teams in two different places. That can work if those systems talk to each other, but more often than not, they don’t.
The ByteDance (TikTok) team saw this firsthand.
“We had Ansible playbooks pulling from our source of truth. Whenever the schema changed on the database side (which it did a lot), our templates broke immediately,” Mufaddal explains.
“The worst part is that we wouldn’t figure it out until much later in the cycle, and we would have to go back and update the templates, which was hard to fix because there was no relationship between the two things.”
With human-driven automation, someone runs a playbook, it fails, someone sees the error and fixes it. The feedback loop may be slow, but it exists.
An agent may not know when to stop. And so it’ll keep reconfiguring devices, provisioning circuits, updating BGP sessions, whatever it’s been set up to do, based on the wrong data model.
By the time anyone notices, it might’ve made the same mistake dozens of times.
4. Parts of Your Network Don’t Exist in Your Source of Truth
When your data model is too rigid to represent something, you don’t stop tracking it, you just track it elsewhere.
One large telco team we spoke to had data in its source of truth, but also in ConnectMaster, and also in a commercial inventory, creating confusion and errors. Their schema couldn’t even handle non-consecutive VLAN selections, a basic requirement for their operations.
Anything that didn’t fit had to be addressed manually.
Eurofiber, which offers infrastructure-as-a-service, virtualization, and data center solutions across France, was running its entire device inventory (switches, routers, firewalls, load balancers) off a local flat file.
They were updating hostnames, device types, IP addresses, all by hand. Cédric Grard, Senior Cloud Architect at Eurofiber, laments:
“Whenever we had new equipment, we had to go through all Oxidize again to update the inventory. And then do that all over again if we needed to remove any equipment.”
Unlike a human who might notice something looks off, an agent won’t question what it can’t see. It’ll make decisions without that context, pushing a config to a device that no longer exists or taking down a service it didn’t know anything depended on.
5. You Can’t Model a New Site Ahead of Time
Deploying a new site usually involves:
- Spreadsheets for day-zero config
- Manual coordination between teams
- A data model update (hopefully)
When you’re only doing one site at a time, that workload is manageable. When you’re managing ten, fifty, five-hundred, it’s easy for mistakes to pile up and for your source of truth to get out of date real fast.
ByteDance (TikTok), for example, used to rely on spreadsheets for day-zero configuration across 200 global PoPs. Every new site was a manual exercise and the data model was always playing catch up.
For agents, there can be no winging it. They need an intended state to work from before a single config gets pushed.
6. There’s No Business Context Behind Your Infrastructure
Who owns this service? What does this circuit cost and when does it renew? Why was this configured this way? What team built it and what does it support?
That information lives in a ticket, an email, a Slack thread, someone’s memory. We’ve heard a version of this from a lot of teams. This came from an infrastructure lead at a global hedge fund:
“There was no way for us to handle telecom, maintenance, license contracts with technical infrastructure. We only had a technical implementation without metadata about ownership, purpose, business reasoning.”
Without that context, things go wrong in ways that are hard to predict.
An agent gets asked to decommission a device, and it does because nothing in the data model says that device is supporting three active customer circuits. Or it provisions a new service on a link that’s already over capacity, because cost and utilization data is in a spreadsheet it doesn’t have access to. Or it makes a change that triggers a compliance violation, because the regulatory context for that piece of infrastructure existed only in someone’s head.
The agent can only make (consequential) decisions based on what it knows. And if your data model is missing the “why” behind your infrastructure, that’s only half the picture.
The Fix
Every sign on this list points to a data model that’s rigid, slow to change, owned by the wrong team, or missing whole parts of the network. It can barely document your infrastructure, let alone power agents.
What you need is a single place that captures what your network should look like and why. One that’s flexible enough to model your infrastructure your way, and structured enough that agents can actually reason from it.
If you want to understand what that looks like in practice, this is a good place to start.
