A2A Protocol

A2A Explained Simply:

The Agent-to-Agent (A2A) protocol, created by Google, is an open standard that enables AI agents built by different companies, using different frameworks, to discover each other, communicate, and collaborate on tasks. Without A2A, agents from different vendors are isolated islands. With A2A, they become a connected network.

Think about email. Before email standards (SMTP), every messaging system was proprietary - CompuServe users could only message CompuServe users. SMTP made it so anyone can email anyone, regardless of provider. A2A does the same for AI agents.

Real-World Analogy - Zomato + Swiggy Delivery Partners:

Imagine if delivery partners could only work for ONE platform. A Zomato delivery person cannot pick up a Swiggy order. That is how agents work today - a LangChain agent cannot collaborate with an AutoGen agent. A2A is like creating a universal delivery standard - any partner can accept orders from any platform, using a common communication protocol.

MCP vs A2A - Complementary Protocols:

They are complementary, NOT competing. A well-designed system uses BOTH: MCP for tool access, A2A for agent collaboration.

1. Agent Card - The Agent Resume:

Every A2A agent publishes an Agent Card at a well-known URL (like /.well-known/agent.json). This is a machine-readable description of what the agent can do, what inputs it accepts, and how to communicate with it. Think of it as a LinkedIn profile for AI agents.

// Example Agent Card
{
  "name": "Travel Planner Agent",
  "description": "Plans trips, books flights and hotels,
    creates itineraries based on preferences and budget",
  "url": "https://travel-agent.example.com/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "plan_trip",
      "name": "Trip Planning",
      "description": "Creates a complete travel itinerary"
    },
    {
      "id": "book_flight",
      "name": "Flight Booking",
      "description": "Searches and books flights"
    }
  ]
}

2. Tasks - The Unit of Work:

When one agent asks another to do something, it creates a Task. A task has a lifecycle: submitted, working, input-required, completed, failed, canceled. The requesting agent can track progress and provide additional input if needed.

Task Lifecycle:
  SUBMITTED -> WORKING -> COMPLETED
                 |          |
                 +-> INPUT_REQUIRED (needs more info)
                 |          |
                 +-> FAILED
                 +-> CANCELED

3. Messages & Parts - The Conversation:

Within a task, agents exchange Messages containing Parts (text, files, structured data). This enables rich, multi-turn conversations between agents - not just simple request/response.

Complete A2A Interaction Flow:

1. DISCOVERY
   Client Agent fetches Agent Card from:
   https://travel-agent.example.com/.well-known/agent.json
   Reads capabilities, skills, endpoint URL

2. TASK CREATION
   Client Agent sends task to Remote Agent:
   "Plan a 5-day trip to Goa for 2 people, budget 50K"
   Remote Agent accepts, returns task ID

3. PROCESSING
   Remote Agent works on the task
   May stream partial results (day 1 planned...day 2...)
   May ask for more input ("Prefer beach or heritage?")

4. COLLABORATION (Optional)
   Remote Agent might delegate to OTHER agents:
   - Flight Agent: search and book flights
   - Hotel Agent: find accommodations
   - Activity Agent: suggest things to do

5. COMPLETION
   Remote Agent returns final result:
   Complete itinerary with flights, hotels, activities
   Task status: COMPLETED

Communication Patterns:

• Request-Response: Simple one-shot task. Agent sends request, gets complete response.
• Streaming: Agent sends request, gets partial results as they are generated. Good for long-running tasks.
• Multi-Turn: Agent and remote agent have a back-and-forth conversation. Remote agent asks clarifying questions before completing.
• Push Notifications: Remote agent notifies client when a long-running task completes, without the client polling.

Key Design Principle - Opaque Agents:

A2A treats agents as opaque - the client agent does not need to know what LLM, framework, or architecture the remote agent uses. It could be a LangChain agent, a custom Python script, or even a team of human operators behind an API. All that matters is that it speaks the A2A protocol.

Scenario 1: Enterprise Customer Support

Customer: "I want to return my order and get a refund"

[Customer Support Agent] (Main orchestrator)
  |-- Discovers Order Management Agent via Agent Card
  |-- Creates task: "Process return for order #12345"
  |
  [Order Management Agent]
    |-- Validates order is eligible for return
    |-- Creates sub-task to Logistics Agent
    |
    [Logistics Agent]
      |-- Schedules pickup for returned item
      |-- Returns pickup date and tracking
    |
  |-- Creates sub-task to Payment Agent
  |
  [Payment Agent]
    |-- Processes refund to original payment method
    |-- Returns refund confirmation
  |
  Final Response: "Return initiated. Pickup on March 5.
                   Refund of Rs 2,499 within 5-7 days."

Scenario 2: Hiring Pipeline

[HR Manager Agent] (Orchestrator)
  |
  +-- [Resume Screening Agent]
  |     Screens 500 resumes, shortlists 50
  |
  +-- [Interview Scheduler Agent]
  |     Coordinates calendars, sends invites
  |
  +-- [Technical Assessment Agent]
  |     Generates coding challenges, evaluates submissions
  |
  +-- [Background Check Agent]
        Runs verification in parallel

All agents are from different vendors,
built with different frameworks,
but communicate via A2A protocol.

Key Benefit - Vendor Independence:

With A2A, your enterprise is not locked into one AI vendor. You can use the best agent for each task regardless of who built it. Switch out the resume screening agent for a better one without changing the rest of the pipeline. This is the power of open protocols.

Challenge 1: Trust and Security

When agents from different organizations collaborate, trust becomes critical. How do you verify that the remote agent is who it claims to be? How do you ensure it does not leak sensitive data? A2A defines authentication mechanisms (OAuth 2.0, API keys) but implementing them correctly is your responsibility.

Challenge 2: Error Propagation

In a chain of agents (A -> B -> C -> D), if agent C fails, how does that cascade? A2A defines task failure states, but designing graceful degradation and retry logic across multiple agents is complex. One failing agent should not bring down the entire workflow.

Challenge 3: The Protocol is Still Young

A2A was released in 2025 and is still early in adoption. The specification may change, tooling is limited, and production deployments are rare. It is important to learn and experiment, but be cautious about betting critical systems on it today.

Challenge 4: Orchestration Complexity

As more agents join a workflow, orchestration becomes harder. Who decides which agent to call? How do you handle conflicting results from two agents? How do you optimize for cost when each agent call costs money? These are open problems in multi-agent systems.

Q: What is A2A and how does it differ from MCP?

Q: What is an Agent Card and why is it important?

Q: What does it mean that A2A agents are "opaque"?

Q: What are the main communication patterns in A2A?

Q: What are the key challenges with A2A adoption?