Google’s A2A Protocol Is Building a Common Language for AI Agents
Google marked the first anniversary of the Agent2Agent protocol on June 18, 2026, arguing that AI agents need a shared communication layer if they are to collaborate across companies, frameworks, and software platforms.
The Google Agent2Agent protocol, commonly called A2A, is designed for independently deployed agents that can hold conversations, delegate work, return artifacts, request additional input, and continue operating over long periods.
The protocol does not make agents intelligent, trustworthy, or secure by itself. Its value is narrower but important: it standardizes how one agent discovers and communicates with another without requiring both sides to share the same framework, model, memory system, or internal tools.
What Is the Google Agent2Agent Protocol?
A2A is an open protocol for communication between agentic applications.
Traditional APIs usually expose fixed operations: submit these parameters and receive a predictable response. Agents may behave less deterministically. They can negotiate a task, ask for clarification, produce incremental work, pause for authorization, and return different artifacts depending on context.
A2A provides common objects and lifecycle rules for those interactions.
Its architecture centers on:
- Agent discovery
- Capability descriptions
- Messages and structured content
- Tasks with persistent state
- Artifacts produced during work
- Streaming and asynchronous updates
- Authentication and authorization boundaries
- Extensions for specialized behavior
The official project describes A2A as framework-independent. An agent could be built with Google ADK, LangGraph, Semantic Kernel, CrewAI, or custom infrastructure and still communicate through the same protocol boundary.
Agent Discovery Starts With an Agent Card
An A2A agent publishes an Agent Card.
This machine-readable document tells clients what the agent claims to do and how to contact it. Depending on the implementation, it can describe:
- Agent name and description
- Network endpoint
- Supported skills
- Input and output formats
- Streaming support
- Push-notification support
- Authentication schemes
- Protocol bindings
- Optional extensions
A client can inspect the card before deciding whether the remote agent is relevant to a task.
For example, a procurement agent might discover that another service can assess supplier risk, accepts structured company records, supports asynchronous tasks, and returns a report artifact.
The Agent Card is similar to a service description, but it is oriented around agent capabilities rather than a fixed list of functions.
It is also important not to overstate what the card provides. A capability claim is not a security certification. Enterprises still need trusted registries, allowlists, identity validation, policy checks, and contract-level governance before delegating sensitive work.
How Task Delegation Works
In a typical A2A exchange, one agent acts as the client and another as the remote agent.
The client sends a message describing the requested outcome. The receiving agent may respond immediately with a message or create a persistent task.
A task is useful when work:
- Takes more than one request-response cycle
- Produces intermediate artifacts
- Requires clarification
- Waits for external systems
- Needs human approval
- May be canceled or resumed
- Must remain queryable after the original connection closes
The client does not need to know the remote agent’s internal chain of thought, model, database, or tools. It interacts through the task boundary and receives status changes and artifacts.
That opacity helps teams preserve implementation independence and intellectual property. It can also reduce unnecessary context sharing between agents.
The A2A Task Lifecycle
A simplified workflow looks like this:
Agent discovery
↓
Read and validate Agent Card
↓
Authenticate and authorize
↓
Send task message
↓
Remote agent accepts or rejects work
↓
Submitted → Working
↓
Optional input or authorization request
↓
Status and artifact updates
↓
Completed, Failed, Canceled, or Rejected
The current specification supports terminal states including completed, failed, canceled, and rejected. It also supports situations where a task requires additional input or authorization before continuing.
This is one of the major differences between A2A and a basic REST endpoint. The protocol models the work as a stateful interaction, not merely one HTTP response.
Long-Running Operations and Streaming
Many useful agent jobs do not finish quickly.
An agent might conduct research, run simulations, generate a report, wait for approval, or coordinate with additional agents. A2A supports these patterns through several mechanisms.
Streaming
A client can open a streaming connection and receive task status or artifact updates as work progresses.
The specification supports streams that begin with a Task and continue with status or artifact events until the task reaches a terminal state.
Polling
A disconnected client can later request the current task state and retrieve artifacts or history.
Resubscription
A client can subscribe to updates for an already active task rather than restarting the work.
Push notifications
Where supported, a remote agent can send webhook notifications when a task changes, allowing the original client to disconnect while the work continues.
The protocol documentation also describes Server-Sent Events for real-time updates and requires agents to advertise whether streaming is supported in their Agent Card.
Messages, Parts, and Artifacts
A2A does not limit agents to plain text.
Messages can contain structured parts such as text, data, URLs, or files, depending on the protocol binding and negotiated capabilities. Results can be returned as artifacts.
An artifact might be:
- A generated report
- A dataset
- A code patch
- An image
- A compliance decision
- A structured plan
- A machine-readable transaction record
This matters because real agent collaboration often produces durable outputs rather than chat responses.
A research agent may return a report plus citations. A coding agent may return a patch and test logs. A logistics agent may return a route plan and exception list.
A2A vs MCP vs APIs vs Orchestrators
These technologies solve different problems.
| Technology | Primary role | Best suited for |
| A2A | Agent-to-agent communication | Delegation between independently deployed agentic services |
| MCP | Agent-to-tool and data access | Connecting models to files, databases, APIs, and utilities |
| REST/gRPC API | Deterministic service interface | Stable functions with known request and response contracts |
| Workflow orchestrator | Controls execution order and policy | Explicit business processes, retries, scheduling, and approvals |
| Agent framework | Builds internal agent behavior | Reasoning, memory, tools, planning, and model integration |
A2A and MCP are complementary.
An A2A-connected travel agent might delegate payment verification to another agent. That remote agent could use MCP to query an internal database or payment tool.
An orchestrator may still decide which agent is allowed to run, enforce deadlines, record approvals, and manage compensation if part of a workflow fails.
Normal APIs also remain useful. A deterministic currency-conversion service does not become more valuable merely because it is wrapped as an autonomous agent.
The official A2A project explicitly positions MCP as the tool-access layer and A2A as the communication layer between agents.
Why A2A Does Not Replace Workflow Orchestration
Agent delegation introduces uncertainty.
A remote agent may:
- Ask for more information
- Take longer than expected
- Return a partial artifact
- Reject the task
- Require authorization
- Choose a different strategy
- Consume more resources than planned
A workflow orchestrator provides deterministic control around those possibilities.
It can define:
- Which agents may be called
- Budget and time limits
- Retry policies
- Human approval gates
- Escalation rules
- Audit logging
- Rollback or compensation logic
A2A standardizes the conversation. It does not replace operational governance.
Security Boundaries Matter More Than Connectivity
Interoperability can expand the attack surface.
An agent receiving a task from another agent must treat the request as untrusted input. The sender could be compromised, misconfigured, or manipulated through prompt injection.
A secure implementation needs:
- Strong service identity
- Mutual authentication where appropriate
- Least-privilege authorization
- Capability allowlists
- Task-level access controls
- Input and artifact validation
- Data-loss-prevention checks
- Network segmentation
- Rate and budget limits
- Signed logs and traceability
- Human approval for high-impact actions
The specification requires authorization scoping so clients only access tasks they are permitted to see. It also supports authorization-required task states for work that cannot continue without additional permission.
Agent opacity is not a complete security feature. Hiding internal tools reduces coupling, but the consuming organization may still need evidence about data handling, model behavior, retention, and downstream dependencies.
Governance and Ecosystem Development
Google introduced A2A in 2025 and later transferred the specification, SDKs, and tooling to a Linux Foundation project.
Founding participants included Google, AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. Google reported support from more than 100 companies at the time of the transfer.
Neutral governance matters because an interoperability standard is less useful when controlled solely by one vendor.
The project now publishes official SDKs for languages including Python, JavaScript, Java, Go, .NET, and Rust.
This is meaningful ecosystem progress, but support does not guarantee identical implementation quality across every framework or vendor.
Benchmark and Evidence Audit
A2A is a protocol release, not a performance benchmark.
| Evaluation question | Published evidence |
| Cross-framework communication | Demonstrated through SDKs and samples |
| Agent discovery | Defined through Agent Cards |
| Long-running tasks | Supported by task lifecycle, polling, streaming, and notifications |
| Security guarantees | Not provided automatically; implementation-dependent |
| Latency overhead | No universal benchmark disclosed |
| Reliability across vendors | No broad independent benchmark disclosed |
| Cost reduction | Not established |
| Production failure rate | Not established |
| Semantic compatibility | Not guaranteed by the wire protocol |
| Vendor-neutral governance | Linux Foundation project |
The protocol defines how systems exchange information, but it does not prove that the agents understand the task in the same way.
Two agents may both support a “supplier risk” skill while using different definitions, evidence standards, or scoring methods.
When A2A Is Worth Using
A2A is a strong fit when:
- Agents belong to different organizations or platforms
- Services are independently deployed
- Tasks are conversational or long-running
- Results include artifacts and intermediate updates
- The remote agent needs implementation autonomy
- Framework independence matters
- Capability discovery is useful
A normal API or internal function is usually better when:
- The operation is simple and deterministic
- Low latency is critical
- Components share the same process or memory
- There is no need for task negotiation
- A typed request-response contract is sufficient
- Agent behavior would add unnecessary uncertainty
Google’s ADK guidance similarly warns that A2A can be counterproductive for tightly coupled, performance-critical operations or simple helper functions.
Why This Matters
Enterprises are unlikely to run one universal agent.
They will use specialized agents for procurement, coding, research, customer service, compliance, analytics, and operations. Many will come from different vendors.
Without interoperability, each connection becomes a custom integration.
A2A aims to create a reusable boundary where agents can advertise capabilities and exchange work without exposing their entire internal design.
The long-term opportunity is an ecosystem where organizations can replace or add agents without rebuilding every workflow.
The corresponding risk is an agent mesh that becomes difficult to govern. Discovery, delegation, authorization, observability, and cost control must develop alongside interoperability.
Simple Explanation for Beginners
Imagine several specialist companies.
One plans travel. One handles payments. One checks identity. One arranges insurance.
A2A gives them a common form for saying:
- Here is what I can do.
- Here is the task.
- I need more information.
- The work is still running.
- Here is the finished result.
MCP gives each company access to its own tools. APIs perform fixed operations. An orchestrator decides which steps happen and under what rules.
Conclusion: Google Agent2Agent Protocol
The Google Agent2Agent protocol is becoming an important architectural layer for multi-agent systems.
Its core contribution is not intelligence. It is a shared model for discovery, task delegation, long-running work, streaming updates, artifacts, and cross-framework communication.
A2A is most useful when agents are independently deployed and genuinely need autonomy. It is unnecessary when a fixed API or normal workflow provides a simpler solution.
The protocol’s success will depend on more than adoption numbers. Identity, authorization, semantic consistency, observability, cost control, and reliable cross-vendor testing will determine whether an interoperable agent ecosystem is also a manageable one.
Final Takeaways
- Google published A2A’s first-anniversary update on June 18, 2026.
- A2A standardizes communication between independently deployed agents.
- Agent Cards advertise skills, endpoints, formats, and capabilities.
- Tasks support state, artifacts, cancellation, clarification, and authorization pauses.
- A2A supports streaming, polling, resubscription, and push notifications.
- MCP connects agents to tools; A2A connects agents to other agents.
- APIs remain better for simple deterministic services.
- Workflow orchestrators still manage policy, sequencing, retries, and approvals.
- Linux Foundation governance reduces dependence on one vendor.
- Agent Cards describe capabilities but do not establish trust.
- No universal latency, cost, or cross-vendor reliability benchmark has been published.
Suggested Read:
- LoRA Alternatives PEFT Benchmark: Which Methods Perform Better?
- GPT-5.5 Health Intelligence: What OpenAI’s Evaluations Show
- Google ADK Guide
- How AI Agents Work
- Latest Google AI News
FAQ: Google Agent2Agent Protocol
What is the Google Agent2Agent protocol?
It is an open protocol for discovering, communicating with, and delegating work to independently built AI agents across frameworks and vendors.
How do A2A Agent Cards work?
An Agent Card advertises an agent’s endpoint, skills, supported formats, capabilities, and authentication information so clients can decide whether and how to connect.
What is the difference between A2A and MCP?
A2A supports agent-to-agent collaboration. MCP gives agents access to tools, data sources, and external resources. The two protocols can be used together.
Does A2A replace APIs?
No. Fixed APIs remain better for deterministic operations. A2A is useful when the remote service behaves like an autonomous, stateful agent.
How does A2A handle long-running tasks?
It provides persistent task states, streaming updates, polling, task subscription, cancellation, artifacts, and optional push notifications.
Is the A2A protocol secure?
It supports security-related metadata and authorization patterns, but deployments must still implement identity, access control, data validation, logging, and policy enforcement.
References: