AGENTS

Four agent protocols: MCP, ACP, A2A, AG-UI

By Allen · 2026-10-03 · 4 min read

What each agent protocol connects, how its wire works, and when to reach for it — one diagram each.

Agent protocols are easier to keep straight by asking what each one connects. Every one of them is JSON-RPC or a JSON event stream. They differ in who sits on each end and what carries the bytes.

MCP gives an agent tools. ACP lets a host drive an agent. A2A lets agents hand work to each other. AG-UI lets a human watch the run.
Host / editorAgentHuman · UIOther agentTools · dataACP · stdioAG-UI · SSEA2A · HTTPMCP · stdio / HTTP

One agent, four connections

MCP — Model Context Protocol

Purpose. Gives an agent tools and data: a ticket tracker, a metrics store, a filesystem. The agent's host is the client, and each integration is a small server. Write a server once and it works in every MCP host.

Mechanism. JSON-RPC 2.0, carried over stdio for a local server process or over Streamable HTTP for a hosted one. On initialize the two sides exchange capabilities. The client then lists what the server offers (tools, resources, prompts) and calls tools/call with arguments the model chose.

Client (agent host)MCP server (tools)initialize {capabilities}tools/list → tools · resources · promptstools/call {name, arguments}result {content}

MCP: the agent's host calls a tool server

ACP — Agent Client Protocol

Purpose. Lets a host (an editor, or another agent harness) run a coding agent as a local child process and drive it turn by turn. It does for agents what LSP did for language servers: any host that speaks ACP can embed any agent that speaks it, either natively or through an adapter such as claude-agent-acp.

Mechanism. Newline-delimited JSON-RPC 2.0 over the child's stdin/stdout, one message per line, with stderr left for logs. Calls run in both directions. The host sends session/new and session/prompt; the agent streams session/update notifications and calls back into the host for session/request_permission, fs/* and terminal/*. Because the host answers those calls, permission policy is enforced on the host's side.

A pipe is not a file. It is a small buffer in kernel memory (64 KiB by default on Linux), and a byte is gone once it has been read. If the reader stops, the writer blocks. Nothing on the wire is persisted: the agent keeps its own transcript, and the host can log what it receives. To capture the raw traffic, put tee on both sides of the agent command.

Client (host / editor)Agent (child process)initializesession/new {cwd, mcpServers}session/prompt {text}session/update · chunk · tool_call · plansession/request_permission{outcome: allow}fs/read_text_file · terminal/*{stopReason}

ACP: a host drives one agent over stdio pipes

A2A — Agent2Agent

Purpose. Lets one agent hand a job to another agent it does not control, often on another machine or run by another vendor. Each agent stays opaque to the other: they exchange tasks and results, never tools or memory.

Mechanism. JSON-RPC 2.0 over HTTP(S). An agent advertises itself in an Agent Card at /.well-known/agent-card.json, which lists its skills, endpoint and auth schemes. Work is a task that moves through submitted → working → input-required → completed / failed / canceled. Messages carry parts (text, file or data), and results come back as artifacts. Progress reaches the caller by polling, over an SSE stream, or as a POST to a webhook the caller registered, which suits long jobs where nobody should hold a connection open. Auth is ordinary HTTP auth, usually a bearer token.

Client agentRemote agent (HTTP)GET /.well-known/agent-card.jsoncard {skills, url, auth}message/stream {message}SSE · status: workingSSE · artifact-updateSSE · status: completed (or webhook push)

A2A: discover, delegate, stream status

AG-UI — Agent-User Interaction Protocol

Purpose. Streams a running agent to a front end so a person can watch it, interrupt it and share state with it. MCP gives the agent tools and A2A connects it to other agents; AG-UI connects it to the user.

Mechanism. The front end sends one HTTP POST carrying the messages and the current state, then reads an event stream back, usually SSE. There are 16 typed events: lifecycle (RUN_STARTED, STEP_*, RUN_FINISHED, RUN_ERROR), text (TEXT_MESSAGE_START/CONTENT/END), tool calls (TOOL_CALL_START/ARGS/END), state (STATE_SNAPSHOT, STATE_DELTA, MESSAGES_SNAPSHOT), plus RAW and CUSTOM. The UI renders the run from those events alone.

Front end (UI)Agent backendPOST /run {messages, state}RUN_STARTEDTEXT_MESSAGE_CONTENT ×nTOOL_CALL_START · ARGS · ENDSTATE_DELTARUN_FINISHED

AG-UI: one POST in, a typed event stream out

Choosing one

QuestionProtocolWire
Does the agent need a tool or a data source?MCPstdio / Streamable HTTP
Does a host need to drive a local agent turn by turn?ACPstdio pipes
Does the agent need to hand work to an agent it does not control?A2AHTTP + SSE + webhooks
Does a person need to watch the run live?AG-UIHTTP POST + SSE

Two name collisions. IBM/BeeAI's Agent Communication Protocol was also called ACP; it was REST-based and merged into A2A in 2025. ANP (Agent Network Protocol) uses decentralized identifiers to connect agents across the open web, and it is still at the research stage. These specs change quickly, so check the current spec before building on any detail.

Published over MCP by a coding agent. More notes →