A2A is an open protocol that lets an agent in one application, framework or organization hand a task to an agent somewhere else. Google announced it in April 2025 and transferred it to the Linux Foundation that June. In day-to-day ADK work you will mostly use sub-agents; A2A earns its place only when the other agent sits beyond your codebase.
What is the A2A protocol, and who controls it now?
The A2A protocol is an open standard that lets one AI agent hand a task to another agent running in a different application, framework or organization. Google announced it in April 2025 and transferred stewardship to the Linux Foundation in June 2025, so the specification is no longer controlled by a single cloud vendor and carries no licence fee for implementers.
The A2A project publishes the specification, the JSON schemas and sample implementations on GitHub under the a2aproject organization. The Linux Foundation, the same body that hosts Kubernetes and OpenTelemetry, holds the project's governance. That matters for the commercial case in the video: a company whose agent runs on a non-Google stack can expose and consume A2A without adopting Google Cloud.
A2A is frequently paired with the Model Context Protocol, an open standard that Anthropic introduced to connect agents to tools and data sources. The two solve different problems and can run in the same system. The video's framing is accurate on this point: MCP connects an agent to tools, while A2A connects an agent to another agent.
Open standard does not mean mature deployment. The speaker says he has used A2A in only a couple of projects, both proofs of concept, with no production rollout. Treat that as one practitioner's experience (evidence class D), not a survey of adoption.
Sub-agent, MCP or A2A agent: which one does your task need?
Use a sub-agent when the work stays inside one application, use an MCP server when the agent needs a tool, and use an A2A agent only when the other agent belongs to a different team, application or organization. The distinction is about ownership boundaries and where the code runs, not about which option sounds more advanced.
The sub-agent case
A sub-agent is a helper agent declared inside the same ADK application. Your orchestrator hands it a slice of the goal: one agent researches, another writes the report, a third queries the database. Everything runs in one process or one deployment, so latency stays low and there is no network hop. The video's advice is blunt: most agent builds should stop here.
The MCP case
An MCP server exposes tools once and lets many agents reuse them. It standardises agent-to-tool communication rather than agent-to-agent conversation. A2A does not replace it: an agent that speaks A2A can still call MCP servers for its own work, and the video confirms the two compose without conflict.
The A2A case
Reach for A2A when the agent you need is owned by someone else. That covers a different team inside the same company that will not share code, a partner organization on another framework, or a public capability such as a validation check. The video's GST-number example fits: a government or registry agent exposes a check that returns valid or not, without granting access to the underlying records.
| Option | Connects | Runs where | Use when | Main trade-off |
|---|---|---|---|---|
| Sub-agent | Agent inside the same app | Same process or deployment | One team, one goal, one codebase | Not reachable from outside |
| MCP server | Agent to tools | Separate server, reusable | Many agents need the same tools | Tool surface, not a conversation |
| A2A agent | Agent to agent | Remote endpoint | Different team, framework or company | Public network, latency, auth |
How does A2A work in Google ADK: agent card, task, artifact?
In Google's Agent Development Kit, exposing an agent over A2A takes an agent card plus a wrapper and a runtime flag, and consuming it takes a remote agent entry in the host agent. The agent card is the discovery step: a JSON document that tells any would-be caller what the agent is called, where it lives and which skills it offers.
The card is served at a fixed well-known path derived from the agent URL. The video's presenter looks for a folder of that name and finds nothing, then explains that the path is an inbuilt keyword in ADK rather than a directory he created. The same correction applies to the card file itself: he expected to name it agent-card, while ADK looks for agent.json. Getting either detail wrong produces a 404 before any task is sent.
Skills are the part a language model actually reads. Each entry carries an id, name, description, tags and example prompts. The video notes that tags serve categorisation and discovery, while the skill name and the agent URL are the fields that drive selection. Its cost agent lists two skills that map to its two internal tools, cost by service and cost by project.
Once discovery succeeds, the calling agent delegates a task and the remote agent returns a result. Payloads can travel as messages or as artifacts, and ADK stores artifacts locally by default or in Cloud Storage when configured. The important structural point is that the remote agent is still declared as a sub-agent in the host, so the orchestrator's transfer logic is the same as for a local helper.
What does the local ADK demo actually change in code?
The demo changes little code: the HR policy agent gains an agent card, is wrapped in an A2A app, and is launched with a flag, while the consumer agent swaps a tool for a remote agent pointing at that URL. Everything else, including the Vertex AI Search data store behind the HR agent, stays untouched.
Exposing the HR agent
The HR agent stays an ordinary ADK agent answering from a Vertex AI Search data store. Publishing it takes three edits: add the JSON card, wrap the agent in an A2A app, and start the server on port 8001 with adk web --a2a.
Without that flag the agent still responds to questions but serves nothing at the agent card path, so no other agent can find it.
Consuming it from a host agent
The host agent gains one remote sub-agent and loses nothing else. It declares that remote sub-agent instead of a tool, using the advertised URL and the well-known card path.
It has no search capability of its own. When asked an HR question, it transfers control, the remote HR agent runs the search, and the answer returns to the caller.
Running two callers at once
The change is per-consumer, not per-agent, which is why a second copy costs almost nothing. The presenter copies the host agent into a second instance and asks both the same travel-policy question.
Both respond, which shows that one exposed A2A endpoint serves many independent consumers. That property is what makes an organization-wide policy agent worth publishing once rather than rebuilding per team.
The video's 404 detour is worth keeping. The presenter had to change the card file name and re-check the well-known path before the handoff worked, and beginners hit the same wall because the path looks like a directory they should create.
What changes when the A2A agent is deployed and private?
A deployed A2A agent behaves the same as a local one except for two things: the URL points at a hosted service, and a private service requires the caller to attach an identity token. The video shows a cost agent on Cloud Run that queries Google Cloud billing data in BigQuery and answers cost questions.
The cost agent exposes two skills that wrap two functions, cost by service and cost by project, and its card carries the Cloud Run URL. The host agent runs locally and reaches it over the network. Nothing about the orchestration changes; only the address does.
Authentication for service-to-service calls
With public access enabled, the demo works with no token at all. When the service is set to require authentication, the agent card request itself returns HTTP 403 until a credential is attached. The presenter's fix is a small function that fetches an access token and adds it to the request header, which is the standard pattern for calling a private Cloud Run service from another agent.
That token has a lifetime, and the video shows the consequence: after it expires, calls fail with 403 until the token is refreshed or the server restarted. Production code needs refresh logic, not a one-off fetch.
The video frames this as the most complex part of a remote A2A setup, and the framing holds. Discovery problems surface as 404s, authentication problems surface as 403s, and the two failure modes are easy to confuse when debugging.
Why do images and files get dropped over A2A?
ADK's default A2A path carries text, so an image, audio file or other binary artifact returned by a remote agent can be dropped unless the caller adds a callback that forwards it. The video demonstrates this with an illustration agent that generates branded images and a slide agent that consumes them.
The illustration agent runs on a Gemini model and produces campaign artwork without embedded text. Exposed over A2A, it becomes an organization-wide brand asset service: the slide agent writes slide content and calls the illustration agent whenever an image is needed, so every image follows the same branding rules.
The first run fails to deliver the image. Only the text reaches the consumer, even though the remote agent produced the artwork. The presenter's diagnosis is that the binary payload is not being propagated, and his fix is a short callback that attaches the image to the response in multipart form, after which the slide agent receives both the copy and the illustration.
This is a useful debugging rule for any agent-to-agent build: capture the raw request and response JSON, compare what the remote agent sent with what the host received, and add handling for whatever went missing. Files then land in the artifact store, local by default or Cloud Storage when configured.
Where does A2A fit in a real system today?
A2A fits workflows where one party needs a yes-or-no answer or a narrow capability from another party's agent, and it does not fit the bulk of intra-application orchestration. The video's examples share that shape: validation, status checks and centrally managed assets.
- A tax or registration system exposes an agent that confirms whether a GST number is registered, without exposing the registry.
- A credentialing platform exposes an agent that confirms a certification ID is valid, replacing the manual lookup a reader does today.
- An insurer exposes an agent that reports claim status under an API key, replacing manual checks across thousands of claims.
- An internal platform team exposes a policy agent that other teams call instead of rebuilding.
- A brand team exposes an illustration agent so downstream slides and campaigns stay consistent.
The counterweight is the public internet. Traffic between agents crosses the network, which adds latency and a security surface that a same-process sub-agent never has. The presenter's conclusion is that sub-agents should be the default and A2A the exception reserved for genuine cross-boundary needs.
That is an opinion from one practitioner with proof-of-concept experience. It is consistent with the standard's design intent, which targets interoperability between agents built on different frameworks, but it is not a measured comparison of latency or reliability.
Frequently asked questions about the A2A protocol
- Is the A2A protocol free to use? Yes. The specification is published openly on GitHub and governed by the Linux Foundation after Google transferred it in June 2025, so no licence fee applies. You still pay for the infrastructure that runs your agents.
- Does A2A replace MCP? No. MCP standardises how an agent reaches tools and data, while A2A standardises how one agent delegates a task to another agent. An A2A agent can call MCP servers, and the video shows the two running together.
- Why does the agent card URL return 404? ADK serves the card at a fixed well-known path derived from the agent URL, and it only exists when the server is launched with the A2A flag. The card file must also use the name ADK expects,
agent.json, rather than a folder the developer creates.
- Why does a private A2A agent return 403? The caller is not attaching a valid identity token. A Cloud Run service set to require authentication rejects the agent card request too, so the host agent needs a refreshable token added to its request headers.
- Why is the returned image missing in the host agent? The default path carries text, so binary artifacts need a callback that attaches the file to the response. Compare the remote agent's raw JSON with what the host received to find what was dropped.
Turning a walkthrough like this into something readable
The most reusable idea in this walkthrough is that A2A confusion is usually a boundary question: who owns the other agent, and does the work cross it. A 56-minute screen recording can carry that lesson, but it can also bury it under a 404 and a token refresh. Written down, the same lesson survives skimming and searching.
If you have explanations like this sitting in your own videos, whether a protocol walkthrough, an interview or a hard-won debugging story, that material can become an article readers can scan, quote and link back to. Paste a YouTube URL into Skala Blog, let it transcribe the video, and turn the transcript into a structured draft you can edit before publishing.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits