Writing
The AI Agent Protocol Stack

The AI Agent Protocol Stack

Four protocols, four different boundaries inside an AI agent, and which ones you probably need.

Pranav Tharoor August 2026 ~6 min read

01Introduction

Four protocols have appeared around AI agents in about eighteen months: MCP, ACP, AHP and A2A. They come from four different companies, and none of the specs reference the other three.

What I find interesting is that they aren't competing. Each one claims a different seam inside the same kind of system, and the seams barely overlap.

Accurate as of August 2026. All four are moving quickly, so check the source specs before you build against any of them.

02The problem with treating "the agent" as one thing

Most agent products are one process. A server renders a chat UI, holds the conversation, calls a model, and runs tool calls in the same request handler. That's a fine way to build the first version, and it's why the internal seams stay invisible until you have to cross one.

Pull them apart and there are five roles doing different jobs.

ONE PROCESS, USUALLY CLIENT renders the chat HOST owns the session RUNTIME does the reasoning TOOLS touches the world ANOTHER AGENT someone else's system
Gold marks a seam. Three of them sit inside one process; the fourth crosses out of it.

None of this is new. It's the same decomposition any distributed system arrives at eventually. What's new is that each of those seams now has a named protocol claiming it.

03MCP, the Model Context Protocol

MCP covers the boundary between a runtime and anything it can read or act on. Anthropic published it in November 2024 and handed governance to the Linux Foundation a year later. It's the closest thing here to a settled standard.

The vocabulary trips people up, so it's worth drawing. The Host is the application itself. It creates one Client per Server, a dedicated connection each.

MCP HOST the AI application CLIENT CLIENT CLIENT MCP FILESYSTEM SERVER DATABASE SERVER SENTRY SERVER
One client per server, never a pool. The host is the thing you'd call "the app".

A server offers three things: tools, which are functions to call; resources, which are read-only context; and prompts, which are reusable templates. Clients ask what's available before invoking anything, which is what lets one host federate many servers into a single tool registry instead of hardcoding them.

"MCP focuses solely on the protocol for context exchange."

That line from the spec places it correctly. It isn't an agent protocol. It says nothing about sessions, about several clients sharing one, or about two agents talking to each other.

04ACP, the Agent Client Protocol

ACP covers one client talking to one agent, and it was designed with code editors in mind. Zed released it in 2025; JetBrains and a long list of agents have picked it up since, which means an editor and an agent no longer need a custom integration per pair.

EDITOR one client ACP PROMPT STREAMED OUTPUT TOOL CALL REQUEST PERMISSION GRANTED AGENT one process
Four message types, one seam, exactly two parties. That last part is the constraint.

Where it stops is where AHP starts. There's only ever one client in ACP's model, so the moment you want several viewers on one session you need something sitting in front of it.

05AHP, the Agent Host Protocol

AHP is the youngest of the four and the least deployed. Microsoft publishes it as an open spec, and its docs are blunt about the job: how a standalone sessions server talks to its clients, so that several of them can hold the same view of one session.

PHONE LAPTOP CI JOB AHP AGENT HOST holds the real state ACP AGENT
The host is the authority. Clients subscribe to it; it speaks ACP onward to the agent.

The design borrows from frontend state management. Each session is a URI-addressed channel, the host keeps an immutable state tree per channel, and changes flow as ordered actions through reducers, so the server and every client compute the same result from the same stream. A client subscribes, gets a snapshot, then receives actions. It isn't a poll loop.

What AHP excludes Its own docs list it: no agent implementation, no model routing, no tool schema or registry, and no agent-to-agent coordination. It's a synchronization layer and nothing else.

06A2A, Agent2Agent

A2A is the only one of the four where both ends are full agents rather than a client, a host or a tool. Google introduced it in 2025 and moved it to the Linux Foundation the same year. It reached v1.0 with more than 150 organizations involved in governance.

It exists separately from MCP because of what sits on the far end. An MCP tool is a known function with a schema: call it, get a typed result. A remote agent is autonomous, might run for minutes or hours, and has reasoning you can't see into. Treating that as a function call throws away the fact that the other side is making its own decisions.

AGENT A its own tools, its own reasoning AGENT B opaque to A, and that's the point AGENT CARD: WHAT I CAN DO TASK: A UNIT OF WORK A2A SUBMITTED WORKING INPUT-REQUIRED DONE
The hatching is the whole argument: neither side can see inside the other, and a task has a lifecycle rather than a return value.

MCP is for reaching into systems you already control. A2A is for handing work to a peer you don't.

07MCP vs ACP vs AHP vs A2A

Side by side, the differences in scope are sharper than any one project's documentation makes them look, because each spec is written as though it's the only protocol in the room.

Four protocols, four boundaries. Not a ranking, a set of different jobs.
Protocol Primary boundary Main purpose Typical participants Maturity What it is not
MCP Agent to tools, data, APIs Standardize how an agent discovers and calls external tools, resources and prompts MCP Host (the app), MCP Client, MCP Server Established. Anthropic, Nov 2024. Linux Foundation since Dec 2025. Not an agent protocol. No sessions, no multi-client sync, no agent-to-agent.
ACP Client (editor) to a single agent One client, one agent: prompts, streaming, tool calls, permissions An editor or IDE, and a coding agent Emerging. Zed, 2025. Stable v1 wire protocol, multi-vendor uptake. Not multi-client aware. Won't coordinate several viewers of one session.
AHP Several clients to one shared session host Keep N clients in sync against one authoritative session Multiple clients, an Agent Host, ACP downstream Experimental. Microsoft, single-vendor origin, least deployed of the four. Not agent implementation, tool schema, model routing or agent-to-agent.
A2A Agent to an independent agent Discover and delegate stateful work to a peer you don't control Two independent runtimes, often different vendors Emerging. Google, 2025. Linux Foundation, v1.0, 150+ organizations. Not tool calling. Not for deterministic, stateless functions.

08How they can fit together

One way to read the four boundaries as a single stack, human at the top, capabilities at the bottom. This is my reading of how the pieces compose, not an official architecture. None of the four specs describe themselves as part of a combined stack.

HUMAN CLIENT AHP AGENT HOST ACP AGENT MCP TOOLS DATA APIS SEPARATELY, IF YOU EVER NEED IT AGENT A A2A AGENT B
A place to locate a boundary you're building against, not a bill of materials.

Most real systems don't instantiate every layer. Plenty of production agents skip AHP because they only ever have one client, and skip A2A because they never delegate outside themselves.

09What this means for builders

If you're building a single-tenant agent, say a React frontend against your own backend with something like LangGraph doing the reasoning, you probably need one of these four and can ignore the other three for a long time.

WHAT YOU ACTUALLY NEED REACT FRONTEND YOUR BACKEND AGENT RUNTIME MCP TOOLS NOT YET ACP you aren't building an editor AHP only one client is ever watching A2A no outside agent to hand work to
Three of the four are solving problems this system doesn't have yet.

MCP is the one that pays for itself early. It turns "write a custom integration per tool" into "write one server per tool, reusable across everything you build afterwards". I'd reach for it as soon as an agent has to touch more than one external system.

The other three are narrower than their names suggest. ACP matters when you're building the editor or the agent but not both. AHP matters once a session genuinely needs watching from more than one place, a phone and a laptop sharing state, or a background job observing. A2A is the easiest to over-apply: an orchestrator calling its own sub-agents in-process doesn't need a wire protocol for it, a function call is fine.

The rule that falls out of that: adopt a protocol when the boundary it covers becomes a real boundary in your deployment, a process, an org or a trust boundary. Not because a reference architecture includes it.

10What is still unclear

None of this is settled, and treating it as settled would be the wrong read. Four things I'd flag:

  • They weren't designed together. Four companies, four timelines, four immediate problems. That they compose as neatly as section 08 suggests is luck more than intent, and nothing keeps them compatible as each one moves.
  • AHP has the least validation. The ideas are borrowed from mature patterns, but as a protocol for agent sessions it's young and single-vendor, and it isn't clear yet whether the ecosystem lands on it, on a rival, or on ad hoc solutions per framework.
  • The overlap is real. A2A's task lifecycle and MCP's extension for long-running tool calls solve adjacent problems from opposite directions, and the line between them keeps moving.
  • "Agent" is doing too much work as a word. An MCP host, an ACP agent, an AHP session and an A2A peer are not the same shape of thing, and the vocabulary hasn't caught up.

11Conclusion

The interesting part isn't that agents have protocols now. It's that four of them formed independently, around four different boundaries, with no central coordination, and mostly landed on compatible shapes anyway.

Which also means the stack in section 08 probably won't look like that in a year. Some of these will merge or get absorbed, and boundaries that don't have names yet will get them. The habit is more durable than the diagram: ask which boundary you're standing on before reaching for a protocol built for a different one.