What Is A2A: How Different Agents Discover, Communicate, and Collaborate

A2A stands for Agent2Agent Protocol.

It is not about how a model calls tools. It is about how different agents discover each other, exchange messages, and collaborate on tasks.

As organizations begin deploying multiple agents internally, a practical problem quickly appears: a sales agent, support agent, finance agent, legal agent, and engineering agent may come from different teams, vendors, and frameworks. They cannot only operate inside their own systems. They also need to delegate work, pass context, and return results to one another.

A2A is designed for exactly this kind of agent interoperability.

Core Takeaway

The value of A2A is not in a single agent. It appears when you have a multi-agent ecosystem.

When there is only one agent in the system, A2A is not very important. One agent can call tools, read data, and execute tasks through MCP or regular tool calling.

But once an organization has multiple agents, the questions change:

• How do you know what an agent can do?
• How do you hand a task to another agent?
• How do you get task status?
• How do you handle long-running tasks?
• How do you exchange text, files, structured data, and other result types?
• How do agents collaborate across frameworks and vendors?

A2A’s role is to provide an open protocol so these agents can interoperate in a unified way.

What A2A Solves

1. Agent Capability Discovery

A2A introduces the concept of an Agent Card.

An Agent Card is like a capability profile for an agent. It describes what the agent can do, how to connect to it, and which interaction modes it supports.

This matters. Without capability discovery, a multi-agent system has to rely on hardcoded routing:

If it is an expense question, call the finance agent
If it is a contract question, call the legal agent
If it is a customer question, call the CRM agent

Hardcoding works in small systems, but it becomes unmanageable at scale.

The purpose of an Agent Card is to make agents discoverable, understandable, and selectable.

2. Standard Communication Between Agents

A2A builds on existing standards such as HTTP(S), JSON-RPC, and SSE. The goal is to reduce integration cost.

It provides a common communication pattern so one agent can send another agent tasks, messages, context, and user instructions.

This is more maintainable than building a separate API between every pair of agents.

3. Long-Running Tasks

Many enterprise tasks cannot be finished in a single request.

For example:

• A recruiting agent searches for candidates and schedules interviews.
• A procurement agent gathers quotes, compares vendors, and waits for approval.
• A legal agent reviews a contract and waits for business confirmation.
• A data analysis agent pulls data, runs analysis, and generates a report.
• An engineering agent modifies code, runs tests, and waits for review.

These tasks may last minutes, hours, or even days.

A2A treats tasks as first-class objects. It supports task lifecycles, status updates, real-time feedback, and final artifact output.

4. Multimodal and Diverse Outputs

Agent collaboration is not limited to text.

Agents may exchange:

• Files.
• Tables.
• JSON.
• Images.
• Audio.
• Video.
• Forms.
• Embeddable UI.

A2A is designed to be modality agnostic, so agent collaboration is not constrained to plain text.

Basic Structure of A2A

A simplified A2A flow looks like this:

Client Agent
  ↓
Discover the Remote Agent's Agent Card
  ↓
Create a Task
  ↓
Exchange Message / Part
  ↓
Receive status updates
  ↓
Obtain Artifact

Key concepts:

In engineering terms, A2A is closer to a task collaboration protocol between agents than a simple chat protocol.

A2A vs. MCP

The relationship between A2A and MCP can be summarized like this:

MCP: agent to tools
A2A: agent to agent

More specifically:

They are not competitors.

In real systems, a common combination looks like this:

User asks the sales agent
  ↓ A2A
Sales agent delegates payment verification to the finance agent
  ↓ MCP
Finance agent queries ERP / invoice systems
  ↓ A2A
Finance agent returns the result to the sales agent

A2A handles collaboration between agents. MCP handles how each agent accesses its own tools and context.

Typical Scenarios

1. Cross-Department Enterprise Collaboration

An enterprise may have many vertical agents:

• HR Agent.
• Finance Agent.
• Legal Agent.
• IT Agent.
• Sales Agent.
• Support Agent.
• Data Analysis Agent.

User requests often cross departmental boundaries.

For example:

Confirm whether this customer can enter enterprise contract approval, and schedule a demo next week.

This may involve:

• The sales agent checking customer status.
• The finance agent checking payment and credit.
• The legal agent reviewing contract templates.
• The scheduling agent arranging a meeting.

A2A lets these agents collaborate without forcing everything into one giant “universal agent.” Each agent can keep a clear professional boundary while cooperating through a protocol.

2. Complex Business Process Automation

Enterprise workflows are rarely single-system operations.

For example, procurement:

Submit request -> search suppliers -> collect quotes -> compare prices -> compliance check -> approval -> place order

Each step may be handled by a different agent or system.

A2A lets agents in the process collaborate through tasks and status, instead of relying on brittle point-to-point scripts.

3. Interoperability Across Agent Frameworks

Different teams may use different agent frameworks:

• LangGraph.
• CrewAI.
• AutoGen.
• Google ADK.
• Internal agent runtimes.
• Cloud vendor agent platforms.

Without a protocol, every framework pair needs an adapter.

A2A aims to let agents communicate through a common protocol even when their internal implementations differ.

4. Long-Running Tasks

Long-running work is a major A2A scenario.

Examples include:

• Deep research.
• Recruiting screening.
• Code migration.
• Contract review.
• Data report generation.
• Customer ticket handling.

These tasks need status updates, intermediate feedback, human intervention, and final deliverables. A2A’s task lifecycle fits this kind of work better than a single request-response call.

Engineering Value of A2A

1. Avoiding the “Super Agent”

Without A2A, teams often try to put every capability into one agent.

That creates several problems:

• Prompts grow longer and longer.
• Tool permissions become broader.
• Responsibility boundaries become unclear.
• Debugging becomes harder.
• Security risks concentrate in one place.
• Different business capabilities become difficult to evolve independently.

A2A offers another architecture: multiple specialized agents collaborate.

Each agent owns its domain and works with others through a protocol.

2. Reducing Integration Cost

Without a common protocol, integration between agents becomes mesh complexity.

Sales Agent connects to Finance Agent
Sales Agent connects to Legal Agent
Support Agent connects to Finance Agent
Support Agent connects to Ticketing Agent
Legal Agent connects to Contract Agent

Every pair needs agreements on APIs, authentication, state, and error handling.

A2A’s value is to standardize these agreements.

3. Supporting Enterprise Governance

Enterprises care not only whether agents can collaborate, but also:

• Who called whom?
• What task was requested?
• What data was passed?
• Was the caller authorized?
• Did the task finish?
• Is the result traceable?
• Where did a human intervene?

When combined with identity, logging, auditing, and permission systems, A2A can become part of enterprise multi-agent governance.

The Boundaries of A2A

A2A is not magic that automatically makes agents reliable.

It does not directly solve:

• The reasoning quality of a single agent.
• Tool calling safety.
• Data permissions.
• Business approvals.
• Hallucinations.
• Factual verification.
• Whether an agent should accept a task.

A2A only defines how agents communicate and collaborate. Each agent’s capabilities, permissions, constraints, and safety policy still need to be designed by the business system.

One misconception is especially important to avoid:

Just because agents can call each other does not mean they should.

In enterprise deployments, collaboration relationships between agents must have boundaries.

Security and Governance

A2A targets enterprise interoperability, so security cannot live only at the model layer.

You need to consider:

• Agent identity authentication.
• Caller authorization.
• Task permission scope.
• Minimal data transfer.
• Human confirmation points.
• Audit logs.
• Task cancellation and rollback.
• Output confidence labels.
• Cross-system data compliance.

A safer design is to classify agent calls:

The real problem in multi-agent systems is not “can they connect?” It is “how do we keep the system under control after they connect?”

When You Need A2A

A2A is suitable when:

• Your organization has multiple specialized agents.
• Agents come from different teams or vendors.
• You need cross-system collaboration.
• Tasks can run for a long time.
• You need task status and artifacts.
• You need a unified way to discover and invoke agents.
• You need enterprise-grade auditing and governance.

A2A is probably unnecessary when:

• You only have one agent.
• The agent only calls tools.
• Tasks are short, and a normal API is enough.
• Agents do not need to interoperate.
• The system is still an early prototype.

Early projects do not need A2A just for architectural completeness.

A2A becomes valuable when the system evolves from “one agent with many tools” to “many agents across many systems.”

Relationship to Existing Workflow Systems

A2A is not a workflow engine.

Workflow engines care about:

• Step orchestration.
• Conditional branches.
• State machines.
• Retries.
• Approvals.
• SLAs.

A2A cares about:

• Agent discovery.
• Agent communication.
• Task delegation.
• Status synchronization.
• Artifact return.

They can be combined.

For example:

Workflow engine decides the next step
A2A calls the corresponding agent
MCP lets that agent access tools

In enterprise systems, this layering is more reasonable:

Workflow: manages process
A2A: manages agent collaboration
MCP: manages tools and context
LLM: manages reasoning and generation

Conclusion

A2A is a protocol to watch once agent engineering moves into the multi-agent stage.

Its core questions are:

• How are agents discovered?
• How do agents communicate?
• How do agents delegate and track tasks?
• How do agents exchange results and artifacts?
• How do agents collaborate across frameworks and vendors?

If MCP is the tool interface that lets agents connect to the external world, A2A is closer to the collaboration interface between agents.

For enterprise deployment, A2A’s value is not “letting agents chat with each other.” Its value is helping specialized agents collaborate on real business tasks within clear boundaries.

More precisely:

A2A is not the whole architecture for multi-agent systems, but it may become a key protocol layer for multi-agent interoperability.

References:

• Announcing the Agent2Agent Protocol
• A2A GitHub Project
• A2A Protocol Technical Documentation
• Google Gemini Enterprise: Register and manage an A2A agent