A2A Protocol Architecture: How AI Agents Interoperate

AI systems increasingly need to hand work to another system that has its own model, data, and permissions. The Agent-to-Agent (A2A) protocol defines a common way for those independently built agents to discover capabilities, exchange messages, and report task progress. This explainer is for developers and architects evaluating multi-agent systems: it covers the protocol’s architecture, where it fits beside tool interfaces, and the controls needed before delegating real work.

Why A2A Is Being Discussed

An organization may have specialist agents for travel, customer support, software operations, or research. Connecting them through custom APIs can make each integration dependent on the other agent’s implementation. A shared protocol offers a standard interaction boundary while allowing each agent to keep its internal reasoning, model, and tools private. Google’s announcement of A2A describes this goal of enabling agents built with different frameworks to collaborate.

The protocol has continued to evolve: the A2A project releases include the 1.0.1 release. That makes version compatibility important when connecting a client to a server; implementations should advertise and test the protocol version and interface they actually support rather than assuming that every A2A endpoint behaves identically.

What Is the A2A Protocol?

A2A is an open protocol for communication between an agent that requests work and an agent that performs it. The requesting agent can ask a remote agent to complete a task without needing to know its internal prompts, model, or tools. The remote agent can respond directly or create a task whose state and output can be checked later.

The A2A project documentation describes the protocol’s roles, data model, and supported interfaces. Its protocol specification defines the Agent Card, messages, tasks, artifacts, and protocol bindings. A2A standardizes how agents interact; it does not select an orchestration strategy, require a particular model, or guarantee that a remote agent is trustworthy.

The Problem A2A Solves

Without a shared interaction contract, an agent that delegates work to another agent needs custom code for that service’s discovery, request format, authentication, progress updates, and error handling. Those bespoke connections are costly to maintain. They also tempt teams to tightly couple systems by sharing internal prompts or direct access to tools and data.

A2A makes the remote agent the boundary. The requesting system communicates the task and relevant context; the remote system decides how to carry it out and returns a result. This can preserve differences between frameworks and deployment environments while making the exchange predictable enough to integrate.

This boundary is not the same as giving agents unrestricted autonomy. The caller still chooses which remote agents are available, what information to send, which identity and credentials to use, and whether a returned result can trigger another action. A protocol can make collaboration interoperable, but it cannot decide whether a particular delegation is appropriate.

How A2A Works: Discovery, Messages, and Tasks

An A2A interaction begins with discovery. A client obtains an Agent Card, commonly published at /.well-known/agent-card.json, to learn the agent’s identity, description, supported interfaces, capabilities, skills, and security requirements. The card is a published description, not proof that the agent is safe or that every advertised skill will succeed. Operators should verify its origin and keep it current as deployments change.

After discovery and authentication, the client sends a message to the remote agent using an interface and protocol binding that both sides support. A message contains a role and one or more parts, which can carry text or structured content such as data or files. The client should send only the context needed for the task; an A2A endpoint does not need the caller’s entire conversation or unrestricted access to its local tools.

Some requests finish with a message. Work that takes longer can be represented as a task with a task identifier and a state. The client can use that identifier to follow progress, retrieve an outcome, or respond if the remote agent requests more input. Depending on the binding and server capabilities, progress can be delivered through streaming or notifications rather than repeated polling. A completed task can contain artifacts, such as a report or structured result, separately from the conversational messages exchanged along the way.

The specification defines protocol bindings, including a JSON-RPC 2.0 interface. JSON-RPC standardizes request and response envelopes; A2A defines the agent-specific operations and objects carried through its binding. Other bindings and interface details are versioned in the A2A specification, so a client should follow the interface advertised by the Agent Card instead of assuming a particular URL or transport.

The protocols can complement one another. An agent may use MCP to reach its own tools and use A2A to delegate a separate task. Model Context Protocol (MCP) covers the tool-and-context boundary in more detail.

Components and Key Concepts

Agent Card. A machine-readable description helps a client discover an agent and determine whether its skills and interface fit a task. Cards can also declare security requirements. Treat the information as an advertised contract to validate, not as a grant of trust or authorization.

Messages and parts. Messages carry the communication between agents. Parts represent the content, which may be plain text, structured data, or file references. Because messages cross a system boundary, clients and servers should validate their structure, size, media types, and access rights.

Tasks and state. A task gives a longer operation a durable identity and lifecycle. It can remain active, request additional input, or reach a terminal outcome such as completion, failure, or cancellation. Clients must handle delayed results, disconnects, and state changes rather than treating every response as an immediate answer.

Artifacts. An artifact is an output associated with a task, for example a generated document or structured result. Consumers should validate the artifact’s type, provenance, size, and content before storing it or passing it to another system.

Interfaces, capabilities, and security. A client must choose an interface the remote server actually supports and follow its authentication requirements. The security requirements in the A2A specification should inform the deployment design; transport-level authentication does not replace authorization checks for a specific user, task, or artifact.

Real-World Use Cases

• Travel planning: A coordinator can delegate flight and lodging searches to specialist agents, then combine their proposals. Booking still requires explicit authorization and confirmation.
• Customer support: A support agent can ask a billing agent for account-specific information. The receiving agent must independently enforce the caller’s access rights and disclose only permitted data.
• Software operations: A monitoring agent can request a diagnosis from a deployment or log-analysis agent. A recommendation can return as an artifact for review without granting the diagnosing agent permission to change production.
• Research workflows: A general research agent can ask specialist agents to analyze separate sources and return evidence-backed summaries. The caller should preserve provenance and independently check important claims.

These patterns are useful when a task belongs to another system with its own capabilities and policies. If the operation is a narrow local action, a tool interface may be simpler than delegating a full task to another agent.

Getting Started: Inspect an Agent Card

Begin with a test endpoint and inspect what it advertises before sending any user data. Install curl and jq with your operating system’s package manager:

# Debian or Ubuntu
sudo apt-get update && sudo apt-get install -y curl jq

# macOS with Homebrew
brew install curl jq

# Windows with winget (curl.exe is included with current Windows versions)
winget install jqlang.jq

Then replace the example host with the base URL supplied by the endpoint operator:

export A2A_BASE="https://agent.example.com"

curl --fail-with-body --silent --show-error \
  "$A2A_BASE/.well-known/agent-card.json" |
  jq '{name, protocolVersion, description, supportedInterfaces, capabilities, skills, securitySchemes, securityRequirements}'

The response should be valid JSON with an identity, an advertised interface, and the capabilities relevant to the integration. Confirm the hostname and TLS certificate, compare the returned security requirements with your client configuration, and avoid sending credentials in the request body. An HTTP response alone does not establish that the listed skills are authorized for your user.

Next, use a client implementation compatible with the advertised interface to submit a harmless task in a non-production environment. Verify both a direct response and an asynchronous task if the service supports them. Exercise authentication failures, unsupported capabilities, malformed content, timeouts, cancellation, duplicate requests, streaming interruptions, and artifact validation. Ensure that an uncertain network outcome does not cause a side effect to run twice.

For deployment, record the peer identity, protocol version, task identifier, authorization decision, and outcome. Apply limits to task duration, file size, concurrent requests, and the data sent to the remote agent. Keep secrets out of logs and prompts, and require an independent approval path for consequential actions. The A2A specification and the project’s compatibility and security guidance should be checked again when upgrading either side.

Common Misconceptions

“A2A makes any two agents automatically interoperable.” Both implementations need compatible protocol versions, bindings, capabilities, and authentication. An Agent Card helps with discovery but does not make unsupported features work.

“An Agent Card is a trust certificate.” It describes an endpoint and its advertised features. Clients still need to authenticate the server, apply policy to the caller and task, and validate returned content.

“A2A replaces MCP or tool calling.” A2A is designed for agent-to-agent delegation. MCP connects an AI application to tools and context, while provider tool calling lets an application mediate a model’s request for an operation. A system may use all three at different boundaries.

Related Articles

• Model Context Protocol (MCP) explained covers connecting AI applications to tools and data.
• LLM structured outputs and reliable tool calling explains validation and controlled execution at the model-to-tool boundary.
• AI agent memory and state management covers persistence and recovery across multi-step work.
• Safety patterns for tool-using LLMs describes authorization, approval, and execution safeguards.

Changelog and Last Updated

• Initial publication. Last updated: October 10.