What Is the A2A Protocol? How AI Agents Delegate to Each Other
Google's Agent-to-Agent protocol lets AI agents discover and delegate tasks across product and company boundaries using agent cards.
When AI Agents Need to Talk to Each Other
AI agents are getting better at doing individual tasks. But the interesting problems — the ones that actually matter in business — rarely fit inside a single agent’s scope.
Summarize a document? Easy. But what if solving a problem requires one agent to research a topic, another to draft a legal summary, and a third to schedule follow-up meetings? That requires coordination. And until recently, there was no standard way for agents to hand off work to each other across products, platforms, or company boundaries.
That’s the problem the A2A protocol — short for Agent-to-Agent — is designed to solve. Announced by Google in April 2025, A2A is an open protocol that gives AI agents a common language for discovering each other’s capabilities and delegating tasks. This article breaks down what it is, how it works, and why it matters for anyone building or deploying multi-agent systems.
The Problem A2A Is Solving
Most AI agents today are islands. They’re built inside a specific product, connected to a specific set of tools, and designed to work with a specific user interface. That’s fine for simple use cases, but it creates real friction when you need agents to collaborate.
Imagine a customer service workflow where:
- One agent handles incoming requests and triage
- Another specializes in account lookup and billing systems
- A third generates drafts for escalated cases
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Without a shared protocol, connecting these agents requires custom integration work for every pair — brittle, bespoke glue code that breaks when either agent updates. There’s no standard handshake, no agreed-upon format for describing what an agent can do, and no common way to track whether a delegated task succeeded or failed.
A2A is Google’s answer to this coordination problem. It defines how agents should introduce themselves, how to structure requests and responses, and how to manage the lifecycle of a delegated task — all using existing web standards rather than proprietary infrastructure.
What Is the A2A Protocol?
A2A is an open specification for agent-to-agent communication. It was developed by Google and launched in April 2025 with support from over 50 technology partners, including Atlassian, Salesforce, SAP, Workday, and ServiceNow.
At its core, A2A defines three things:
- How an agent advertises its capabilities — via a structured metadata file called an Agent Card
- How one agent sends work to another — via a standardized task request format
- How tasks are tracked and results returned — via a defined task lifecycle with clear status states
The protocol is built on HTTP, JSON-RPC, and Server-Sent Events (SSE). There are no new standards to learn. If you know how REST APIs work, the mechanics of A2A will feel familiar.
A2A is also explicitly designed to be complementary to Anthropic’s Model Context Protocol (MCP), not a replacement for it. The two protocols solve different problems, which we’ll cover in detail below.
How A2A Works: The Technical Breakdown
Agent Cards
The entry point for any A2A interaction is an Agent Card — a JSON file that lives at a predictable URL path on any A2A-compatible agent’s server: /.well-known/agent.json.
An Agent Card declares:
- The agent’s name and description
- What it can do (its skills and capabilities)
- What input formats it accepts
- What authentication it requires
- Where to send requests
This is how agents discover each other. Instead of requiring a central directory or human configuration, an orchestrating agent can fetch another agent’s card, read what it does, and decide whether to delegate a task to it. It’s closer to how a web browser fetches a robots.txt or sitemap.xml — simple, stateless, and built on existing conventions.
Tasks
Work moves between agents via tasks. A task is a discrete unit of work: a natural language instruction, a structured request, or anything in between.
Every task goes through a defined lifecycle with the following states:
- Submitted — The task has been received
- Working — The agent is processing it
- Input-required — The agent needs more information before it can continue
- Completed — The task finished successfully
- Failed — The task encountered an error
- Canceled — The task was stopped before completion
This lifecycle matters because many real-world tasks take time. An agent might kick off a task, get a “working” status, and check back later — or stream updates in real time using SSE. Either pattern is supported.
Parts and Artifacts
The content of messages in A2A is structured as parts — typed units of content that can be text, files, or structured data. This makes A2A natively multimodal. An agent can send a document alongside a text prompt, or receive an image alongside a JSON result.
When a task is complete, the output is returned as artifacts — the deliverables the delegating agent requested. One task can produce multiple artifacts.
Authentication and Security
A2A supports standard authentication mechanisms, including API keys, OAuth 2.0, and JWT tokens. Agents declare their authentication requirements in their Agent Card, and calling agents are expected to satisfy those requirements before a task will be accepted.
This is important for enterprise use cases where agents from different organizations or security domains need to interact without exposing internal systems.
A2A vs. MCP: What’s the Difference?
This is probably the most common question that comes up when people first encounter A2A.
MCP (Model Context Protocol) defines how an AI agent connects to tools and data sources — file systems, databases, APIs, code interpreters. It’s the protocol for giving an agent access to capabilities it doesn’t have natively. Think of it as how an agent reaches down into tools.
A2A defines how one agent delegates to another agent. It’s the protocol for coordinating work across agents with different specializations. Think of it as how an agent reaches across to peers.
In practice, both protocols can coexist — and often should. An orchestrating agent might use MCP to access a database directly, while using A2A to hand off a specialized analysis task to a domain-expert agent that also uses MCP internally for its own tools.
| Dimension | MCP | A2A |
|---|---|---|
| What it connects | Agents ↔ Tools/Data | Agents ↔ Agents |
| Direction | Agent pulls capabilities | Agent delegates tasks |
| Who developed it | Anthropic | |
| Primary use case | Tool access | Task delegation |
| Communication style | Direct calls | Task-based, async |
The two protocols address different layers of the multi-agent stack. You don’t need to choose between them.
Why Agent Cards Are a Big Deal
The Agent Card concept deserves more attention than it usually gets.
In most current agentic systems, connecting agents requires manual configuration. A developer has to know what Agent B can do, write code to call it correctly, handle errors, and maintain that integration as things change. It’s brittle and doesn’t scale.
Agent Cards make agent capabilities machine-readable and self-describing. An orchestrator can:
- Discover that an agent exists (via a known URL or registry)
- Fetch its Agent Card to understand what it does
- Decide at runtime whether to delegate a task to it
- Send a well-formed task request based on the card’s specifications
This enables dynamic, emergent multi-agent behavior. An orchestrator doesn’t need to be pre-programmed with knowledge of every agent it might work with. It can discover and evaluate agents on the fly — the same way a search engine discovers web pages.
For enterprise environments with dozens of specialized agents running across different systems, this is a meaningful shift. Adding a new specialized agent to the network becomes a matter of deploying it and pointing the orchestrator to its card, rather than modifying integration code everywhere it needs to be accessible.
Real-World Use Cases for A2A
Cross-Platform Customer Support
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
A support orchestrator routes incoming tickets. Simple billing questions go to a billing-specialist agent. Technical issues get delegated to a product-support agent. Escalations requiring legal review go to a compliance-trained agent. Each agent operates in its own domain, and A2A handles the handoffs — including returning results back to the orchestrator once a task completes.
Multi-Step Research Pipelines
A research orchestrator delegates subtasks: one agent searches and summarizes sources, another fact-checks claims, a third formats the final output into a specific template. None of these agents need to know about each other’s internal architecture — they just need to honor the A2A task format.
Enterprise Workflow Automation
In a large organization, you might have agents deployed by different teams, built on different frameworks, running in different cloud environments. A2A gives them a common protocol to delegate work across those boundaries without requiring a central platform to own all the logic.
Human-in-the-Loop Workflows
The input-required task state is specifically designed for situations where an agent needs human input before it can continue. This allows multi-agent pipelines to pause at the right moments and surface decisions to a human, rather than proceeding on assumptions.
Where MindStudio Fits in a Multi-Agent World
MindStudio is a no-code platform for building and deploying AI agents, and it’s worth understanding how platforms like it relate to protocols like A2A.
When you build an agent in MindStudio, you’re defining what it knows, what it can do, and when it runs. The platform handles connections to 1,000+ business tools — Salesforce, HubSpot, Slack, Google Workspace, and more — so your agents can actually act on data, not just process it.
One relevant capability here is MindStudio’s support for agentic MCP servers — which means agents you build in MindStudio can be exposed to other AI systems as callable services. This is exactly the kind of infrastructure that becomes useful as A2A and similar protocols mature: you build specialized agents on MindStudio, expose them via standard protocols, and let orchestrators delegate to them.
For teams that want to build multi-agent workflows today — before A2A tooling is fully mainstream — MindStudio’s visual builder lets you create agents that call other agents, chain workflows, and coordinate across tasks, all without writing infrastructure code. The Agent Skills Plugin (@mindstudio-ai/agent on npm) also lets external agents built with frameworks like LangChain or CrewAI call MindStudio’s capabilities directly as typed method calls.
If you’re building multi-agent systems and want a platform that’s already thinking about agent interoperability, you can try MindStudio free at mindstudio.ai.
The Broader Ecosystem and What’s Next
A2A launched with support from a wide range of enterprise software vendors, which matters more than it might seem at first glance. Protocol adoption lives or dies by network effects. If the agents embedded in Salesforce, ServiceNow, and SAP all speak A2A, enterprises have a strong incentive to build orchestrators that speak it too.
Google has published the A2A specification as an open standard on GitHub, and there’s already community involvement in extending and refining it. The expectation is that A2A will become one of the foundational layers of enterprise AI infrastructure over the next few years — the way REST became foundational for web services.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
That said, A2A is still early. Production tooling is limited, most frameworks don’t yet have first-class A2A support, and the security and governance questions around cross-organization agent delegation are still being worked out. For most teams, the practical play right now is to understand the protocol, experiment with it in lower-stakes contexts, and make sure the agents you’re building today are architected in ways that won’t be painful to integrate later.
Frequently Asked Questions
What does A2A stand for?
A2A stands for Agent-to-Agent. It’s a communication protocol that defines how AI agents discover each other’s capabilities and delegate tasks between themselves, across platform and organizational boundaries.
Who created the A2A protocol?
Google created and published the A2A protocol, announcing it in April 2025. It launched with over 50 technology partners including Atlassian, Salesforce, SAP, Workday, and ServiceNow. The specification is open source and available on GitHub.
What is an Agent Card in A2A?
An Agent Card is a JSON metadata file that an A2A-compatible agent hosts at /.well-known/agent.json. It describes the agent’s name, capabilities, accepted input formats, authentication requirements, and endpoint for receiving tasks. Other agents read Agent Cards to discover what a remote agent can do before deciding whether to delegate work to it.
How is A2A different from MCP?
MCP (Model Context Protocol, developed by Anthropic) defines how an agent connects to tools and data sources. A2A defines how one agent delegates tasks to another agent. They operate at different layers of a multi-agent system and are designed to be complementary — both can be used together in the same architecture.
Is A2A ready for production use?
A2A is a new protocol as of 2025, and production tooling is still maturing. The specification itself is stable and publicly available, and major enterprise vendors have committed to supporting it. For most teams, the right approach now is to experiment, understand the pattern, and design agents with interoperability in mind — rather than treating full A2A integration as a day-one production requirement.
Does A2A support real-time communication?
Yes. A2A supports streaming updates via Server-Sent Events (SSE), which allows a delegating agent to receive live progress updates from a remote agent as a task is being worked on. It also supports a simpler request-response pattern for tasks that complete synchronously.
Key Takeaways
- The A2A protocol gives AI agents a standard way to discover each other’s capabilities and delegate tasks — using existing web standards like HTTP, JSON-RPC, and SSE.
- Agent Cards are the discovery mechanism: machine-readable JSON files that describe what an agent can do, hosted at a known URL path.
- A2A and MCP are complementary protocols — MCP handles tool access, A2A handles agent-to-agent delegation.
- A2A supports both synchronous and streaming task execution, with a well-defined task lifecycle that includes states for async workflows and human-in-the-loop interrupts.
- The protocol launched with broad enterprise support, which improves the odds of real adoption across the industry.
- For teams building multi-agent systems today, designing agents with interoperability in mind — and using platforms like MindStudio that already support agentic protocols — puts you in a stronger position as A2A tooling matures.
If you want to start building agents that are ready for a multi-agent world, MindStudio is a practical starting point — no setup overhead, no infrastructure to manage, and over 200 AI models available out of the box.
