Four protocols, one conversation.

Before any protocol, a packet has to find you.

Every protocol on this page is, underneath, one HTTP request riding TLS riding TCP. Before the first byte reaches a server, three things happen: a name becomes an address (DNS), a secure channel opens (TLS), and a structured message crosses it (HTTP). Step through one request and watch the layers stack up.

# one https GET, peeled open layer by layer
ip   = dns_resolve("api.example.com")        # name → IP, cached by TTL
sock = tcp_connect(ip, 443)               # SYN · SYN-ACK · ACK
tls  = tls_handshake(sock, sni="api.example.com")  # 1 round trip; verify cert vs a CA
tls.send("GET /v1 HTTP/2 · Host: ... · Authorization: ...")
resp = tls.recv()                          # 200 OK + headers + body

An API is just an agreed-on shape for the bytes.

An API is a contract: send a request shaped like this, get a response shaped like that. On the web that usually means REST over HTTP, a method, a path that names a resource, headers (including who's asking), and a JSON body. The server answers with a status code and a body. This is the layer every agent protocol is built on. MCP, both ACPs, and A2A are all, at bottom, structured API calls.

MCP is USB-C for models: one port, many tools.

The Model Context Protocol standardizes how an app gives a model tools, data, and prompts. A host (Claude Desktop, an IDE) runs one or more clients, each holding a 1:1 session with a server. Messages are JSON-RPC 2.0, over stdio (local) or Streamable HTTP (remote). And a server can never read the whole conversation or peek at other servers, the host keeps them isolated.

// the model decided to call a tool → the client sends:
{"jsonrpc":"2.0", "id":2, "method":"tools/call",
 "params":{"name":"get_weather", "arguments":{"city":"NYC"}}}

// the server runs it and replies with the same id:
{"jsonrpc":"2.0", "id":2,
 "result":{"content":[{"type":"text", "text":"72°F, clear"}]}}

A server exposes three primitives, split by who decides to use them:

The first ACP: LSP, but for coding agents.

Two unrelated protocols share the initials ACP. The first is Zed's Agent Client Protocol. It standardizes the seam between a code editor (the client) and a coding agent like Claude Code or Gemini CLI (the agent), the same way the Language Server Protocol let any editor talk to any language. The agent runs as a subprocess; they speak JSON-RPC 2.0 over stdio. The editor owns the UI and the files; the agent does the thinking and asks permission before it acts.

editor → agent   initialize            # negotiate versions + auth methods
editor → agent   session/new           # a fresh conversation, its own history
editor → agent   session/prompt        # "fix the failing test"
agent  → editor  session/update        # stream tokens + tool calls back to the UI
agent  → editor  session/request_permission  # may I run this command?
agent  → editor  fs/read_text_file     # the editor owns the files; the agent asks

The second ACP lost its own name.

The other ACP is IBM's Agent Communication Protocol (from IBM Research and BeeAI, March 2025). Different problem: agent-to-agent. Different wire: plain REST over HTTP, deliberately not JSON-RPC, so you can drive it with curl. Then the twist. A month later Google shipped A2A, solving the same problem. Rather than split the ecosystem, in August 2025 IBM's ACP wound down and merged into A2A under the Linux Foundation. Of the two ACPs, one is alive and independent (Zed's). The other is now a chapter in A2A's history.

A2A works like this: each agent publishes an Agent Card at /.well-known/agent-card.json, a machine-readable business card listing its skills and accepted auth schemes. Peers then exchange Tasks, Messages, and Artifacts over JSON-RPC (or gRPC, or REST), with SSE for streaming and webhooks for push.

One prompt can cross every seam.

Put it together. You type a request to a coding agent inside your editor. That single intent can ripple through all four protocols, each at its own seam, each ultimately bytes on the wire. Step the trace and watch the words client and server change meaning at every boundary.

Every seam is also a place to get fooled.

Each protocol boundary is a trust boundary: a line where data of one trust level meets authority of another. Get the boundary wrong and a low-privilege input borrows a high-privilege capability. The most consequential boundary in any agent is between its trusted instructions and the untrusted data it reads. Three failure modes recur.

# the lethal trifecta: risky only when all three are true at once
danger = has_private_data and reads_untrusted_input and can_exfiltrate
# there is no 95%-reliable filter. the only sturdy defense is structural:
assert not danger   # remove a capability until one leg is gone (least privilege)

Four ways to prove you're allowed.

Every request so far carried proof of identity in the same place: the Authorization header, or, for mTLS, the TLS handshake itself. Here are the four schemes you'll meet, in rough order of strength and ceremony. Pick one and see how it travels.

verifier  = random()                 # the client's one-time secret
challenge = sha256(verifier)         # sent up front, so the code can't be stolen mid-flight
code  = authorize(challenge, scope, redirect)   # the user consents in a browser
token = exchange(code, verifier)     # proves it's the same client → access token (+ refresh)
call(api, auth=f"Bearer {token}")   # token is audience-scoped to this one api

At a glance, weakest secret to strongest identity:

It's contracts all the way down.

A protocol is just an agreement about the shape of a message and the meaning of the words around it. API, MCP, the two ACPs, A2A: each draws a contract at a different seam, between parties that trade the names “client” and “server” depending on where you stand. Underneath, they all dissolve into the same DNS lookup, the same TLS handshake, the same HTTP request you met at the start.

So the interesting questions were never on the wire. They're at the seams. Who is allowed to ask. Which token proves it. What happens when an untrusted message crosses a trusted boundary. Get those right and the bytes take care of themselves.

Facts here come from the RFCs, the official protocol specs, and the foundations now stewarding them. Where a protocol moves fast (MCP, A2A), I cite the spec version I read; MCP's current revision is 2025-11-25, and IBM's ACP folded into A2A in August 2025.