Part 1 of 6 · 3 min read
Overview
In this module you will
- Say what A2A is for and where it overlaps with MCP, without repeating the slogan that "MCP is for tools and A2A is for agents" as if it settled the question.
- Read an Agent Card and say what a client may trust in it (almost nothing, unless it is signed by a key you provisioned), and how a client picks an interface.
- Follow a task through its states, including the two pauses (a question, a missing credential) that a plain function call has no place for.
- Choose between polling, streaming and push notifications for a job that takes minutes, and give the cost of each in requests.
- Explain delegation: three ways an agent can act for a user at another agent, and which one keeps the user's identity intact.
- Wrap an agent as a tool without losing the question, the permission request or the task id.
- Test a server against the protocol with a conformance suite, and check the suite by planting defects.
- Answer the interview question "A2A or MCP, and why?" with an honest answer.
Modules 1 to 6 treated the other side of a call as code: a tool with a schema, which does one thing and returns. That model stops working when the other side is an agent. An agent may need a minute or an hour. It may ask you something halfway through. It may need the person's permission to read a file. It may refuse because the request is outside what it does. And you usually cannot see how it works: it is somebody else's system, and its tools and prompts are none of your business.
A2A (the Agent2Agent protocol) is a specification for exactly that case. This module builds a small A2A 1.0 server and client and a concierge agent that delegates to others, then looks at the parts that go wrong: what a client can believe about a card, how identity travels along a chain, how a tool wrapper loses information, and how to test all of it.
About the examples, and about what is real
Everything runs offline in one process. Real: the protocol messages, state rules, error table and both bindings (JSON-RPC and HTTP+JSON), written from the 1.0 specification, which I read on 24 October 2026; a card signature check; server-sent events over a real socket in one test; and a conformance suite of 41 checks. Imitated: the network is a simulated one with virtual time; the "agents" are short scripts that parse a request with regular expressions, not language models; tokens are my small imitation of signed tokens (HS256, because Python's standard library has no public-key signatures, where the specification's own example uses ES256); gRPC is named but not implemented. Numbers show which designs hold up, not how a real agent would behave. Hard exercises say "I did not run this, so your numbers are the ground truth".
Two warnings about sources. Older write-ups describe an early draft of the protocol: a different card location, different method names, no version header. A client written from them fails against a 1.0 server in three specific ways, which I measured (section 3). And where the specification is silent I made a choice. Those are marked my choice in the text.