A2A (Agent2Agent) Protocol

Executive Summary

The Agent2Agent (A2A) protocol represents a significant shift in AI agent architecture, moving from isolated tool-based systems to an open, interoperable ecosystem. Announced by Google Cloud in April 2025 and subsequently donated to the Linux Foundation, A2A is supported by over 150 organizations. Unlike framework-specific solutions, A2A functions as a vendor-neutral interoperability layer that standardizes how agents discover each other and collaborate across system boundaries.

The critical takeaway for engineers and architects is the transition from a “tool-invocation” mental model to a “peer-collaboration” model. The protocol’s “beating heart” is the Task lifecycle, specifically the input-required state, which allows agents to pause execution and request further information from clients or other agents. This asynchronous, stateful negotiation differentiates A2A from the Model Context Protocol (MCP), which focuses primarily on standardizing tool access.

The Evolution and Strategic Positioning of A2A

A2A has rapidly moved from a conceptual framework to a standardized protocol integrated into major AI ecosystems.

• Origins and Governance: Launched in April 2025 by Google Cloud, the protocol was transferred to the Linux Foundation to ensure open governance and broad industry adoption.

• Industry Support: Coordination between major players is evident in the merger of A2A narratives with IBM’s Agent Communication Protocol (ACP) and its integration into frameworks like IBM’s BeeAI.

• Educational Momentum: The protocol is now a central component of industry training, including specific courses from DeepLearning.AI that frame A2A as the standard for cross-framework communication.

A2A vs. MCP: Complementary Roles

While both protocols enhance agent capabilities, they serve distinct architectural purposes:

Feature

MCP (Model Context Protocol)

A2A (Agent2Agent Protocol)

Primary Focus

Tool access and data retrieval.

Inter-agent discovery and collaboration.

Mental Model

Agent calling a stateless-ish tool server.

Peer-to-peer negotiation between stateful agents.

Control Flow

Orchestrator-driven.

Distributed; remote agents have their own control flow.

Interaction

Request/Response.

Task-based with lifecycle states (async).

Core Primitives of the A2A v0.3 Specification

The A2A protocol is built on five fundamental primitives, as defined in the v0.3 specification and implemented in the official Python SDK.

• AgentCard: A self-describing manifest located at a well-known path (/.well-known/agent-card.json). It contains the agent’s name, description, protocol version, preferred transport, supported modalities, and specific skills/capabilities.

• Message: The basic conversational unit consisting of a role and multiple parts.

• Part: A discriminated content model capable of carrying text, files, or structured data.

• Artifact: The final or intermediate “deliverable” produced by an agent, which can be passed to subsequent agents in a workflow.

• Task: The primary unit of work. It maintains a persistent state, history, and associated artifacts throughout its lifecycle.

The Task Lifecycle and State Machine

Understanding A2A requires mastering the Task lifecycle. Unlike a standard API call that either succeeds or fails, an A2A task is a multi-state process.

Lifecycle States

1. Submitted: The task has been received by the remote agent.

2. Working: The agent is actively processing the request.

3. Input-Required: A critical state where the agent pauses to ask the client for more information.

4. Completed: The task is finished and artifacts are available.

5. Failed: An error occurred during processing.

6. Canceled: The task was terminated by the client.

7. Rejected: The agent refused to perform the task (e.g., due to permission or capability issues).

The Significance of input-required

The input-required state allows for true agency. An agent can emit a TaskStatusUpdateEvent with this state, carrying a message (e.g., “Which audience?”) that the orchestrator must answer by sending a new message referencing the same taskId and contextId. This “resuming” mechanic is fundamental to the protocol’s asynchronous nature.

Technical Implementation and SDK Patterns

The official Python SDK provides the building blocks for creating A2A-compliant servers and clients.

Server-Side Architecture (Minimum Viable Agent)

A standard A2A agent implementation involves:

• A2AStarletteApplication: An HTTP server integration that hosts the JSON-RPC interface.

• DefaultRequestHandler: Maps A2A methods (e.g., message/send, tasks/get) to the agent’s logic.

• AgentExecutor: The class where the core logic resides, emitting events to an EventQueue.

• InMemoryTaskStore: A tutorial-level utility for persisting task states during a session.

• EventQueue: Buffers TaskStatusUpdateEvent and TaskArtifactUpdateEvent objects for streaming.

Client-Side Orchestration

The orchestrator follows a discovery-to-completion flow:

1. Discovery: Using an A2ACardResolver to fetch AgentCards from remote endpoints.

2. Task Creation: Sending an initial message to an agent (e.g., a Research Agent) to initiate a task.

3. Event Handling: Monitoring the stream of events until a terminal state (completed) is reached.

4. Artifact Passing: Extracting artifacts from one agent and providing them as input to another (e.g., an Editor Agent).

Production Nuance and Expert Considerations

Transitioning from a localhost prototype to a production deployment requires addressing several architectural challenges.

Task Persistence and Scaling

While InMemoryTaskStore is convenient for local development, it is unsuitable for production:

• Volatility: Tasks are lost if the server process restarts.

• Routing Issues: In multi-replica deployments, a follow-up request (responding to input-required) might land on a process that has no record of the task.

• Solution: Real-world deployments require shared storage (SQL or Redis) and sophisticated routing to handle tasks/resubscribe logic. The a2a-redis package is one such solution for scaling.

Security and Trust

A2A is an interoperability protocol, not a security boundary.

• Untrusted Input: All data from external agents—including AgentCard fields and artifacts—must be treated as untrusted.

• Prompt Injection: Developers must be wary of feeding external strings directly into LLMs without sanitization.

• Authentication: Additional layers for signatures, policies, and authentication must be implemented atop the protocol.

Future Outlook: The Transition to v1.0

The A2A protocol is actively evolving, with v1.0 introducing significant breaking changes from the v0.3 family.

Change Area

v0.3 Specification

v1.0 Development/Alpha

Streaming Events

Uses kind discriminator and final boolean.

Removes kind discriminator; uses wrapper-based discrimination; removes final boolean.

Enum Values

Lowercase/kebab-case (e.g., input-required).

SCREAMING_SNAKE_CASE (e.g., TASK_STATE_INPUT_REQUIRED).

HTTP Pathing

Uses /v1 prefix in bindings.

Removes versioned prefix for cleaner URL design.

AgentCard

Standard fields for discovery.

Consolidates fields; moves extended support under capabilities.

To prepare for these changes, developers are advised to pin SDK versions and focus orchestrator logic on abstract semantics—such as the “discover-send-watch” state machine—rather than specific payload shapes.