What Is the A2A Protocol and Why AI Agents Need a Common Language

AI agents are moving from demos to production, but most still talk only to their host application. One agent built with LangGraph cannot easily delegate work to another running on a different cloud, written in another framework, or owned by another team. That fragmentation is the problem the Agent2Agent (A2A) protocol targets.

A2A is an open standard, introduced by Google and contributed to the Linux Foundation, that defines how agents advertise capabilities, exchange tasks, and stream results over HTTP. If MCP (Model Context Protocol) connects agents to tools and data, A2A connects agents to each other.

The interoperability gap

Today's agent stacks share a pattern: an orchestrator calls an LLM, invokes tools, and loops until a task completes. Each framework—LangChain, CrewAI, custom Python services—implements that loop differently. When two products need to collaborate, teams fall back to bespoke REST APIs or brittle prompt handoffs.

That works for one integration. It does not scale when you want:

• A sales agent to hand qualified leads to a support agent on another platform
• A coding agent to request a security review from a specialized auditor agent
• Enterprise buyers to mix agents from multiple vendors under one workflow

A2A proposes a shared contract so agents can discover each other and negotiate work without custom glue code for every pair.

Core concepts

Agent Cards

An agent publishes an Agent Card—a JSON document describing its identity, endpoint URL, supported input modes (text, files, structured data), authentication requirements, and skills. Clients fetch the card before sending work, similar to reading an OpenAPI spec.

Tasks and messages

Work flows as tasks. A client creates a task, sends messages with user or agent input, and receives responses that may include partial progress, artifacts (files, code snippets), or final answers. Tasks have explicit states: submitted, working, completed, failed, and others defined by the protocol.

Streaming

Long-running agent work benefits from streaming updates. A2A supports server-sent style delivery so UIs and orchestrators can show intermediate reasoning, tool calls, or draft outputs without waiting for the full run to finish.

How A2A relates to MCP

These protocols are complementary, not competing.

A practical stack might use MCP so your agent can query Postgres, and A2A so the same agent can delegate a research subtask to a partner's agent.

A simplified interaction flow

1. Discovery — Client reads https://agent.example.com/.well-known/agent.json (Agent Card).
2. Authentication — Client obtains credentials if required (OAuth, API keys per card metadata).
3. Task creation — Client POSTs a task with the user goal and context.
4. Message exchange — Client and agent send messages; agent may call its own tools internally.
5. Completion — Agent marks the task complete and returns artifacts.

The wire format uses JSON-RPC style messages over HTTPS, which keeps debugging familiar for backend engineers.

Example: delegating a subtask

Imagine a project-management agent that receives: "Draft a launch checklist for our mobile app." It recognizes that a compliance review is needed and discovers a legal-review agent via its Agent Card.

User → PM Agent: "Draft launch checklist"
PM Agent → Legal Agent (A2A): task "Review checklist for GDPR gaps"
Legal Agent → PM Agent: artifact with flagged items
PM Agent → User: merged checklist with compliance notes

Without A2A, the PM team would hard-code an HTTP integration to the legal vendor. With A2A, any compliant agent can participate as long as it exposes a card.

Security considerations

Agent-to-agent trust is harder than tool access inside one app.

• Authenticate every hop. Agent Cards should declare required auth; never accept anonymous tasks for sensitive skills.
• Scope tasks narrowly. Pass the minimum context—avoid shipping full customer databases when a summary suffices.
• Log and audit. Multi-agent chains need trace IDs across tasks the same way microservices need distributed tracing.
• Validate artifacts. Treat returned files and code as untrusted input before executing or displaying them.

When you actually need A2A

You probably do not need A2A on day one if a single agent with MCP tools solves the problem inside one codebase.

Consider A2A when:

• Multiple teams ship agents that must collaborate without shared deployment
• You sell an agent platform and customers bring their own agents
• Workflows span organizational boundaries (vendor, client, partner)
• You want a marketplace model where agents advertise skills dynamically

Stay with internal function calls when latency, simplicity, and a unified security boundary matter more than cross-vendor interoperability.

Implementation landscape

Google published the specification and sample implementations; ecosystem support is still maturing. Early adopters typically:

1. Expose an Agent Card from an existing agent service.
2. Implement task/message endpoints behind their current orchestrator.
3. Use A2A only at integration boundaries while keeping internal tool loops unchanged.

Framework maintainers are adding adapters so LangGraph, Google ADK, and others can speak A2A without rewriting core logic.

Design lessons for builders

Even if you adopt A2A later, its model suggests good habits now:

• Publish clear capability boundaries instead of monolithic "do everything" agents.
• Prefer structured task inputs over giant free-text prompts when handing off work.
• Stream progress so downstream agents and humans can intervene early.
• Version your agent's skills in the Agent Card when behavior changes.

FAQ

Is A2A only for Google Cloud? No. It is an open protocol. Google originated it, but the goal is cross-platform agent communication.

Does A2A replace REST APIs? It standardizes agent-specific semantics (tasks, skills, streaming). Generic CRUD APIs remain appropriate for non-agent resources.

How is this different from calling another LLM API? A2A assumes autonomous agents with skills, stateful tasks, and artifacts—not single prompt/response pairs.

Should I wait for wider adoption? If your roadmap includes multi-vendor agent workflows in the next year, prototyping an Agent Card now de-risks integration. Otherwise, monitor the spec and focus on solid single-agent architecture first.