On this page
This is the opening post of a seven-part series that builds a read-only agentic network operations centre, from the MCP and A2A protocols up to an autonomous, self-healing monitor over a live network. The full list of parts is at the end of this post.
A large language model on its own is a sealed brain. It can reason about a BGP config you paste into the prompt, but it cannot open an SSH session, read a routing table, shut an interface, or hand a job to another agent. For anyone who runs infrastructure, that gap is the entire problem. Nothing an LLM says matters operationally until it can touch the network and coordinate with other pieces of software that also touch the network.
Two protocols close that gap, and they close it along two different axes. This post is a precise introduction to both, plus the third protocol you will hear named in the same breath, so that by the end you know exactly what each one is for, where each came from, and why the rest of this series builds on the two we build on. Every date and version below is cited, because the whole point of the series is that a skeptical reader cannot poke a hole in it.
The isolation problem, stated exactly
An LLM has one interface: text in, text out. To make it useful against real infrastructure you have to solve two integration problems that are genuinely distinct, and conflating them is where a lot of confusion starts.
The first is vertical. How does a single agent reach tools and data: your switches, your kubectl, your firewall API, your ticketing system? This is a client-to-service problem. The agent needs a typed, discoverable way to call functions and read data that live outside itself.
The second is horizontal. How do multiple agents, quite possibly built by different teams on different frameworks, discover each other and delegate work? If you have one agent that understands your VXLAN fabric and another that understands your Kubernetes cluster, something has to let a third agent find them, describe a task, and collect a result. This is a peer-to-peer problem, and it looks nothing like the first one.
Before any standards existed, both problems were solved by hand, once per pair. Every model that wanted to reach every tool needed a bespoke integration, so M models and N tools meant M times N connectors, each with its own auth, schema, and failure modes. That combinatorial cost is exactly what a protocol is supposed to kill.
MCP: the vertical axis, agent to tools
The Model Context Protocol (MCP) is an open standard that Anthropic introduced in November 2024, with the first specification revision dated 2024-11-05. It standardizes the vertical connection: how an agent reaches tools and data.
MCP defines three roles, and keeping them straight matters. The host is the AI application, the thing that talks to the model. The server exposes capabilities, for example a set of tools that operate on your fabric. The client is the connector that lives inside the host and speaks to exactly one server, one client per server. So a host that uses three MCP servers holds three MCP clients, each paired to its server.
The wire format is JSON-RPC 2.0. A server advertises three kinds of primitive. Tools are functions the model can invoke, each with a typed input schema, which is the primitive that matters most for infrastructure work. Resources are data the model can read, addressed by URI. Prompts are reusable templates a server can offer. For this series, tools are the star: a read-only tool that runs a specific show command and returns structured data is the atom we build everything from.
MCP defines two transports today, and this is the kind of detail a careful reader will check, so here it is exactly. The first is stdio: the host launches the server as a subprocess and they exchange JSON-RPC messages over standard input and standard output. This is the natural choice for a local server, and it is what we use later in the series. The second is Streamable HTTP, introduced in spec revision 2025-03-26 and retained in the November 2025 revision, which is JSON-RPC 2.0 over a single HTTP endpoint that supports POST and GET with optional Server-Sent Events for streaming. Streamable HTTP replaced the older HTTP plus SSE transport from the original 2024-11-05 spec, which has been deprecated since 2025-03-26. If you read a tutorial that describes MCP over a separate SSE endpoint, it is describing the deprecated transport.
The payoff is the M plus N shape. Write one MCP server for your fabric, and any MCP-speaking agent can use it without a bespoke integration. That is why adoption moved fast: within a year the primitive was supported well beyond its origin, with OpenAI and Google DeepMind adopting it and Microsoft co-authoring an official C# SDK. MCP became the default way to connect an agent to tools.
A2A: the horizontal axis, agent to agent
MCP connects an agent to its tools. It says nothing about how two agents talk. That is the job of the Agent2Agent protocol (A2A), which Google announced on 9 April 2025 at Google Cloud Next, released under the Apache 2.0 license. On 23 June 2025 Google donated A2A to the Linux Foundation for neutral governance, with founding participation from Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow, and support from more than a hundred companies.
A2A solves discovery and delegation between peers. The cornerstone is the Agent Card, a JSON document that an agent serves at a well-known URL and that advertises the agent's identity, its skills, its endpoint, and how to authenticate. A client that wants to use an agent fetches its card first, reads what the agent can do, and only then sends work. Discovery is built into the protocol rather than bolted on.
Once discovered, agents communicate over JSON-RPC 2.0 carried on HTTP or HTTPS, with Server-Sent Events available for streaming updates. The unit of work is a task, and messages and artifacts flow between the client and the remote agent as the task progresses.
The distinction from MCP is worth stating plainly, because it is the hinge of the whole series. An MCP tool is a typed function that the model invokes directly and whose result the model reads. An A2A agent is an opaque peer that you hand a task to, and it decides how to accomplish it, quite possibly by calling its own MCP tools underneath. MCP is a function call downward. A2A is a delegation sideways. They are not competitors, they are two layers.
ACP, briefly and accurately
You will hear a third name, ACP, the Agent Communication Protocol, and it deserves an honest paragraph rather than a hand-wave. IBM Research launched ACP in March 2025 to power its BeeAI platform. It took a different design stance from A2A, REST-based and async-first, and IBM donated both BeeAI and ACP to the Linux Foundation.
In August 2025, ACP officially merged with A2A under the Linux Foundation. This was not an acquisition or an abandonment, it was a convergence: ACP contributed its simplicity and its open-governance experience, A2A contributed a broader feature set and wide industry backing, and the governance was unified, with ACP's Kate Blair joining the A2A Technical Steering Committee alongside the other founding members. The BeeAI platform, previously powered by ACP, now runs on A2A.
For a builder in 2026 the practical consequence is simple. There is effectively one horizontal standard to target, and it is A2A. We name ACP for completeness and history, and because understanding the convergence tells you why the ecosystem looks the way it does. But building a separate ACP layer today would mean building toward a specification that has already merged into the one we use. So we mention it, and we build on MCP and A2A.
The mental model that anchors this series
Hold two axes in your head. MCP is vertical: it runs downward from an agent to tools and data. A2A is horizontal: it runs across agents. The two compose cleanly, because an A2A agent is free to be an MCP client at the same time.
That composition is the architecture we build. A supervisor agent speaks A2A to a set of specialist agents. Each specialist speaks MCP to the tools of its own domain. When the supervisor delegates "check the fabric" to the fabric specialist, that specialist turns around and calls its read-only MCP tools, which run real commands against real switches, and the structured result flows back up the A2A link. Two protocols, two layers, one clean seam between them.
If you keep only one sentence from this post, keep this one: MCP connects an agent to its tools, A2A connects an agent to other agents, and a serious system uses both at once with a hard boundary between them.
Why a network engineer should care, and what comes next
The prize is concrete. With these two protocols you can build an agent that safely reads a routing table, checks a BGP session, or verifies a VIP is being advertised, and a team of specialists that coordinate across the fabric, the firewalls, and the cluster. The word doing the heavy lifting is safely, and it is where most of the real engineering lives, because an agent that can touch your network is only useful if it cannot break it.
The rest of this series is a build. Next we write a minimal MCP server from scratch and watch the JSON-RPC on the wire, then a minimal A2A agent with a real Agent Card, then the evolution of these protocols in more depth. After that we build the real thing, a read-only network operations centre over a live VXLAN and EVPN fabric, a Palo Alto firewall pair, and a Kubernetes cluster, step by step so you can reproduce it. Then we show what it does, and finally how it is tested, because a monitoring tool you cannot trust is worse than none.
One promise to the skeptical reader, since this series is aimed at people who will check. Every protocol claim is dated and cited. Every build step is runnable on your own gear. Every result is backed by a captured log from a real run. If a statement here cannot survive that standard, it does not belong in the series.
Building an Agentic NOC, the full series:
- Part 1: The three protocols: MCP, A2A, and ACP (you are here)
- Part 2: Build a minimal MCP server
- Part 3: Build a minimal A2A agent
- Part 4: How the protocols evolved and converged
- Part 5: What we built, step by step
- Part 6: What it actually does
- Part 7: Testing, and earning trust
