Home › Guides › A2A Protocol Explained
Tech Explained · 2026A2A Protocol Explained in 2026: How Agent2Agent Works, MCP vs A2A, and Your First Multi-Agent Build
The A2A protocol is an open standard that lets AI agents built on different frameworks discover each other, delegate tasks and return results over HTTP, without sharing their internal memory or tools. Google released it in April 2025 and donated it to the Linux Foundation; version 1.0 shipped in March 2026 with 150+ supporting organisations.
- A2A is agent to agent; MCP is agent to tool. They sit at different layers and most production systems in 2026 run both.
- Version 1.0 shipped on 12 March 2026. Its headline change was cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalisation (RFC 8785).
- Three transports, one behaviour. The spec requires JSON-RPC 2.0, gRPC and HTTP/REST to be functionally identical, so your client choice is an infrastructure decision, not a feature decision.
- Adoption is real but concentrated. The Linux Foundation reported 150+ supporting organisations and 22,000+ GitHub stars at the one-year mark on 9 April 2026, mostly inside large platform vendors.
- Security is yours to build. A2A defines no authorisation framework and no central Agent Card registry, so identity and least privilege are your job.
- Learn it second, not first. If you have never shipped an agent that calls a tool reliably, MCP and evaluation matter far more to your next job than A2A does.
Your claims agent works. It reads the policy PDF, pulls the customer record, drafts a reply, and the demo lands well. Then someone in finance asks whether it can hand the payout calculation to the pricing agent another team already built, in a different framework, on a different cloud, under a different manager. That is the moment you stop writing prompts and start writing integration code, and it is the exact problem the A2A protocol was designed to remove.
What is the A2A protocol, and what problem does it actually solve?
Agent2Agent, usually shortened to A2A, is an open protocol for letting autonomous agents talk to each other as peers. Google announced it on 9 April 2025 with more than 50 launch partners, then donated it to the Linux Foundation, where it now lives under Apache 2.0 with the specification published at a2a-protocol.org and official SDKs in Python, JavaScript, Java, Go and .NET.
The problem it solves is boring and expensive. Before a shared protocol existed, a Salesforce agent could not delegate a subtask to a ServiceNow agent without bespoke glue code, and a Vertex AI agent could not coordinate with a Bedrock agent without someone hand-rolling a bridge. Every pair of agents was its own integration project, which meant the cost of a multi-agent system grew roughly with the square of the number of agents rather than with the number of agents.
The design decision that makes A2A interesting is opacity. An agent exposed over A2A does not reveal its prompts, its memory, its model or the tools it calls. It publishes what it can do and accepts tasks. That is deliberately unlike an API contract, because the caller is not supposed to know how the work gets done, only what it asked for and what came back. If you are building agentic AI systems for more than one team, that boundary is the whole point: it lets the pricing team rewrite their agent on Friday without breaking your claims flow on Monday.
How the Agent2Agent protocol works: Agent Cards, tasks and transports
The mechanism is smaller than the hype suggests, which is a compliment. There are three moving parts.
One A2A task, end to end
A2A crosses the boundary between two teams. MCP stays inside each one.
Flow drawn from the A2A specification published at a2a-protocol.org, checked 12 September 2026.
The Agent Card
Discovery happens through a JSON metadata document, conventionally served at /.well-known/agent-card.json. It names the agent, describes its skills, declares which input and output modalities it accepts (text, files, structured data), and lists the authentication schemes it supports. Version 1.0, released on 12 March 2026, formalised signing those cards with JWS as defined in RFC 7515, using JCS canonicalisation from RFC 8785, so a caller can verify that the card genuinely belongs to the domain it claims.
The task
A2A's unit of work is a task, not a function call, and that distinction shapes everything else. A task has a lifecycle that moves through states such as submitted, working and completed, which means the protocol assumes some work takes minutes or needs a human to approve a step. Results come back three ways: synchronously, streamed over Server-Sent Events, or pushed to a callback URL you registered.
The transports
There are three: JSON-RPC 2.0, gRPC, and plain HTTP/REST. The spec requires all three to behave identically, which is a genuinely useful guarantee. You can put a REST-only agent behind an existing API gateway and a gRPC agent inside a service mesh, and the semantics do not drift between them.
MCP vs A2A: which protocol does what
This is the question that trips people up in interviews, and the framing in the question is wrong. MCP and A2A are not competitors. MCP is the interface between an agent and the world it acts on. A2A is the interface between agents inside a larger system. The Model Context Protocol was created by Anthropic and donated to the Linux Foundation's Agentic AI Foundation in December 2025, so both protocols now sit under the same neutral governance.
| Dimension | MCP | A2A |
|---|---|---|
| What it connects | One agent to tools, data and prompts | One agent to another agent |
| What stays hidden | Nothing; the tool schema is fully described to the model | Each agent's prompts, memory, model and tools |
| Discovery | Server lists its tools when the client connects | Signed Agent Card at /.well-known/agent-card.json |
| Transport | stdio and streamable HTTP | JSON-RPC 2.0, gRPC and HTTP/REST, all required to behave identically |
| Unit of work | A tool call, normally short-lived | A task with a lifecycle, built for long-running and human-in-the-loop work |
| Async support | Progress notifications during a call | Server-Sent Events plus a push callback URL |
| Origin and governance | Anthropic, donated to the Linux Foundation's AAIF in December 2025 | Google, donated to the Linux Foundation, v1.0 in March 2026 |
| Maturity signal | Reported at 97 million monthly SDK downloads by February 2026 | 150+ supporting organisations and 22,000+ GitHub stars at the April 2026 one-year mark |
| When you need it | Almost immediately, from your first useful agent | Once agents cross a team, vendor or cloud boundary |
The practical rule: reach for MCP when your agent needs to do something, and reach for A2A when your agent needs someone else to do something. A single assistant wired to files, a database and an internal API needs MCP and nothing more. If you want the tool-design half of this in exam form, it is the centre of gravity of the CCDV-F developer certification, and 360DT runs a live 6-week cohort that builds a production Claude app and practises exactly that boundary.
Also read: MCP Explained for Claude Certification Candidates: The 18% Most People Underestimate.
Where the A2A protocol runs in 2026: AI agent interoperability across clouds
A2A at the one-year mark
Three numbers worth quoting in an interview, all from primary sources.
Figures from the Linux Foundation's one-year announcement and the published specification, checked 12 September 2026.
AI agent interoperability stopped being a whitepaper idea sometime last year, and adoption is now genuinely broad at the platform layer. Microsoft's April 2026 Azure AI Foundry release notes list "Add an A2A agent endpoint to Foundry Agent Service (preview)" as a shipped feature. Amazon added native A2A support to Bedrock AgentCore Runtime in late 2025 and extended it through AWS Marketplace in November 2025. Google's Vertex AI, which originated the protocol, was first to ship a managed multi-agent runtime around it, and Salesforce Agentforce 3 was named in the Linux Foundation's own one-year announcement alongside enterprise deployments at IBM, Cisco, SAP and ServiceNow.
What that list tells you matters more than the list itself. A2A landed first where the pain was worst, which is inside vendors selling agent platforms to each other's customers. If you work at a product company with one agent and three tools, none of this is urgent yet. If you work at a bank, a GCC or a systems integrator stitching together agents from three vendors, it already is. Anyone building on the Azure side will meet Foundry's agent surface directly in the AI-200 Azure AI cloud developer track, and the AWS equivalent sits inside the AWS solutions architect and DevOps path.
A worked scenario: two agents at a mid-size Indian insurer
The following is an illustrative scenario, not a real customer story, built to make the trade-off concrete.
Take a mid-size insurer in Pune processing roughly 40,000 motor claims a month. The claims platform team of five has a working orchestrator agent on Azure. A separate four-person pricing team, sitting under actuarial, already runs a settlement calculator agent on Google Cloud, with its own rate tables and its own audit trail. Finance wants claims to call pricing automatically for anything under Rs 50,000.
Option one is a REST endpoint. The pricing team exposes POST /calculate, claims calls it, and you are live in two weeks. Option two is A2A: pricing publishes a signed Agent Card, claims discovers it, tasks flow with a lifecycle, and streaming updates arrive over SSE.
For one caller, one callee and one operation, the REST endpoint wins and it is not close. A2A costs you a week of learning, an SDK dependency, a card-signing story and a new failure mode, in exchange for capabilities you are not using. The picture flips at the third consumer. Once underwriting and fraud both want the pricing agent too, and pricing wants to change its internals without three teams re-testing, the opaque-agent contract starts paying for itself, and the task lifecycle stops you from rebuilding retries and long-poll handling in every caller.
The tell is not agent count. It is ownership count. Two agents owned by one team should just call each other. Two agents owned by two managers with two release calendars are the case A2A was written for.
Also read: Enterprise AI Agents in 2026: Why Only 23% of Pilots Scale, and 6 Skills That Close the Gap.
Is the A2A protocol worth learning in 2026?
Yes, but second. Here is the honest ordering, and it is the opposite of what the conference talks imply.
If you cannot yet make one agent call one tool reliably, evaluate its output, and explain why it failed on Tuesday, A2A will not help you get hired. Interviewers in Bengaluru and Hyderabad are still asking about retrieval quality, tool schema design, cost per request and evaluation harnesses, because that is where projects die. Learn MCP, tool design and evals first. A2A is a two-day protocol once you understand the layer beneath it, and it is a two-month slog if you do not.
Where it does pay immediately is seniority signalling. Knowing why an agent boundary should be opaque, and being able to say out loud that ownership count rather than agent count is what triggers the need for a protocol, is an architect's answer rather than a developer's. That reasoning is the kind tested at the architecture level in the CCAR-F architect foundations exam, and you can see how the four Claude exams stack against Microsoft's on the full certifications overview.
And the caveat nobody puts on a slide: A2A does not make your agents good. It makes them reachable. A badly grounded agent that hallucinates policy numbers becomes a badly grounded agent that hallucinates policy numbers to four other agents at machine speed, with a signed card vouching for it. Interoperability multiplies whatever quality you already had, in both directions.
Limitations and the security work you inherit
Read the spec's silences, not just its features. A2A deliberately leaves several things to implementers, and every one of them becomes your ticket.
- Agent Card spoofing. Palo Alto Networks' A2A security guidance notes that card signing is supported but not enforced, and there is no central registry, so anyone can publish a card claiming skills they do not have. Pin your peers explicitly. Do not discover strangers.
- No authorisation framework. The spec covers authentication schemes but leaves authorisation entirely to you. If you skip this, any agent that can reach the endpoint can invoke any skill on it.
- Coarse OAuth tokens. Security analyses of A2A repeatedly flag tokens scoped to the whole agent rather than to a skill, with no mandated short expiry for sensitive operations. A leaked token stays useful for a long time.
- Tracing across the boundary. Once a task crosses into an agent you cannot see inside, your logs stop at the request. Propagate a correlation ID from the first call or you will never reconstruct an incident.
None of this is a flaw in the design so much as a consequence of it. A protocol that stayed neutral across five clouds could not have shipped an opinionated authorisation model. But it means the operational layer, identity, quotas, tracing and rollback, is work you own. That work has a name and a job title now, and it is closest to what the MLOps and AI-300 track covers on the monitoring and governance side.
Also read: AI Agent Governance in 2026: 7 Controls Every Enterprise Needs Before Deploying AI Agents.
How to learn the A2A protocol: an 8-week build path
You do not need a cluster or a budget. Two Python processes on a laptop are enough to understand every idea in the specification.
Eight weeks from zero to a two-agent system
Each stage ends in something you can put in a repository and talk about in an interview.
Build the tool layer first
Write one MCP server exposing two real tools, for example a SQLite query and a PDF extractor. Deliverable: an agent that answers questions grounded in your own data, with logs showing every tool call.
Read the specification properly
Work through the Agent Card, task lifecycle and transport sections at a2a-protocol.org. Deliverable: a one-page note explaining, in your own words, why a task has states and a tool call does not.
Publish your first Agent Card
Wrap last week's agent as an A2A server using the official Python SDK and serve the card at /.well-known/agent-card.json. Deliverable: a curl command that fetches your card and returns valid JSON.
Make a second agent call the first
Build a client agent in a different framework on purpose, then send a task with message/send. Deliverable: a terminal recording of a task moving from submitted to completed.
Add streaming and a long task
Make the remote agent take 45 seconds and stream progress over SSE, then handle the client dropping mid-stream. Deliverable: a reconnection path that does not duplicate work.
Sign and verify the card
Sign the Agent Card with JWS and have the client refuse an unsigned or mismatched card. Deliverable: a failing test that proves a spoofed card is rejected.
Deploy behind a real gateway
Put the remote agent on a managed runtime such as Azure AI Foundry or Bedrock AgentCore, with OAuth in front. Deliverable: a public endpoint your client reaches with a scoped token.
Write the failure post-mortem
Break it deliberately: expired token, malformed task, remote agent timing out. Deliverable: a README documenting each failure mode and how your system degrades.
Path built against the SDKs and platform features documented as available on 12 September 2026.
| Skill | Why it matters for A2A | How to practise it this week |
|---|---|---|
| MCP tool design | Every A2A agent is only as good as the tools underneath it | Expose two tools with tight schemas and no free-text arguments |
| JSON-RPC 2.0 and SSE | The default A2A transport and its streaming model | Hand-write one request and one SSE stream with curl before touching an SDK |
| OAuth 2.0 scoping | A2A authenticates but does not authorise; scopes are your control | Issue a token valid for one skill and confirm the others reject it |
| Async task design | Tasks are long-running by assumption, not by exception | Add idempotency keys so a retried task does not run twice |
| Distributed tracing | Your logs end at the trust boundary unless you plan for it | Propagate one correlation ID across both agents and grep for it |
| Evaluation harnesses | Interoperability spreads bad output faster than good output | Score the remote agent's replies on 30 fixed cases before you trust it |
Learn the layer beneath A2A first: build agents that plan, use tools and act
A 16-week live cohort in generative AI, RAG and AI agents, certified on both Microsoft Copilot Studio and Claude Code, the two stacks real job postings are naming. You build agents that plan, call tools and act, which is the foundation every multi-agent protocol sits on top of.
Explore the course
The verdict: what we would do in your position
If you are an engineer with two years of experience and 30 spare hours a month, spend the next quarter on tool design, retrieval quality and evaluation, then give A2A a single focused fortnight using the path above. You will finish with a two-agent system, a signed card, and a post-mortem, which is a better portfolio artefact than three half-built chatbots and reads as architectural maturity rather than tool-chasing.
If you are an architect or a team lead, the decision is a threshold, not a preference. Adopt A2A when a second team wants to consume your agent, and not one sprint earlier. Until then a documented REST endpoint is cheaper, faster and easier to debug, and pretending otherwise costs you a quarter. Just do the identity and tracing work at the same time as the protocol work, because retrofitting scoped tokens across four agents is the part everyone underestimates.
The people getting hired for this in India right now are not protocol specialists. They are engineers who can build a grounded, evaluated, tool-using agent and then reason clearly about where its boundaries should sit. That is exactly the ground covered by 360DT's live AI Engineer course, and if you are heading toward the enterprise deployment side of the work, the Forward Deployed Engineer track is the closer fit. Start with the course page, or sit in on a free webinar first and decide from there.
Related guides
- Agentic AI Jobs in India 2026: How a 300% Hiring Surge Is Creating 6 New Tech Careers the demand picture behind every protocol on this page.
- Retrieval Augmented Generation Explained in 2026: How RAG Actually Works, Step by Step the grounding layer you should master before any agent talks to another.
- 8 Generative AI Project Ideas for 2026: Stack, Data and What Interviewers Ask portfolio builds that pair well with the eight-week path above.
- What Is a Forward Deployed Engineer in 2026? Role, Skills and Career Path Explained the role that owns multi-agent rollouts inside client systems.
- AI Engineer Jobs in Bangalore 2026: Salary, Skills and Companies Hiring which employers are actually asking for agent experience.
- MLOps Engineer Salary in India 2026: Advertised Pay by Experience, Company Type and Skill Stack what the operational half of this work pays.
Frequently asked questions
What is the A2A protocol in simple terms?
The A2A protocol is an open standard that lets one AI agent hand work to another AI agent built by a different team, on a different framework or cloud. The receiving agent publishes an Agent Card describing its skills, the caller posts a task to its endpoint over HTTPS, and the result comes back synchronously, as a stream, or to a callback URL. Neither side sees the other's prompts, memory or tools.
Is A2A a replacement for MCP?
No. MCP connects an agent to tools and data; A2A connects agents to each other. Most production systems in 2026 run both, with MCP inside each agent and A2A between them. Both protocols are now governed under the Linux Foundation, MCP through the Agentic AI Foundation since December 2025.
Which cloud platforms support A2A?
Azure AI Foundry lists an A2A agent endpoint feature in its April 2026 release notes, Amazon Bedrock AgentCore Runtime added native support in late 2025 and extended it via AWS Marketplace in November 2025, and Google Vertex AI shipped the first managed multi-agent runtime around the protocol. Salesforce Agentforce 3 was named in the Linux Foundation's April 2026 announcement.
Do I need A2A for a single AI agent?
No, and adopting it early is a common mistake. One agent calling tools needs MCP only. The trigger for A2A is not the number of agents but the number of owners: once a second team wants to consume your agent on its own release calendar, the opaque-agent contract starts earning its cost.
Is the A2A protocol secure by default?
Not by default. Version 1.0 formalised signed Agent Cards using JWS, but signing is supported rather than enforced, there is no central card registry, and the specification defines no authorisation framework. Security guidance from vendors including Palo Alto Networks recommends pinning known peers, verifying signatures, scoping OAuth tokens narrowly and treating discovery as spoofable.
What programming languages have official A2A SDKs?
Five: Python, JavaScript, Java, Go and .NET. The reference implementation is Apache 2.0 licensed on GitHub, and the specification is published at a2a-protocol.org. Python has the widest example coverage, so start there unless your team is already committed to another stack.
How long does it take to learn A2A?
Two weeks of focused evening work if you already understand tool calling, HTTP APIs and async patterns. Considerably longer if you do not, because most of the difficulty is in the layer beneath the protocol. The eight-week path in this guide deliberately spends the first two weeks on tools and reading rather than on A2A itself.
Will learning A2A help me get an AI engineer job in India?
It helps as a differentiator, not as an entry ticket. Indian job postings still centre on retrieval quality, tool design, evaluation and cost control. A working two-agent project with a signed Agent Card and a documented failure analysis is a strong portfolio piece, but only on top of demonstrable single-agent competence.
About this guide. 360 Digital Transformation is an independent training provider. We are not affiliated with the certification bodies, vendors or products compared here, and our courses are exam preparation rather than official training. Product features and pricing change often; figures cited were checked on 12 September 2026.