1Overview
An open protocol for agent-to-agent communication: discovery via an agent card, task delegation, and progress on long-running work across systems you do not own.
MCP standardised how an agent reaches a tool. The layer above it — how an agent reaches another agent, across an organisational boundary — is younger, noisier, and full of protocols announced with a press release and no users. → This chapter publishes an agent card, calls a remote agent, and then gives you the classification skill that outlives the specific protocol: adopted, announced, or dead. → One of the case studies is a protocol from a major vendor that was archived within a year.
Agents talking to agents across an organisational boundary. The protocol work is real and the hype around it is heavier than anywhere else in this course — so half the chapter is the interop itself and half is the skill of telling a live standard from a press release.
1.2After this chapter you can
→Explain what A2A standardises and how it differs from MCP
→Publish an agent card and make your agent discoverable
→Call a remote agent over A2A and handle a long-running task
→Classify a new agent protocol as adopted, announced or dead from primary evidence
→Read an adoption claim critically, including who published it
→Decide what to build on when the standard is still moving
1.3When to reach for it
When agents need to cross an organisational boundary. Inside one codebase, a function call is cheaper and clearer.
1.4Key parts
An agent card, a task lifecycle, an extension mechanism, and a transport. Plus a habit of checking who actually implements it.
1.5Free vs paid
The protocol and its reference implementations are open and vendor-neutral, governed by a foundation rather than a company.
1.6Watch out
Adoption numbers in this space are usually self-reported by the body promoting the standard. Treat them as claims and check for implementations.
2Lessons 7
2.1 Distinguish agent‑to‑agent from agent‑to‑tool
The distinction between an agent‑to‑agent interaction that returns a pollable task ID and an agent‑to‑tool call that yields an immediate result.
Place A2A at the right layer and recognise when it is the wrong approach.
- Read the MCP description in the chapter below to see how it standardises tool calls.
- Open the A2A specification page at a2a-protocol.org/latest/specification/ and note the current version number.
- Compare the two approaches by examining a "book a flight" example that shows a direct tool response versus an A2A task ID.
- You'll see A flight booking request either returns a direct result as a tool call or a task ID with pollable status as an A2A task.
- Takeaway Use A2A only across real boundaries; otherwise prefer a simple function call
- Check How can you decide whether to use an A2A task ID or a direct tool response when handling a flight‑booking request?
- Cost Free to reason about. The protocol and reference SDKs are open source; nothing here requires an account.
2.2 Publish an Agent Card and verify it
An Agent Card is a JSON document containing the required skills, capabilities and securitySchemes fields.
Create a valid Agent Card JSON file, host it at the well‑known URL and confirm it is discoverable
- Write the Agent Card JSON using the required fields and save it as agent-card.json
- Copy agent-card.json to the /.well-known/ directory inside your web server’s document root
- Restart or reload your web server so the new file is served
- Open a terminal and execute curl https://your-domain.com/.well-known/agent-card.json
- Check that the response includes the
skills, capabilities and securitySchemes sections
- You'll see A GET request to https://agent.example.com/.well-known/agent-card.json returns a JSON document containing skills, capabilities and securitySchemes
- Takeaway Discovery relies on a fixed well‑known path that any client can fetch without a registry
- Check What three sections must appear in the JSON returned from the well‑known /.well-known/agent-card.json URL to confirm a valid Agent Card?
- Cost Free to publish — a static JSON file is a complete agent card if the agent needs no auth. Auth schemes add whatever your identity provider costs, same as any API.
2.3 Send a task to a remote agent
The TASK_STATE_INPUT_REQUIRED status signals that the remote agent is awaiting further information to proceed with the A2A task.
Dispatch a task to a remote agent and handle its status updates instead of expecting an immediate answer
- Send a start‑task message to the remote agent and record the returned task ID
- Poll the task status by ID using the chosen transport binding (JSON‑RPC, gRPC or HTTP+JSON)
- If the status is
TASK_STATE_INPUT_REQUIRED, provide the requested information and continue polling
- You'll see A task sent to a remote agent coming back
TASK_STATE_WORKING immediately, then — polled a minute later — TASK_STATE_INPUT_REQUIRED asking for a missing field, then finally TASK_STATE_COMPLETED once the caller supplies it - Takeaway An A2A task is stateful and long‑running: submitted, working, possibly paused for input or auth, then terminal; design your client to poll or stream and to handle mid‑task questions
- Check After sending a start‑task message, which task state indicates that the remote agent needs additional input before it can continue?
- Cost Free at the protocol level. What you pay for is whatever the remote agent itself charges or rate-limits — the protocol has no metering of its own.
2.4 Add new capabilities to A2A using extensions
The A2A‑Extensions parameter (or header) carries the URI of the desired extension, which must also be declared in the agent’s extensions list.
Enable a payment capability in an A2A interaction without updating every server
- DECLARE the supported extensions in an agent card’s
extensions field using their URI identifiers - SPECIFY the desired extension for a particular request by adding an
A2A-Extensions parameter with the relevant URI - VERIFY that the client checks the agent’s
extensions list before invoking any non‑core functionality
- You'll see An agent card whose
extensions array lists a payments‑extension URI and a client that includes the A2A-Extensions header only for calls that need to move money - Takeaway Extensions let A2A grow by declaring URIs in the agent card, versioning independently, and requesting them per call
- Check How does a client indicate that it wants to use a specific payment extension in an A2A request?
- Cost Free — declaring or checking an extension is a field in JSON you already have. The extension's own implementation (an SDK, a settlement integration) carries whatever cost that specific capability needs.
2.5 Classify a protocol as adopted, announced or dead
A dead protocol shows an archive banner on its repository page, indicating that the project has been deprecated or moved.
Determine whether a protocol is adopted, announced or dead using verifiable evidence you can check yourself
- Open the protocol’s GitHub repository and note the date of the most recent commit; if it is within six months, treat the repo as active
- Look for an archive banner on the GitHub page; its presence marks the project as dead
- Read the press release or steward announcement that cites adoption numbers and record whether the claim is self‑reported or independently verified
- Search online for independent implementations by name outside the originating organisation; finding one confirms adopted status, otherwise treat the protocol as announced
- You'll see A table showing A2A classified as adopted, AP2 and ANP as announced, and ACP as dead after applying the same four checks
- Takeaway Adopted requires an active repo and at least one independent implementation; announced has a spec but no independent implementer; dead shows an archive banner or redirects elsewhere
- Check What evidence would you look for on a protocol’s GitHub page to classify it as dead rather than announced?
- Cost Free — ten minutes per protocol on GitHub, no tooling required beyond a browser.
2.6 Classify AP2 and ANP protocols
Both AP2 (Agent Payments Protocol) and ANP (Agent Network Protocol) lack independent implementations, so they remain classified as announced.
Determine the adoption status of AP2 and ANP using the evidence provided
- Read the description of AP2 — Agent Payments Protocol and note its classification as announced
- Read the description of ANP — Agent Network Protocol and note its classification as announced
- Compare the partner list of AP2 with the author information of ANP to see why they are placed in different adoption buckets
- You'll see Both protocols appear in the “announced” category, with AP2 showing a long partner list and ANP showing a single‑author draft spec
- Takeaway Protocols without foundation governance or independent implementations remain announced, even if one has more commercial partners
- Check Why are AP2 and ANP both placed in the announced bucket despite AP2 having a longer partner list?
- Cost Free — the same ten-minute-per-protocol check as the previous lesson, applied to two more protocols.
2.7 Choose which specifications to use for production
A production‑ready spec is one governed by a recognised body (e.g., the Linux Foundation) and has multiple independent implementations across different languages.
Define today’s production dependencies and prototype‑only targets.
- EVALUATE the spec’s governance by confirming it is managed by a recognised body such as the Linux Foundation.
- VERIFY the existence of multiple independent implementations across different languages.
- CLASSIFY the spec as production‑ready only if it meets both governance and implementation criteria; otherwise mark it prototype‑only.
- DOCUMENT the decision in a short note that includes the protocol name, status, and a recheck date twelve months from now.
- You'll see A one‑page decision note listing each protocol, its status (production or prototype), and a recheck date.
- Takeaway Build production dependencies on foundation‑governed, actively‑committed specs with independent implementations; prototype everything else behind a swappable interface and recheck annually
- Check What two criteria must a specification meet before you can label it production‑ready for today’s dependencies?
- Cost Free. The discipline is a recurring ten-minute check, not a tool or a subscription.