Your Vendor’s Agent Doesn’t Know Your Network

—

Agentic AI continues to move into network operations. This is no longer theoretical. Vendors are building agents that can investigate problems, recommend changes, update configurations, and increasingly act across parts of the network. The question is becoming less about whether the agent is capable but whether it understands enough about the operating environment to make the right decision.

At RCR Wireless’s Intelligent RAN Forum in September, Verizon described how it is thinking about that problem. Anil Guntupalli, Verizon’s SVP-Technology and Product Development, talked about moving beyond scripted automation toward AI agents that can reason across network domains, including radio and transport.

What stands out is not the sophistication of the agents, but Verizon’s recognition that the agent alone is not enough. The agent needs context. And the operator has to own it.

A Good Recommendation Can Still Be the Wrong Decision

Verizon gave a useful example: An energy optimization application might detect a degraded cell and determine that traffic should be rerouted. From the application’s point of view, that recommendation may be completely reasonable. But what happens if the transport network supporting the alternate route has no available capacity?

Now the recommendation creates another problem. The application may have understood the radio environment. It did not understand enough of the network. And that distinction matters.

Infrastructure decisions rarely exist inside one system or one domain. A change that looks correct locally can be wrong when you account for the dependencies around it. The same problem exists outside network operations.

Consider a large fiber deployment. An AI system sees that one segment is delayed and recommends moving a crew to another site. The schedule may support that decision. But the permit may still be pending. The pole attachment may not be approved. An easement may be unsigned. A subcontractor’s insurance certificate may have expired. Another field dependency may have changed that morning.

The recommendation is only as good as the operating context behind it.

Said context usually does not live in one place. It lives across schedules, records, approvals, documents, field updates, engineering systems, vendor systems, and years of institutional knowledge. That is the environment the agent actually operates in.

Verizon Is Solving for More Than the Agent

Verizon’s answer is an orchestration layer that sits above the individual agents.

Sub-domain agents can investigate different parts of a problem. Their findings come together. Context can be shared. The final action can then be evaluated against a broader understanding of the network.

Guntupalli called out arbitration as one of the more difficult parts of the model. That makes sense.

Once multiple agents are working across an operating environment, someone has to decide what happens when their conclusions conflict.

A radio agent may recommend one action? Transport capacity may make that action impossible.

A maintenance window may introduce another constraint? Customer commitments may create another.

Security rules, approval requirements, or operational policy may create several more.

The value is not simply having more agents.

The value is being able to determine which action is appropriate once all of those dependencies are considered.

Verizon was also clear about who should own that decision.

As Guntupalli put it, “The intent and outcome is something Verizon wants to own.”

That may be the most important point in the entire conversation.

The Operator Still Owns the Outcome

Agents can perform work. They can investigate, recommend, update, and in some cases make changes automatically.

But authority and accountability are not the same thing. Verizon is comfortable allowing agents to handle defined tasks such as configuration updates or resetting nodes within an established operating remit.

But when a change affects the state of the network or the customer experience, human approval still matters. That is not a limitation of the technology, it is, in my professional opinon, operational governance.

Every infrastructure organization already has rules around who can change what, under which conditions, with whose approval, and with what record of the decision.

AI does not make those requirements disappear. It makes them more important because the speed and volume of decisions can increase dramatically.

Traceability Has to Be Built In

Verizon also raised another issue that deserves more attention: provenance.

If an agent makes a configuration change, the operator needs to know which agent acted, what information it saw, what network state existed at the time, and what context influenced the decision.

That becomes increasingly important as the number of automated actions grows. Verizon’s closed-loop automation platforms processed more than 70 million configuration changes in 2025.

At that scale, “the agent changed it” is not a useful answer. You need to be able to reconstruct what happened.

• Which data did the agent use?
• Which records did it rely on?
• Which permissions applied?
• What dependencies did it see?
• What did it fail to see?
• Who approved the action?
• What changed afterward?

Without that history, the organization does not really have operational control. It has automation.

Those are different things.

Most Operators Will Not Build What Verizon Is Building

Verizon has the resources and technical depth to build its own orchestration and intelligence layers. Most infrastructure organizations will not. These organizations will buy agents, models, applications, and automation from vendors. This means buyers need to look below the agent itself.

Before an AI system is allowed to act inside a live operating environment, leaders should be asking:

1. What systems can the agent see?
2. What happens when two systems disagree?
3. Does it understand the relationships between records, or does it simply retrieve information from them?
4. Does it inherit the permissions and approval paths already used by the organization?
5. Can we see the information behind each recommendation or action?
6. Can we reconstruct why a decision was made?
7. Who has authority to approve a change?
8. What happens to our operating context if we replace the AI vendor?

Your Operating Context Should Not Belong to the Agent Vendor

Every AI vendor will want to understand more about how your operation works. And they have to because the better the context, the better the agent performs.

But there is a difference between allowing a tool to use your operating context and allowing the tool to become the place where that context exists.

Models will change. Agents will change. Vendors will change.

The records, relationships, approvals, dependencies, and decision history that explain how your operation works should remain yours.

That information is becoming part of the operational architecture. If it is fragmented across disconnected systems, AI inherits the fragmentation. If it is connected and governed, the agent can make decisions with a much better understanding of what is actually happening.

This is the layer our team at OneVizion works in every day. Telecom and infrastructure programs already depend on connected records, field activity, approvals, documents, dependencies, and operational history. AI makes the value of that foundation more visible because an agent cannot reason about relationships it cannot see.

That is why I think the next phase of agentic AI will be less about which company has the smartest agent. The agents will continue to improve. The harder problem is making sure they understand the environment they are being asked to change. For telecom leaders, the practical test is straightforward: If an agent cannot see how the network and the work around it are connected, it should not be trusted to change either one.

Source

RCR Wireless, “Where the agentic world kicks in – Verizon draws the line, marks the difference,” James Blackman, October 1, 2026.