Agent2Agent (A2A)

Agent2Agent is the agent-to-agent interoperability layer: MCP exposes tools to an agent; A2A lets independent agents discover capabilities, negotiate modalities, and coordinate tasks without sharing private state. Source: A2A protocol specification, https://a2a-protocol.org/latest/specification/, 2026-06-17

A2A is useful when the unit of delegation is an agent, not a tool call. The protocol frames remote agents as opaque systems with discoverable capabilities, supported input/output modalities, task state, and security boundaries. That makes it a coordination primitive for cross-vendor or cross-org agents where direct access to memory, tools, or chain-of-thought should stay private.

The wiki should treat A2A as complementary to MCP as the Integration Standard, not as a replacement. Use MCP when Kevin needs an agent to call a tool, database, browser, service API, or local capability. Use A2A when Kevin needs one agent system to delegate work to another agent system and preserve each side's autonomy.

In Kevin's ideation stack, A2A pairs with Services-as-Software: A2A is how specialized agents communicate; services-as-software is the business lens for what those agents sell, namely outcomes rather than dashboards.

Routing Rules

Need Prefer
Call a tool or service from one agent MCP as the Integration Standard
Coordinate two independent agent systems A2A
Build a typed agent harness inside one app Tool-Calling Design and app-native APIs
Delegate a business outcome across vendors A2A plus Services-as-Software

Protocol boundary

A2A is for agent-to-agent delegation, not ordinary function calls. That distinction matters:

Layer Unit of work What remains private
Function/tool call one action with schema tool internals
MCP server resources, prompts, and tools exposed to one agent server implementation
A2A agent task handled by another autonomous agent remote agent memory, tools, chain-of-thought, internal policy

The protocol's value is that each side can remain opaque while still advertising capabilities, input/output modalities, task state, and security requirements. In Agent Capability Registry terms, a remote agent becomes a governed capability.

Product implications

A2A needs control-plane support, not just SDK support:

  • identity for the calling and called agent,
  • capability discovery and trust metadata,
  • task status and cancellation,
  • auth and billing boundaries,
  • artifact exchange,
  • audit logs for both sides,
  • fallback when the remote agent refuses or fails.

This is the remote-agent version of Agent Product Surface: the user should know which agent owns the task, what authority it has, and what evidence came back.

Concept Position

Field Value
Concept family Agent harness and runtime primitives
Concept owned Agent2Agent is the agent-to-agent interoperability layer: MCP exposes tools to an agent; A2A lets independent agents discover capabilities,...
Category map Concept System Map

Timeline