Agent2Agent (A2A) Protocol

repository·main·Indexed 12 days ago

https://github.com/a2aproject/a2a

An open standard for interoperability and collaboration between autonomous AI agents across different frameworks and ecosystems. A2A v1.0 supports standardized communication via JSON-RPC 2.0 over HTTP(S), gRPC, and JSON+HTTP, featuring Agent Cards for discovery and support for synchronous, streaming (SSE), and asynchronous interactions. It provides SDKs for Python, Go, JavaScript, Java, .NET, and Rust, and integrates with frameworks such as LangGraph, CrewAI, and Pydantic AI.

Tokens
46.8K
Snippets
83
Records
209
Agent score
95%

What's inside A2A

  1. Overview of the Agent2Agent (A2A) Protocol

    main

    The Agent2Agent (A2A) Protocol is an open standard designed for seamless communication and interoperability between AI agents. It provides a common language that allows agents built on different frameworks (such as LangGraph, CrewAI, or Semantic Kernel) to collaborate, delegate sub-tasks, and exchange information without exposing their internal memory, tools, or proprietary logic.

    Key Capabilities

    • Interoperability: Connect agents across diverse platforms to create composite AI systems.
    • Complex Workflows: Enable task delegation and coordination between agents to solve problems beyond the scope of a single agent.
    • Security & Opacity: Agents interact securely without sharing internal implementation details or intellectual property.
    • Extensibility: Supports formal protocol extensions and custom bindings via a tiered promotion process.
  2. Core features of A2A Protocol v1.0

    main

    A2A v1.0 is a production-ready standard for agent-to-agent communication designed for enterprise environments. Key capabilities include:

    • Heterogeneous environment support: Uses multi-protocol bindings and version negotiation to allow interoperability across different technology stacks.
    • Multi-tenancy support: Enables a single endpoint to securely host multiple agents.
    • Signed Agent Cards: Uses cryptographic verification for agent identity and metadata to establish trust.
    • Web-aligned architecture: Follows stateless, layered patterns compatible with standard web infrastructure (load balancing, gateways, etc.).
    • Flexible result consumption: Supports polling, streaming, or webhooks for receiving task updates and responses.
  3. Understand the A2A JSON Artifact

    main

    The a2a.json file is a non-normative build artifact that serves as a JSON Schema 2020-12 bundle. It is derived directly from the canonical protocol definition located at specification/a2a.proto.

    Important: Do NOT edit a2a.json manually. It is a transient file generated during the build process. To make changes to the schema, you must update the source .proto file instead. The artifact is regenerated automatically via the build pipeline.

  4. Configure blocking vs non-blocking execution modes

    main

    When sending messages via SendMessageConfiguration, you can control whether the operation waits for the task to finish or returns immediately using the return_immediately field.

    • Blocking (return_immediately: false or unset): This is the default behavior. The operation MUST wait until the task reaches a terminal state (TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_REJECTED) or an interrupted state (TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED) before returning. The response will include the latest task state and artifacts.
    • Non-Blocking (return_immediately: true): The operation returns immediately after the task is created. The returned task will be in an in-progress state (e.g., TASK_STATE_WORKING). You are responsible for polling via Get Task, subscribing via Subscribe to Task, or waiting for push notifications.

    Note: return_immediately has no effect on streaming operations, operations returning a direct Message (instead of a task), or configured push notifications.

  5. Handle Artifacts as task outputs

    main

    An Artifact is a tangible, concrete result generated by a remote agent (e.g., a document, image, or structured data).

    Key characteristics:

    • Has a unique artifactId.
    • Has a human-readable name.
    • Consists of one or more Part objects.
    • Is closely tied to the task lifecycle and can be streamed incrementally to the client.
  6. How A2A and MCP work together in agentic systems

    main

    A2A and MCP are complementary. In a complex application, you typically use A2A for inter-agent communication and MCP for internal tool integration within each agent.

    The Pattern:

    1. User $\leftrightarrow$ Agent A: Uses A2A for high-level task delegation.
    2. Agent A $\leftrightarrow$ Agent B: Uses A2A for collaborative reasoning and multi-turn negotiation.
    3. Agent B $\leftrightarrow$ Tools: Uses MCP to execute specific, structured functions required to complete the task assigned by Agent A.

    This allows agents to partner on broad goals (A2A) while utilizing specialized capabilities (MCP) to execute the work.

  7. Key Features of the A2A Protocol

    main

    The A2A protocol provides a standardized way for agents to interact using the following features:

    • Standardized Communication: Uses JSON-RPC 2.0 over HTTP(S).
    • Agent Discovery: Utilizes "Agent Cards" which detail capabilities and connection information.
    • Flexible Interaction: Supports synchronous request/response, streaming (SSE), and asynchronous push notifications.
    • Rich Data Exchange: Supports text, files, and structured JSON data.
    • Enterprise-Ready: Includes design considerations for security, authentication, and observability.
  8. Understand A2A error handling and categories

    main

    All A2A operations may return errors. Servers MUST return appropriate errors and SHOULD provide actionable information. Errors fall into these categories:

    • Authentication Errors: Invalid or missing credentials (e.g., missing bearer token). Servers MUST reject these and SHOULD specify the required scheme.
    • Authorization Errors: Insufficient permissions (e.g., accessing a task owned by another user). Servers MUST NOT reveal the existence of resources the client is not authorized to access.
    • Validation Errors: Invalid input parameters (e.g., invalid task ID format). Servers MUST validate inputs and SHOULD specify which parameter failed and why.
    • Resource Errors: Requested resource not found or inaccessible (e.g., task deleted). Servers SHOULD NOT distinguish between "does not exist" and "not authorized" to prevent information leakage.
    • System Errors: Internal failures or temporary unavailability (e.g., database failure). Servers SHOULD return appropriate codes for temporary vs permanent failures and MAY include retry guidance.
  9. Discover agents using Curated Registries (Catalog-Based)

    main

    In enterprise or marketplace environments, agents are discovered via a central registry service. This allows for capability-based discovery (e.g., searching for specific skills).

    Workflow:

    1. Publishing: A2A Servers upload their Agent Cards to the registry.
    2. Querying: Client agents call the registry's API to search for agents based on criteria like skills, tags, provider name, or capabilities.
    3. Retrieval: The registry returns matching Agent Cards or references.

    Note: The current A2A specification does not prescribe a standard API for these registries.

  10. Understand the difference between A2A and MCP

    main

    When building agentic systems, you must choose the correct protocol based on whether the interaction is with a tool or another autonomous agent:

    Model Context Protocol (MCP)

    Use MCP when an agent needs to interact with Tools and Resources. These are typically stateless primitives with well-defined, structured inputs and outputs.

    • Characteristics: Calculators, databases, APIs, or predefined functions.
    • Purpose: To allow an agent to gather information or perform discrete, specific functions (e.g., get_weather or query_database).

    Agent2Agent (A2A) Protocol

    Use A2A when an agent needs to interact with other Agents. These are autonomous systems capable of reasoning and planning.

    • Characteristics: Systems that maintain state, engage in multi-turn dialogues, and manage complex, evolving tasks.
    • Purpose: To enable peer-to-peer collaboration, discovery, negotiation, and the exchange of conversational context (e.g., a travel agent coordinating with a flight agent).
  11. Compare A2A with MCP (Model Context Protocol)

    main

    While both protocols facilitate interaction, they serve different layers of the agent stack:

    FeatureMCP (Model Context Protocol)
    Primary FocusConnecting models to data and external resources (tools).
    Interaction TypeTypically stateless, predefined functions (e.g., database queries, calculators).
    Agent RoleTreats the capability as a tool for the model.
    FeatureA2A (Agent2Agent)
    Primary FocusStandardizing communication between deployed agents.
    Interaction TypeMulti-turn, reasoning-heavy, and conversational (e.g., negotiation, clarification).
    Agent RoleEnables agents to act as peers, communicating in their native modalities.

    Mental Model: Use MCP to give a model a tool; use A2A to let one agent delegate a complex task to another agent.