What Is Agent-to-Agent Protocol? A2A Explained

The first generation of enterprise agents worked alone. The second generation is being asked to work together: a customer-service agent hands a billing question to a finance agent, a procurement agent asks a supplier's agent for a quote, an orchestrator delegates subtasks to specialists built by different teams. Agent-to-agent (A2A) protocols exist to make that collaboration possible without bespoke integration for every pair. This explainer covers what the protocol does, how it relates to Model Context Protocol, and the posture enterprises should take. It sits alongside what is Model Context Protocol and the strategic view in the agent interoperability standards whitepaper.

What is an agent-to-agent protocol?

An agent-to-agent protocol is an open standard that defines how one agent discovers what another agent can do, delegates a task to it, exchanges messages and artifacts during the task, and learns when the task is complete or has failed. The best-known proposal is the Agent2Agent protocol announced by Google in April 2025 with broad industry backing and later contributed to the Linux Foundation for neutral governance. Other proposals exist, and the ecosystem is still converging.

What are the core concepts?

Concept	What it is	Enterprise analogy
Capability description	A published description of what an agent can do and how to reach it	A service catalog entry
Task	A unit of delegated work with a lifecycle: submitted, working, needs input, completed, failed	A ticket
Message	Communication between agents during a task, including requests for clarification	Ticket comments
Artifact	An output produced by the task, such as a document or structured result	Ticket attachment
Client and remote agent	The agent that delegates and the agent that performs	Requester and assignee

The design treats delegation as a task with state rather than a single request and response, which fits long-running work and human-in-the-loop pauses.

How does A2A relate to MCP?

Layer	Question	Protocol
Agent-to-tool	How does an agent reach systems and data?	Model Context Protocol
Agent-to-agent	How does an agent delegate to another agent?	A2A and similar protocols

An agent handling a customer request might use MCP to read the order system and A2A to delegate a refund decision to a finance agent that another team operates. The layers are complementary; the widely repeated framing is that MCP gives agents tools and A2A gives agents colleagues. The comparison of tool-layer options is in MCP vs API integration.

When does an enterprise need it?

• Cross-vendor delegation: agents from different platforms inside the enterprise must hand work to each other.
• Cross-organization delegation: your agent must interact with a partner's or supplier's agent.
• Decoupled teams: business units run their own agents and want a standard way to collaborate without a central orchestrator.

When all agents run inside one orchestrator, an internal contract is simpler, faster, and easier to secure. Orchestration patterns that need no external protocol are described in the multi-agent orchestration patterns whitepaper.

What about security?

The protocol defines discovery and messaging, not trust. Enterprises must supply:

• Agent identity for every agent that delegates or performs, per the agent identity and access control whitepaper.
• Authorization for which agents may delegate which tasks to which agents, with delegated authority never exceeding the task's needs.
• Boundary controls for cross-organization delegation: authentication, contracts, data-handling terms, and rate limits.
• Audit of every task with both agents' identities, the delegating user where relevant, and the artifacts exchanged.
• Injection awareness: messages and artifacts from another agent are untrusted content, exactly like tool results.

What posture should enterprises take?

1. Keep an internal registry of agent capabilities and permissions as the source of truth, regardless of protocol.
2. Use internal orchestration where all agents share a platform.
3. Adopt an A2A protocol behind an adapter only where cross-vendor or cross-organization delegation is a real requirement, choosing the protocol with the broadest backing.
4. Apply identity, authorization, and audit at the boundary before any external agent can delegate to yours or vice versa.
5. Pin versions and treat protocol libraries as managed dependencies.

What are the common misconceptions?

1. "A2A replaces MCP." They are different layers.
2. "Every multi-agent system needs it." Most run fine inside one orchestrator.
3. "The protocol handles trust." It does not; you do.
4. "It is settled." Adoption is broad, but the ecosystem is still converging; keep the choice reversible.

How does FISTA Solutions help?

FISTA Solutions designs multi-agent systems and interoperability layers as part of its AI enablement practice: internal orchestration contracts, agent registries, and adapters for external protocols where delegation across vendors is required, with identity and audit at every boundary. Every AI agent FISTA delivers is registered and permissioned so it can collaborate safely. Our forward deployed engineers build the first delegations with your teams. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To assess whether your agents need a delegation protocol, message FISTA on WhatsApp, or read multi-agent systems explained first.