Avatar

As I’ve explored the possibilities of smarter SD-WAN in my previous two articles, I’ve discussed how AI can be integrated into the network and how intelligence can be pushed out to the edge.

However, there’s one area that I didn’t cover in depth, and that is the most important factor in determining whether all of that intelligence at the edge ultimately results in a smarter network or just a noisier one. Let me begin by addressing a common concern regarding whether AI agents are simply superior to MCP. It’s an understandable point to consider; however, these two technologies are fundamentally different.

Comparing an AI agent to MCP is like comparing the brain to the nervous system. The brain thinks; the nervous system transmits signals. Both are essential. And when you view them as separate layers rather than competing technologies, a third layer becomes apparent—the focus of this article.

Three layers, not a contest

In my article about enhancing SD-WAN with MCP, I referred to MCP as “a USB-C port for AI,” a universal interface that allows a model to interact with a manager without needing to speak a different language to each. This representation remains accurate. However, a plug is only useful if someone on the opposite end determines what to do with it.

The agent—the edge device I discussed in Beyond the Controller: Architecting Decentralized Intelligence in SD-WAN—is the one that perceives, decides, acts, and learns. The agent is the brain, and MCP is how that brain touches the network. Straightforward.

The key insight is that a single intelligent device is only half the story. What happens when the other half consists of a multitude, where each of these devices thinks for itself? This is where the third layer comes in—the most recent addition to the model.

Infographic titled "The Autonomous SD-WAN Stack." On the left, three color-coded horizontal layers are stacked vertically:1. Reasoning — The AI Agent (blue, brain icon): "Perceives, decides, acts, learns." 2. Tool Access — MCP (Model Context Protocol) (teal, plug icon): "Agent to vManage / VeloCloud / Silver Peak APIs." 3. Coordination — A2A (Agent2Agent Protocol) (green, loop-arrows icon): "Agent to agent: discovery, delegation, negotiation." On the right, three router icons labeled Edge 1, Edge 2, and Edge 3 are arranged in a triangle and connected by dotted lines. A caption notes: "Dotted lines represent A2A (Agent2Agent) peer-to-peer communication."
The agent decides. MCP lets it reach its tools. A2A lets it reach its peers.

The problem I left unsolved

In my last entry, I described a large retail operation running an autonomous agent in each store, and I said the stores “work in concert,” but I never answered the obvious question: in concert with whom, and how?

To help you understand the situation, let me paint a different picture. Picture a busy sales day. When customer traffic peaks, every store’s agent independently reaches the same smart conclusion: reroute customer overflow to the healthiest route and/or exit. Now imagine hundreds of agents, all making the right local decision, all pushing toward the same exit. The result is a stampede.

A high IQ network of individual agents is not a smart network. If agents can cooperate, they can see one another, request or offer help where it’s needed, and—most importantly—share the work. That’s the sort of capability that any good team possesses, and it is exactly what is missing.

Enter Agent2Agent: A common language for agents

Agent2Agent (A2A) is an emerging, open standard. The first stable release was in 2026, and it is now a Linux Foundation project. It’s gaining traction across the industry, and the idea is simple:

  • MCP enables an agent to communicate with its tools.
  • A2A enables an agent to communicate with other agents.

While MCP handles the agent’s reach across the network, A2A handles its communication with its peers. They are designed to manage different functions and, as such, do not conflict with one another, transforming an array of isolated decision-makers into a system that can collaborate.

With A2A, agents can identify themselves to other agents, indicate capabilities, and request that an agent perform a task, then be informed when the task is complete. It essentially allows agents to negotiate with one another as opposed to the reactive manner in which they currently operate.

The same store, with conversation

Now let’s revisit the surge. Picture the agents interacting, calm and collected. This time, one store’s agent feels the pressure and sends a message to the network: “Can anyone absorb my overflow for a few minutes?”

An agent with a broader view of the network answers—routing traffic to the stores with the most available capacity while protecting the paths reserved for revenue-generating transactions.

The request is still made once and in clear terms: “Keep point-of-sale fast during business hours.” But now it’s achieved through coordination rather than thousands of separate, uncoordinated reactions. No stampede, no scramble—just a network that calmly works out the right response.

A word on trust

Giving agents a voice and autonomy also expands the security challenge: devices that can request actions from other devices open a new potential gap.

Trust guardrails for agent actions that demand the highest trust should include:

  • Agents to carry a verifiable identity within the enterprise security standard.
  • A requirement for agents to identify themselves before a request is acted upon
  • Ensuring critical decisions are still made by a person

The path forward: evolution, not revolution

I will always balance my optimistic vision with a dash of realism. It is unlikely we will suddenly unleash every agent on every site to chat with impunity. Expect a multi-step process.

  1. Initially, agents will only communicate via a central arbiter, or referee, that provides oversight. Think of this as an air traffic controller. This is a lower-risk strategy and will most likely garner broad acceptance.
  2. Let trusted agent peers communicate directly. Referring to a lack of referee situations as “low stakes,” communication tends to go unmonitored unless agents decide to escalate the situation.
  3. Fully exposed fabric. Agents are free to navigate and communicate in all threads of the fabric under watchful, yet transparent, purpose-driven supervision.

Bringing it together

Are AI agents of the future better than the MCP of the past? The answer is more nuanced than that. A truly autonomous SD-WAN is not the victory of one technology over others, but the collaboration of layered technologies. The agent makes the decision, MCP connects it to the network, and A2A lets it communicate with peers. That’s the difference between a grouping of highly intelligent agents and a truly cooperative system.

How are you thinking about coordination in your own autonomous designs? Share your thoughts in the comments.

 


Read next:

Making SD-WAN Smarter with MCP: A Developer’s Guide

Beyond the Controller: Architecting Decentralized Intelligence in SD-WAN

Authors

Het Mehta

Software Engineer

Cisco SD-WAN