In 2025, every serious team built AI agents. By 2026, they hit the same wall: the agents could not talk to each other. The customer-support agent built on one framework could not hand work to the procurement agent a vendor shipped, and nobody wanted to write custom glue code for every pairing.
The A2A protocol — Agent2Agent — is the open standard that fixes this. It gives agents a common language to find each other, delegate tasks, and return results, without either side exposing its prompts, memory, or internal tools. And 2026 is the year it went from announcement to infrastructure: a stable v1.0 release in March, and a move under the same neutral foundation as MCP in August.
This guide explains what A2A is, how a task actually flows through it, how it differs from MCP, who supports it in October 2026, what it honestly cannot do — and why Indian developers and IT services teams should pay attention.
Why your AI agents cannot work together yet
The problem is easiest to see with an example. A mid-size company’s HR team runs an onboarding agent that creates employee accounts and assigns equipment. Their finance team uses a vendor’s expense agent. When a new hire starts, someone — usually a human, or a brittle script — has to carry information between the two.
Multiply this by every department and every vendor, and you get the M×N integration problem: M agents that need to talk to N other agents, each pair needing custom code. The number of integrations grows faster than the number of agents, and every vendor update risks breaking the glue.
Single-agent tools already had this problem solved for tools. KnowledgeSense covered the MCP explainer earlier this year: MCP standardizes how one agent reaches down into databases, calendars, and APIs. But MCP is vertical — one agent talking to its tools. Nobody had standardized the horizontal direction: agent to agent. A2A is that standard.
What A2A actually is, in plain English
The Agent2Agent protocol is an open specification for communication between independent AI agents. Think of it less like an API and more like a shared language:
- Discovery. An agent publishes an “Agent Card” — a public JSON document describing what it can do, how to reach it, and how to authenticate. Any client agent can read that card.
- Delegation. A client agent sends the remote agent a message describing a goal. The remote agent can accept the work, ask clarifying questions, stream progress, or refuse.
- Return. The remote agent reports task status and hands back “artifacts” — documents, structured data, files — as results.
The critical design choice is opacity. The two agents never see each other’s prompts, memory, or tool implementations. An MCP client calls your tools one by one and watches each result; an A2A client hands you a goal and gets back a task, status updates, and artifacts. Your reasoning stays private. That is what makes it safe to delegate work to agents you did not build and cannot inspect.
The protocol reuses boring, proven technology on purpose: HTTP, JSON-RPC 2.0, and Server-Sent Events for streaming. There is no new transport to learn and no exotic runtime to install.
How an A2A task actually works, step by step
Back to the HR example. The onboarding agent (client) needs the expense agent (remote) to set up a new employee’s travel account:
- Discovery. The onboarding agent fetches the expense agent’s Agent Card from
/.well-known/agent-card.json. The card says: this agent can create travel accounts, it accepts text and structured employee records, it speaks HTTPS with OAuth 2.0. - Task creation. The onboarding agent sends a message: “Create a travel account for employee #4821, joining October 20.” The expense agent creates a task and returns its ID.
- Working and input-required. The expense agent starts work. If it needs a missing detail — say, the employee’s cost centre — the task enters an
input-requiredstate, and the client supplies the missing field. - Streaming or polling. For long tasks, the client can subscribe to Server-Sent Events and receive
TaskStatusUpdateEventandTaskArtifactUpdateEventmessages in real time. For tasks that run for hours or disconnect, push notifications go to a client-provided webhook URL instead. - Completion. The task reaches a terminal state — completed, failed, canceled, or rejected. Completed tasks return artifacts: in this case, the travel account credentials and a setup summary.
Nothing about the expense agent’s internals leaked: not its model, not its prompts, not how it talked to the travel-booking system. The onboarding agent only ever saw the card, the status, and the artifacts.
The building blocks of A2A
The official specification organizes the protocol in three layers. You do not need to memorize them, but knowing the vocabulary helps you read any A2A documentation:
- Agent Card — the JSON metadata document every A2A server publishes, covering identity, skills, endpoint, and authentication requirements.
- Message and Parts — a message is one conversational turn between client and remote agent; each message carries one or more parts, which can be text, file references, or structured data.
- Task — the fundamental unit of work, with a unique ID and a defined state machine (submitted → working → input-required → completed/failed/canceled).
- Artifact — an output produced by the task: a document, image, or structured payload, composed of parts.
- Streaming and push notifications — real-time updates over SSE for connected clients; server-initiated webhook posts for long-running or disconnected work.
- Security — authentication declared in the Agent Card’s
securitySchemesfield, using standard flows like OAuth 2.0, Bearer tokens, or API keys. Credentials are never embedded in the card itself; they are exchanged out of band.
A short history: April 2025 to v1.0
A2A moved unusually fast for a standards effort:
- April 9, 2025 — Google announces the A2A protocol, with more than 50 launch partners including Atlassian, Salesforce, LangChain, and PayPal.
- June 23, 2025 — Google donates A2A to the Linux Foundation, making it vendor-neutral from the start. SDKs ship in Python, JavaScript/TypeScript, Java, Go, and .NET.
- July 2025 — v0.3 adds gRPC transport support and signed Agent Cards (JWS), an early enterprise-security signal.
- August 2025 — IBM folds its rival Agent Communication Protocol (ACP) into A2A under the Linux Foundation; ACP development winds down and its assets are contributed to the project.
- March 2026 — A2A v1.0 ships: the first stable specification. Teams can now design production systems against it without fearing breaking changes.
That timeline matters because enterprise IT buys on stability signals. v1.0 is the line between “interesting experiment” and “infrastructure you can plan around.”
The 2026 turning point: A2A joins the Agentic AI Foundation
On August 17, 2026, the A2A project joined the Agentic AI Foundation (AAIF) — the Linux Foundation body formed in December 2025. That is the same neutral home Anthropic contributed MCP to as a founding donation. Two implications follow:
- The protocol war is over. The two most significant agent standards now share governance, backed by AWS, Anthropic, Google, Microsoft, OpenAI, Salesforce, SAP, Cisco, and ServiceNow at the top tiers. If you build multi-agent systems on MCP plus A2A today, you are building on infrastructure governed by 250 organizations, not on one company’s roadmap.
- Lock-in risk drops. You can mix agent frameworks — a LangGraph orchestrator delegating to a CrewAI specialist, or your agent calling a vendor’s agent — and have them coordinate through a neutral spec both sides implement independently.
Nothing breaks for existing implementers; both protocols were already stable. What changes is the strategic calculus, and that is exactly what enterprise buyers were waiting for.
A2A vs MCP: the one-line difference, then the full table
The one-line version: MCP connects agents to tools; A2A connects agents to agents.
| MCP | A2A | |
|---|---|---|
| Direction | Vertical: agent → tools and data | Horizontal: agent → agent |
| Solves | “How does one agent call a database, calendar, or API?” | “How do agents built by different vendors delegate work to each other?” |
| Counterparty | Passive: an MCP server exposes capabilities and waits | Active: the remote agent reasons, negotiates, can ask questions or refuse |
| What stays private | Tool internals are visible to the calling agent | Prompts, memory, and tool chains stay opaque on both sides |
| Origin | Anthropic, November 2024 | Google, April 2025 |
| Stable spec | 2025 | v1.0, March 2026 |
| Governance | Agentic AI Foundation (founding, Dec 2025) | Agentic AI Foundation (joined Aug 2026) |
In practice you use both, in the same system. A scheduling agent inside your product uses MCP to read your calendar service and A2A to accept work from a customer’s procurement agent. One protocol makes an individual agent capable; the other makes a population of agents cooperative.
This is also why the two articles are companions. If you have not read it yet, start with What Is MCP? The Model Context Protocol (“USB-C for AI”) Explained for the vertical half of the story.
Who actually supports A2A in October 2026
Support is the difference between a spec and infrastructure. As of this month:
- Frameworks with native or first-class A2A support: Google’s Agent Development Kit, LangChain/LangGraph (native A2A server and client components), CrewAI, Microsoft’s Agent Framework, Semantic Kernel, LlamaIndex Agents, and AutoGen.
- Cloud platforms: Microsoft integrated A2A into Azure AI Foundry and Copilot Studio; AWS embedded it in Bedrock AgentCore; Google ships it with its agent platform.
- Enterprise software: Salesforce’s Agentforce Third-Party Orchestration is explicitly A2A-based; Deloitte has connected more than 1,000 pre-built industry agents through it.
- Production deployments are reported in financial services, supply chain, and IT operations — the sectors where multi-vendor agent coordination is a daily reality.
The Linux Foundation counts more than 150 supporting organizations, up from 50 at launch. That growth, in eighteen months, is the adoption curve that turned v1.0 into a safe bet.
The honest part: what A2A does NOT guarantee
Every protocol explainer should include this section, and most skip it. A2A is a communication standard, and communication is not the same as trust:
- Transmission ≠trust. Task state is self-reported. If a remote agent says “completed,” the protocol gives you no independent way to verify the work was actually done well. Acceptance testing and result validation remain your job.
- Identity is self-asserted. Agent Cards describe what an agent claims to be. Signed cards (JWS) exist since v0.3, but signing is optional — you decide which cards you trust, and the protocol does not make that decision for you.
- No discovery registry ships with the spec. The protocol defines how agents describe themselves, but there is no built-in trusted directory of agents. Enterprise deployments typically solve this with private registries or allow-lists.
- It does not replace orchestration. A2A moves messages and manages task state between agents. The logic of who should do what, in which order, with which fallbacks — that is your orchestration layer’s job.
None of this is a flaw in the protocol; it is the boundary of what any communication standard can promise. But if a vendor tells you A2A “guarantees” agent reliability or security, that claim goes beyond the spec.
Why Indian developers and IT services teams should care
This is where the protocol story becomes a career story. Three reasons:
- Multi-vendor enterprise projects are the default engagement. India’s IT services firms integrate systems across clients’ vendor stacks. As enterprise clients standardize on A2A for agent interoperability, “can integrate your agents with our A2A network” becomes a deliverable — and a differentiator in RFPs.
- The skill is transferable and framework-agnostic. A2A fluency — Agent Cards, task lifecycles, streaming, auth patterns — applies whether the client runs LangGraph, CrewAI, or a vendor platform. It is closer to learning HTTP in the 1990s than to learning one vendor’s SDK.
- Builders get composability for free. If you are shipping an AI product — a voice agent, a support bot, a workflow automation — exposing an A2A endpoint means any other A2A-compliant agent can delegate work to yours. Distribution through interoperability, not just marketing. (Our guides on building AI agents with n8n and AI voice agents for Indian businesses are good starting points for the agents themselves; A2A is what connects them.)
The realistic timeline: large enterprises adopt first, mid-market follows over the next 12–18 months. Learning the protocol now puts you ahead of the services wave, not chasing it.
How to start with A2A
If you want hands-on, the path is short:
- Read the spec. The official specification lives at a2a-protocol.org — start with the overview and key concepts sections. Version 1.0.0 is the current stable release.
- Browse the reference repo. The Apache 2.0-licensed reference implementation is on GitHub under the a2aproject organization, with SDKs in Python, Go, JavaScript/TypeScript, Java, and .NET.
- Pick a framework with native support. If you already use LangChain, CrewAI, or Google’s ADK, the A2A server and client components are the fastest way to a working prototype.
- Run the minimal version first. Because the protocol is JSON-RPC 2.0 over HTTP, you can stand up a minimal server with any web framework: expose
/.well-known/agent-card.jsonand handle task messages. The SDK handles serialization and lifecycle bookkeeping, but it is not required. - Study MCP alongside. The two protocols are designed to coexist. Read our MCP explainer to understand the vertical half of the stack.
Frequently asked questions
What is the A2A protocol?
A2A (Agent2Agent) is an open standard, launched by Google in April 2025 and hosted by the Linux Foundation, that lets one AI agent discover another agent, delegate a task to it, and collect the result — even when the two agents were built with different frameworks, languages, or vendors. It reached its first stable release, v1.0, in March 2026.
Does A2A replace MCP?
No. MCP (Model Context Protocol) is the vertical layer: it connects a single agent to tools and data sources. A2A is the horizontal layer: it connects agents to other agents. Most production agent products run both. Since August 2026 both protocols share the same neutral home, the Agentic AI Foundation.
Is A2A production-ready?
The spec reached v1.0 in March 2026 and major platforms — Azure AI Foundry, Amazon Bedrock AgentCore, Google’s agent platform — support it natively, with production deployments reported in financial services, supply chain, and IT operations. That said, the protocol standardizes communication, not trust: you still need to decide which agents you accept work from.
What is an Agent Card in A2A?
An Agent Card is a JSON document published at /.well-known/agent-card.json that describes an agent’s identity, capabilities, skills, service endpoint, and authentication requirements. It is how a client agent discovers what a remote agent can do before delegating a task.
Is A2A free to use?
Yes. The specification is an open standard and the reference implementation is Apache 2.0 licensed on GitHub. There are no licensing fees — the cost of A2A is the engineering work to implement it.
Which frameworks support A2A?
Native or first-class support exists in Google’s Agent Development Kit, LangChain/LangGraph, CrewAI, Microsoft’s Agent Framework, Semantic Kernel, LlamaIndex, and AutoGen, plus the cloud platforms Azure AI Foundry, Amazon Bedrock AgentCore, and Salesforce Agentforce.
Sources
- Google Developers Blog — “A2A: A new era of agent interoperability” (April 9, 2025): https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
- Linux Foundation press release — “Linux Foundation launches the Agent2Agent Protocol project” (June 23, 2025): https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
- A2A Protocol official specification (latest released version 1.0.0): https://a2a-protocol.org/latest/specification/
- A2A reference implementation, Apache 2.0 (GitHub): https://github.com/a2aproject/A2A
- PracticalLogix — “The 2026 Agent Interoperability Reset: A2A + MCP under AAIF” (Aug 17, 2026): https://www.practicallogix.com/the-2026-agent-interoperability-reset-a2a-mcp-under-aaif/
- Adamarant — “A2A protocol: how to design an agent API other agents can call” (updated Oct 2026): https://adamarant.com/en/blog/a2a-protocol-how-to-design-an-agent-api-other-agents-can-call
- dev.to / Alex Aslam — “A2A vs. MCP vs. ACP: the protocol war that’s costing your team months of rework” (Oct 2026): http://dev.to/alex_aslam/a2a-vs-mcp-vs-acp-the-protocol-war-thats-costing-your-team-months-of-rework-38ga
- ByteIota — “A2A Joins MCP at the Agentic AI Foundation: What Changes” (Aug 2026): https://byteiota.com/a2a-joins-mcp-at-the-agentic-ai-foundation-what-changes/
- ToolRadar — “MCP vs A2A” (updated Oct 2026): https://toolradar.com/blog/mcp-vs-a2a
AI assistance disclosure: this article was researched and drafted with AI assistance and reviewed against primary sources (the official A2A specification, Google’s announcement, and the Linux Foundation press release). Dates, milestones, and protocol mechanics were verified against those sources in October 2026.