Why Agents Need Protocols: The Two Boundaries of the Agentic Web

Start with the smallest version of the idea. A language model on its own only predicts text: give it nothing to act on and it will describe sending the email without sending it, narrate running the query without running it, and change nothing in the world. An agent is what you get when you put that model in a loop and let it use tools. The interesting part, and the whole subject of this series, is what happens at the edge where the model stops predicting and starts reaching out to things that are not itself.

Because a model that can reason brilliantly and touch nothing is an expensive autocomplete. The loop only becomes useful when it can check a calendar it was never trained on, write a row to a database it has never seen, or hand a slice of the work to another team’s agent it did not build. And those last two are not the same kind of reach. One goes down, to a tool that does exactly one thing and has no opinions. The other goes across, to a peer that has its own model, its own tools, and its own goals. They feel like one problem (“let the agent talk to things”), and the entire industry’s first instinct was to treat them as one. They are not, and the proof is that we ended up with two protocols, not one.

The agentic web is being built out of two protocols because an agent crosses two fundamentally different boundaries, and the shape of each protocol is dictated by the boundary it crosses, not by the company that shipped it. That is the claim this series pays off. This first part maps the territory: the two boundaries, why each one forces the protocol it gets, and why you cannot collapse them into one. Later parts go to the wire, into the Model Context Protocol and Agent2Agent message by message, with enough working detail to build against either.

The aim across the series is a working guide, not a survey, and it runs from the basics to the advanced edges. It starts here, with what an agent actually is and why it needs to reach out at all. From there each part builds on the last: MCP up close and its primitives, then MCP on the wire with its transports and security model, then A2A and the peer boundary, then the wider interop landscape, and finally where the whole thing is heading. The series releases one part a week, and each new part links back to the ones already out, so the “Part X of N” navigation at the foot of every post always points to what you can read now, never ahead of it. If you are putting an agent into production and trying to decide what it should speak to the outside world, this is the map I wish I had had starting out. I will ground each claim in the specifications themselves, link the primary sources, and mark clearly where I am reasoning past what they actually say.

What makes a model an agent

It is worth being precise about the loop, because everything downstream is built on it. The definition that survived the hype is small: an agent is a model that runs tools in a loop to achieve a goal.¹ The mechanism is just as small. The model is handed a goal and a set of tool definitions, and each turn it emits one of two things: a final answer, or a tool call, which is a structured request naming a tool and supplying arguments that fit that tool’s schema. A runtime executes the call, captures the result, and hands it back to the model as the next thing it reads. Then the model goes again. Think, act, observe, repeat, until it decides it is finished.²

The one decision that matters is the one the model makes every turn: answer, or call a tool. Nothing else in the system makes that choice, and that gate is where an agent’s autonomy lives. Most of the engineering of a serious agent is about bounding what happens at that gate, a subject worth a post of its own, which I will not repeat here. For this series the consequence is simpler and more structural: the loop is inert without tools to call, and the moment you want more than a couple of tools, or any tool you did not write yourself, you need a standard way to describe a tool, list what is available, and invoke it. A standard like that is a protocol, and the rest of this post is about why an agent needs not one of them but two.

The loop is only as good as its reach

The interesting variable in an agent is not how smart the model is. A bigger model in a sealed box is still a sealed box. The interesting variable is surface area: how much of the world the loop can observe and change. Every agent I have found useful earned its keep at the boundary, not in the model. The voice agent I built for phone calls was only worth answering a phone with once it could check real availability and write a real booking; before that it was a very fluent way to waste a caller’s time.

So reach is the product. And reach comes in two shapes that are worth separating before they get tangled. The first is invoking a capability: the agent wants something done that it cannot do itself, like running a SQL query or sending an email, so it calls out to a thing that does only that. The second is collaborating with another actor: the agent wants a whole sub-goal handled by something that is itself an agent, like asking a specialist legal-review agent to vet a contract and report back. The first is a function call. The second is a delegation. Hold that distinction, because everything below hangs on it.

Why integration cost forces a protocol

Before there is a protocol, there is an integration explosion. If you have M agents and N tools and no standard, every agent that wants a tool wires it up by hand, and you are on the hook for M times N bespoke integrations. Add one tool and you integrate it M times. This is not a new problem and it has a well-worn solution: put a protocol in the middle and M times N collapses to M plus N. Each agent learns the protocol once, each tool speaks the protocol once, and they meet without knowing anything specific about each other.

This is the oldest move in plumbing. USB did it for peripherals against ports. The Language Server Protocol did it for code editors against languages: before LSP, every editor needed a custom plugin for every language, an N-by-M grid of half-maintained integrations, and after LSP each editor and each language implemented one protocol and the grid collapsed. MCP took the same move from there: its own specification says it “takes some inspiration from the Language Server Protocol,” applying the idea to AI tools instead of editors.³ The economic case really is that simple, and it is why the 2024 to 2026 stretch produced protocols rather than just more products. When integration cost gets large enough, a standard is not idealism, it is arithmetic.

Two boundaries, not one

Here is the whole geometry of the series in one picture. An agent reaches in two directions, and each direction is a different boundary with a different protocol.

The thing to notice is that MCP edges point down and the A2A edge points across, and the peer on the far side of the A2A hop has its own downward MCP edges. That layering is the canonical shape of an agentic system: A2A between agents, MCP from each agent to its own tools.⁴ I will keep using that vocabulary, down and across, for the rest of the series, because it is the cleanest way to remember which protocol is doing what.

Why do the two boundaries feel like one? Because from inside the loop they look identical: the model emits something, waits, and gets something back. The difference is entirely on the other side of the line, and it comes down to two properties of the counterparty: how intelligent it is, and how opaque it is. A tool is neither. A peer is both. Those two properties, worked through, are what force two different protocols, and the next two sections take them one at a time.

The tool boundary is asymmetric

A tool is dumb and transparent on purpose. It does one thing, it has no goals of its own, and you can read its schema and know exactly what it will do with what you send it. All of the intelligence in the interaction lives on the agent’s side; the tool just holds a capability and waits to be asked. That asymmetry is the defining feature of the down boundary, and it dictates everything about the protocol that crosses it.

What does such a boundary actually need? Three things, which are exactly MCP’s three server-side primitives.⁵ It needs a way for the tool to describe its capabilities so the model can choose among them, which MCP calls tools (each with a name, a description, and a JSON Schema for its arguments). It needs a way to expose context data the model should be able to read, which MCP calls resources. And it needs a way to ship reusable templates for common interactions, which MCP calls prompts. The model discovers what is available with a tools/list call, then invokes one with tools/call and typed arguments, and gets a structured result back. Call and return, over a stateful JSON-RPC session.

There is a wrinkle worth flagging now and unpacking in part two: the down boundary is not purely one-directional. MCP also lets the tool side reach back, asking the client to run a model completion on its behalf (sampling) or to collect input from the user (elicitation).⁵ But these are the exceptions that prove the rule. They exist precisely because the tool is too dumb to have its own model or its own user, so it borrows the client’s. The asymmetry is the design: a dumb, transparent counterparty gets a call-and-return protocol with capability discovery, and the protocol’s shape is just the boundary’s shape made concrete.

The peer boundary is symmetric

Now put another agent on the far side. It has its own model, its own tools, its own goals, and one more property that changes everything: it is opaque. You cannot see its internals, it will not show you its prompt or its memory or its toolset, and it should not have to. “Opaque” is the load-bearing word in A2A’s own one-line definition of itself, a protocol for “communication and interoperability between opaque agentic applications.”⁶ The whole point is to let agents collaborate without exposing how they work.

A boundary like that needs something other than “call this function.” It needs delegation. You do not invoke a peer, you hand it a task and let it work. So the peer boundary needs a way to discover who an agent is and what it can do before you trust it with anything, which A2A calls the Agent Card, a JSON document served at a well-known URL.⁶ It needs a task with a real lifecycle, because a peer’s work is a process, not a function: it can be submitted, then working, then pause at input-required to ask you something, then land on completed, failed, canceled, or rejected.⁷ It needs to stream progress while the work runs, and to hand back artifacts when it is done. Because both sides are intelligent and opaque, the protocol is task-oriented and stateful across the whole life of the task, not a quick call and return. A smart, opaque counterparty gets a delegation protocol with a task machine, for the same reason the dumb one got a function call: shape follows boundary.

Why one protocol cannot do both jobs

The tempting unification is to say it is all just agents calling things, so pick one protocol and tunnel everything through it. And to be fair, you can. You can wrap a peer agent so it looks like a single MCP tool to its caller, and people do; a peer often is exposed to its client as just another capability. You can also model a tool call as a degenerate A2A task. The grain of truth is real: the two boundaries are adjacent, and the wire formats overlap enough that either can impersonate the other for a while.

But the fit fails in exactly the direction that matters. Wrap a peer as an MCP tool and the moment its work takes minutes, or needs to come back mid-flight to ask a question, or needs to stream partial results, you have nowhere to put any of that, because you flattened a collaborator with a task lifecycle into a synchronous function call. Go the other way and model a five-millisecond database read as a stateful A2A task, with discovery and a webhook for completion, and you have wrapped a function call in a small distributed-systems project for no benefit. This is why A2A’s own maintainers describe the two protocols as complementary rather than competing, with the memorable split that A2A is about agents partnering on tasks while MCP is about agents using capabilities.⁴ A protocol is a frozen set of assumptions about the counterparty. A tool and a peer are different enough that they need two different sets, and trying to serialize one assumption-set through the other’s wire format quietly discards the assumptions you actually needed.

The map is also a power struggle

So much for the engineering. The reason a protocol series is worth writing now, in mid-2026, is that the wire formats are stabilizing while the politics around them are not, and the politics will decide which of these you have to support in two years.

The current state, briefly. MCP came from Anthropic in November 2024 and spread fast: OpenAI adopted it in March 2025, Google followed, and in December 2025 it landed under the Linux Foundation’s new Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI.⁸⁹ A2A came from Google in April 2025, was donated to the Linux Foundation in June 2025, and reached its v1.0 spec only in March 2026, after a full year on 0.x versions; by its first anniversary it claimed more than 150 organizations and a steering committee spanning AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow.¹⁰ Around the edges, IBM’s competing Agent Communication Protocol was merged into A2A in August 2025 rather than competing with it, and Cisco’s AGNTCY joined the Linux Foundation as agent infrastructure.¹¹

Read the cast lists and you see the tension. Google anchors A2A; Anthropic and OpenAI anchor the Agentic AI Foundation that now stewards MCP; Microsoft, AWS, and Google show up almost everywhere. Some analysts frame this as two rival blueprints for who owns the agent stack, and there is a land-grab quality to it that I think is real. But I would put it softer than “war”: both protocols sit under the same foundation umbrella, both keep getting adopted, and the boundaries they serve are genuinely different, which is a strong reason for them to coexist rather than one swallowing the other. That is my read, not a reported fact, and it is exactly the kind of thing this series will keep testing against what the specs actually say. The next part goes down, into MCP, and takes the tool boundary apart primitive by primitive.

Takeaways

If I had to compress the map into a few things to carry into the rest of the series:

1. Reach, not intelligence, is the product. The engineering payoff of an agent lives at the boundary, in what it can safely touch, which makes it a protocol problem far more than a model problem. A smarter model wired to nothing is still wired to nothing.
2. A protocol’s shape is dictated by its counterparty. MCP is call-and-return because a tool is dumb and transparent; A2A is task-and-lifecycle because a peer is intelligent and opaque. When you read either spec, read it as a description of the thing on the other side of the line.
3. Down and across are different boundaries, so do not tunnel one through the other by accident. You can wrap a peer as a tool or a tool as a task, but you silently lose the streaming, the task lifecycle, or the opacity that the other protocol existed to provide.
4. The wire is settling faster than the governance. Bet on the boundaries, which are permanent, more than on any one company or foundation winning the stack, which is not yet decided.