Written by: Arjun Karnik, Growth Marketing Specialist

Key Takeaways for Working with A2A

  • The A2A protocol is an open standard donated to the Linux Foundation that enables collaboration between AI agents across frameworks and vendors.
  • Agent Cards are JSON discovery files published at /.well-known/agent-card.json that let agents locate, evaluate, and delegate tasks without hard-coded integrations.
  • A2A maintains a nine-state task lifecycle with native support for long-running tasks, streaming updates via SSE, and webhook push notifications.
  • Security in A2A relies on mTLS, OAuth 2.0 scopes mapped to skills, JWS-signed Agent Cards, and mid-task authentication escalation to TASK_STATE_AUTH_REQUIRED.

How Agent Cards Work in A2A

Every A2A-compliant agent publishes its Agent Card at a well-known URL following RFC 8615 so client agents can discover it via unauthenticated HTTP GET requests. The canonical discovery path is /.well-known/agent-card.json.

The following example shows a production-ready Agent Card for a travel-booking agent that conforms to the A2A v1.0 specification. Pay attention to the top-level identity fields, the capabilities object, the skills array, and the securitySchemes section, because client agents rely on these fields during discovery and delegation.

{ "name": "TravelBookingAgent", "description": "Books flights, hotels, and ground transport for multi-leg itineraries.", "version": "1.2.0", "provider": { "organization": "Acme Travel Systems", "url": "https://travel.acme.example" }, "url": "https://travel.acme.example/a2a", "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": false }, "defaultInputModes": ["text/plain", "application/json"], "defaultOutputModes": ["text/markdown", "application/json"], "skills": [ { "id": "book-flight", "name": "Book Flight", "description": "Searches and books commercial flights given origin, destination, and travel dates.", "tags": ["travel", "flight", "booking"], "examples": [ "Book a round-trip flight from SFO to LHR departing 2026-09-01.", "Find the cheapest one-way flight from JFK to CDG next Friday." ], "inputModes": ["text/plain", "application/json"], "outputModes": ["application/json"] }, { "id": "book-hotel", "name": "Book Hotel", "description": "Reserves hotel rooms for specified dates and guest counts.", "tags": ["travel", "hotel", "accommodation"], "examples": [ "Reserve a double room in Paris from 2026-09-01 to 2026-09-07." ], "inputModes": ["text/plain"], "outputModes": ["application/json"] } ], "securitySchemes": { "oauth2": { "type": "oauth2", "flows": { "clientCredentials": { "tokenUrl": "https://auth.acme.example/token", "scopes": { "travel:book": "Create and manage travel bookings" } } } } }, "security": [ { "oauth2": ["travel:book"] } ] }

A minimal valid Agent Card requires at least six top-level fields: name, description, version, url, capabilities, and skills. A2A also distinguishes between a public Agent Card available for initial discovery and an extended Agent Card returned after client authentication that may include additional skills or configuration details.

Client Agent vs. Remote Agent Responsibilities

A2A maintains opaque operations so agents cannot see the inner workings of other agents during collaboration, so neither side needs to know the other agent’s internal architecture, model, or framework. Roles remain fluid, because any agent can act as a client in one interaction and a server in another.

The client agent is responsible for:

  • Fetching the remote Agent Card from /.well-known/agent-card.json
  • Matching the remote agent’s declared skills to the task at hand
  • Acquiring credentials through the authentication flow declared in the card
  • Submitting a task via JSON-RPC 2.0 and monitoring its lifecycle
  • Consuming streaming updates via SSE or webhook push notifications

The remote agent is responsible for:

  • Publishing and maintaining an accurate, signed Agent Card
  • Accepting and validating incoming JSON-RPC requests
  • Managing task state transitions and emitting status events
  • Producing Artifacts as the deliverable output
  • Enforcing per-skill authorization scopes on every call

Managing task state transitions becomes especially important when tasks run longer than a single request and response. That responsibility leads directly into the A2A model for long-running work.

Long-Running Tasks and the A2A Task Lifecycle

A2A natively supports long-running tasks through streaming, push notifications, and asynchronous execution for scenarios where agents or users are not continuously connected. The A2A task lifecycle defines nine states, listed here in order of typical progression:

  1. TASK_STATE_UNSPECIFIED , the default zero value, used only when no state has been assigned.
  2. TASK_STATE_SUBMITTED , where the client has sent the task and the remote agent has acknowledged receipt.
  3. TASK_STATE_WORKING , where the remote agent is actively processing the task.
  4. TASK_STATE_INPUT_REQUIRED , where the agent has paused and needs additional information from the client before continuing.
  5. TASK_STATE_AUTH_REQUIRED , where the agent requires additional credentials mid-task before proceeding.
  6. TASK_STATE_COMPLETED , where the task finished successfully and Artifacts are available for retrieval.
  7. TASK_STATE_FAILED , where the task terminated with an error.
  8. TASK_STATE_CANCELED , where the client issued a CancelTask call and the agent honored it.
  9. TASK_STATE_REJECTED , where the remote agent refused the task, typically due to policy or capability mismatch.

A2A tasks support a message thread plus artifacts, so the lifecycle functions as both an operational state machine and a conversational exchange rather than a simple request-response pattern. A2A also provides mechanisms to resume interrupted tasks that reach states such as TASK_STATE_INPUT_REQUIRED or TASK_STATE_AUTH_REQUIRED.

Discovery and Communication Flow Between Agents

The core nouns defined in the A2A protocol, including AgentCard, AgentSkill, Task, Message, Part, Artifact, and Extension, are defined in Protocol Buffers and published as JSON Schema 2020-12, auto-generated from the protos. The discovery and communication flow proceeds as follows:

  1. The client agent sends an unauthenticated HTTP GET to https://{remote-domain}/.well-known/agent-card.json.
  2. The client parses the returned Agent Card and verifies any JWS signatures against a trusted issuer key before trusting the card.
  3. The client matches the remote agent’s declared skills to the task requirements.
  4. The client acquires credentials using the scheme declared in securitySchemes , such as OAuth 2.0 client credentials, Bearer token, or mTLS certificate.
  5. The client submits a task via an HTTP POST carrying a JSON-RPC 2.0 payload with method SendMessage or SendStreamingMessage and an A2A-Version header.
  6. The remote agent returns a task ID and begins processing, then emits TaskStatusUpdateEvent or TaskArtifactUpdateEvent messages over an SSE stream.
  7. For very long-running tasks, the client registers a webhook via CreatePushNotificationConfig and the server POSTs updates to that URL.
  8. The client calls GetTask to retrieve the final Artifact once the task reaches a terminal state.

A2A uses existing standards like HTTP, JSON-RPC, and Server-Sent Events (SSE) so developers can adopt it quickly.

A2A vs. MCP: How to Use Both Protocols

MCP, introduced by Anthropic, is a protocol for connecting AI and LLM applications and agents to external data sources, tools, and APIs, while A2A standardizes peer-to-peer delegation of complete autonomous tasks between agents. The two protocols are complementary, not competing. A2A functions as the horizontal agent-to-agent interoperability layer while MCP serves as the vertical agent-to-tool layer, so an agent can speak A2A outward and MCP downward to its own tools. The following table maps the architectural and operational differences that guide when to use each protocol.

Dimension A2A MCP Notes
Primary purpose Agent-to-agent collaboration across frameworks and vendors Connecting LLM applications to external data sources, tools, and APIs Different layers of the same stack
Architecture Horizontal, peer-to-peer with fluid client-server roles Strict client-server, where the AI agent is always the client and the tool provider is always the server A2A roles can invert, while MCP roles cannot
Transport HTTPS with JSON-RPC 2.0, SSE streaming, and optional gRPC, which was added in v0.3.0 in July 2025 stdio for local subprocesses or Streamable HTTP for remote servers, as of spec version 2025-11-25 A2A is network-first, while MCP supports local subprocess communication
State model Stateful task lifecycle with nine defined states that supports multi-turn negotiation Stateless per call, where tools perform single functions without retaining task state Use A2A when the subtask requires reasoning across turns
Discovery Agent Card at /.well-known/agent-card.json , registry-based discovery, or direct configuration Server URL configured by the developer, with no standardized well-known discovery path A2A discovery is runtime-dynamic, while MCP discovery is typically build-time
Typical use case Delegating a complex, stateful task such as planning an international trip to a specialist agent Connecting an agent to a database, search API, or file system Combine both protocols in production

Security and Authentication Basics in A2A

The A2A protocol features a security-first design that assumes zero trust between distributed agents, relying on mutual TLS (mTLS) to encrypt the channel and verify the cryptographic identity of both endpoints, OAuth 2.0 for user-delegated authority with strictly defined scopes, and basic API keys for simpler internal architectures.

The four primary security mechanisms in A2A v1.0 form a defense-in-depth strategy, and each one protects a different layer of the system:

For authorization downscoping in agent delegation chains, the recommended pattern is OAuth 2.0 Token Exchange (RFC 8693) to trade a broad token for a narrowly scoped, short-lived token specific to the delegated skill. Rost Glukhov recommends no anonymous agents in production paths, per-request authentication for every A2A call, OAuth scopes mapped to skills rather than blanket admin rights, and short-lived delegation tokens carrying user ID, task ID, scope, expiry, and hop limit.

End-to-End Travel-Agent Workflow Example

This scenario illustrates a user asking an orchestrator agent to plan a trip from San Francisco to London. The orchestrator discovers and delegates to two specialist agents, TravelBookingAgent for flights and hotels and VisaCheckAgent for entry requirements.

Step 1 , Discovery. The orchestrator fetches https://travel.acme.example/.well-known/agent-card.json and https://visa.acme.example/.well-known/agent-card.json , verifies JWS signatures, and confirms both agents declare the required skills.

Step 2 , Task submission to TravelBookingAgent. The orchestrator sends the following JSON-RPC request:

{ "jsonrpc": "2.0", "id": "req-001", "method": "SendStreamingMessage", "params": { "message": { "role": "ROLE_USER", "parts": [ { "type": "TextPart", "text": "Book a round-trip flight SFO→LHR departing 2026-09-01, returning 2026-09-08, and a hotel in London for the same dates." } ] }, "configuration": { "returnImmediately": false } } }

Step 3 , SSE streaming updates. The remote agent emits TaskStatusUpdateEvent messages as the task moves through SUBMITTED and WORKING. If the agent needs passport details, it transitions to INPUT_REQUIRED and the orchestrator supplies them in a follow-up message.

Step 4 , Artifact retrieval. On COMPLETED, the orchestrator calls GetTask and receives an Artifact:

{ "taskId": "task-abc123", "state": "TASK_STATE_COMPLETED", "artifacts": [ { "parts": [ { "type": "DataPart", "data": { "flightConfirmation": "BA0284", "hotelConfirmation": "ACME-LON-7721", "totalCost": "USD 2340.00" } } ] } ] }

Step 5 , Parallel delegation to VisaCheckAgent. With A2A, the orchestrator delegates the visa check concurrently, collects both Artifacts, and assembles a unified itinerary for the user, without custom integration code.

These patterns appear across many domains, so the same discovery, delegation, and lifecycle concepts apply beyond travel planning.

Frequently Asked Questions About A2A and MCP

What is the difference between an Agent Card and an MCP server manifest?

An Agent Card is a JSON document published at a standardized well-known URI that describes an autonomous agent’s identity, skills, supported protocol bindings, capability flags, and authentication requirements. It is designed for runtime discovery by other agents. An MCP server manifest, by contrast, is typically configured at build time by a developer and describes tools, prompts, and resources that an LLM application can call. Agent Cards enable dynamic peer-to-peer delegation between agents across organizational boundaries. MCP server configurations enable a single agent to reach its own tools and data sources. The two serve different layers of the same stack and are designed to be used together in production systems.

Can A2A and MCP be used in the same production system?

Yes, and this is the recommended production pattern. An agent uses MCP internally to access its own tools, databases, and APIs. It then uses A2A to delegate complete, stateful subtasks to external specialist agents across organizational or framework boundaries. For example, a travel orchestrator agent might use MCP to query its internal pricing database and then use A2A to delegate hotel booking to a specialist agent running on a different vendor’s infrastructure. The two protocols compose cleanly because they operate at different layers, with MCP vertical from agent to tool and A2A horizontal from agent to agent.

How does A2A handle authentication when a task requires credentials mid-execution?

A2A defines a dedicated task state called TASK_STATE_AUTH_REQUIRED for this scenario. When a remote agent determines that it needs additional credentials to continue, for example to access a third-party booking system on behalf of the user, it transitions the task to AUTH_REQUIRED rather than failing it. The client agent receives this state update via SSE or webhook, acquires the necessary credentials through the appropriate OAuth flow or other scheme declared in the Agent Card, and resumes the task by sending a follow-up message with the credentials attached. This design keeps the task alive across authentication interruptions without requiring the client to restart the entire workflow from scratch.

What governance body oversees the A2A protocol specification today?

The Linux Foundation hosts the A2A protocol as an open standard under the Agent2Agent Protocol project. Google originally developed and launched the protocol in April 2025 with support from more than 50 organizations. The protocol was donated to the Linux Foundation in June 2025. By its one-year mark in April 2026, the project had grown to more than 150 participating organizations including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. The v1.0 specification was released in 2026 under Linux Foundation stewardship, with the core data model defined in Protocol Buffers and published as JSON Schema 2020-12.

What are the most common mistakes when publishing an A2A Agent Card?

The most frequently documented errors include using vague skill descriptions that do not help a client agent evaluate fit, declaring streaming support in the capabilities object without implementing the corresponding SendStreamingMessage endpoint, leaving the skills array empty, setting the url field to the card’s own discovery path instead of the JSON-RPC task endpoint, and hard-coding localhost URLs in production cards. A well-formed Agent Card should include two to three concrete example prompts per skill, accurate MIME-type arrays for inputModes and outputModes , and only capability flags that the agent actually implements. Agent Cards should also never contain static secrets, and sensitive cards should be protected behind authentication, with different clients receiving different views based on permissions.

Verify These Claims Yourself

Every technical claim in this article is traceable to a dated, publicly accessible source. The A2A specification is published on the a2aproject GitHub. The Linux Foundation governance announcement is on the Linux Foundation press page. The original Google launch post is on Google’s developer blog.

To test the citation authority of this content directly, open ChatGPT, Perplexity, or Google AI Overviews and ask “agent to agent protocol explained” or “a2a agent card example.” Observe which sources appear in the answer. That is the same self-verifying method Arjun Karnik applies to every topic his test lab covers, where the system being documented is the same system producing the visibility.

If you want to apply this structured, citation-optimized approach to your own content and agent strategy, book a demo with AI Growth Agent.