Agent2Agent (A2A) Communication Standard

A universal specification enabling fluid interaction and systemic coherence across disparate, opaque agentic implementations.

Agent2Agent (A2A) Communication Standard
Demonstration Showcase
Architectural Principles
- Standard Interaction Sequence
Initiation Guide
Community Contribution Framework
Forward Roadmap
Project Provenance

A significant hurdle in deploying sophisticated AI systems within enterprise environments is ensuring seamless functional integration among agents developed using disparate technological stacks or proprietary systems. Consequently, we architected the open Agent2Agent (A2A) specification, fostering an environment where agents across varied computational domains can achieve mutual comprehension. Google champions this industry-wide open standard because we foresee it becoming fundamental for underpinning complex multi-agent operations by furnishing agents with a shared semantic layer, independent of their underlying construction framework or provider. Through A2A, participants can mutually advertise their operational aptitudes and stipulate interaction modalities (ranging from textual discourse to form processing or bidirectional multimedia exchange) while maintaining stringent security parameters throughout cooperative execution.

Demonstration Showcase

View this video presentation to observe A2A facilitating uninterrupted dialogue across heterogeneous agentic environments.

Architectural Principles

The Agent2Agent communication specification governs the interchange between isolated artificial entities. Key structural components include:

Entity Descriptor Card: A publicly accessible metadata manifest (typically residing at /.well-known/agent.json) detailing an entity's functional capacities, operational proficiencies, network access URI, and credential expectations. Consumers utilize this artifact for automated discovery.
Service Host Endpoint: An agent implementation that exposes an HTTP interface adhering to the A2A protocol methods (as detailed in the canonical specification). This component receives external directives and oversees the lifecycle of associated operations.
Service Consumer: Any application or peer agent that utilizes A2A services. It transmits execution requests (e.g., tasks/send) directed towards a Service Host Endpoint's Uniform Resource Locator.
Operation Unit: The atomic unit of computational endeavor. A Consumer initiates an Operation Unit via a tasks/send or tasks/sendSubscribe invocation. These Units possess unique identifiers and progress through defined systemic phases (submitted, working, input-required, completed, failed, canceled).
Interchange Datum: Represents a single turn of dialogue exchange between the Consumer (role: "user") and the Agent (role: "agent"). Data exchange packages contain Payload Segments.
Payload Segment: The foundational atomic content structure within an Interchange Datum or a Result Artifact. Segments can assume forms like TextPart, FilePart (supporting embedded binary data or external URIs), or DataPart (for structured payloads such as interactive forms).
Result Artifact: Denotes outputs generated by the Agent throughout an Operation Unit's execution (e.g., finalized documents, structured export data). Artifacts also encapsulate Payload Segments.
Data Pipelining: For protracted Operation Units, hosts supporting the streaming attribute utilize tasks/sendSubscribe. The Consumer receives continuous Server-Sent Events (SSE) containing either TaskStatusUpdateEvent or TaskArtifactUpdateEvent messages, ensuring fidelity on progress.
Proactive Notification Channel: Hosts supporting pushNotifications can unilaterally dispatch Operation Unit status updates to a client-specified callback URI, configured via tasks/pushNotification/set.

Standard Interaction Sequence

Identification: Consumer retrieves the Entity Descriptor Card from the host's designated well-known location.
Invocation: Consumer dispatches a tasks/send or tasks/sendSubscribe transmission, including the initial User Datum and a guaranteed unique Operation ID.
Execution Cycle:
- (Pipelined Mode): Host transmits SSE notifications detailing state changes and newly generated artifacts as processing evolves.
- (Synchronous Mode): Host completes the Operation internally and returns the terminal Task object within the response body.
Feedback Loop (Optional): Should the Operation transition to the input-required state, the Consumer issues subsequent Datum transmissions utilizing the identical Operation ID via tasks/send or tasks/sendSubscribe.
Finalization: The Operation Unit eventually settles into a defined terminal status (completed, failed, canceled).

Initiation Guide

📚 Consult the comprehensive technical documentation to fully comprehend the specification's capacities
📝 Scrutinize the JSON Schema Definition outlining the required data structures
🎬 Utilize our implementation examples to observe A2A operationalization
- Reference Client/Host Pairings (Python, JS)
- Integrated Multi-Agent Web Demonstration
- Command Line Interface Tools (Python, JS)
🤖 Employ our reference agents to see A2A integration across varied development toolkits
- Agent Development Kit (ADK)
- CrewAI Adaptor
- Enterprise Data Processor (Gemini + Mindsdb Integration)
- LangGraph Integration Package
- Genkit Adapter
- LlamaIndex File Interaction Utility
- Marvin Integration Module
- Semantic Kernel Connector
- AG2 + MCP Bridge
📑 Review core concepts for deep protocol comprehension

Community Contribution Framework

We actively encourage and welcome external involvement in the A2A Specification evolution! Here is the engagement pathway:

Kickstart participation? Refer to our formal contribution guidelines for initial steps.
Queries regarding the protocol? Engage with our community via GitHub discussions.
Suggestions for specification refinement? Submit your input through GitHub issues.
Confidential feedback? Kindly utilize this Google feedback portal
Existing Google Cloud client seeking partnership to augment the A2A ecosystem? Please complete this Partner Program application

Forward Roadmap

Planned initiatives focus on refining the core specification logic and enhancing the provided reference implementations:

Specification Evolution:

Entity Discovery Refinements: Standardizing the inclusion of necessary authorization schemas and optional credential parameters directly within the EntityDescriptorCard structure.
Agent Synergy: Investigating the utility of a QuerySkill() invocation method to dynamically verify support for unlisted or unanticipated functional requirements.
Operation Lifecycle & User Experience: Enabling mechanisms for dynamic user interface negotiation mid-operation (e.g., the Agent requesting the injection of audiovisual input during an ongoing exchange).
Consumer Methods & Transport Layer: Exploring extensions to support consumer-initiated remote procedures (beyond current task management primitives).
Enhancements aimed at improving the robustness of data pipelining and the reliability of proactive notification delivery.

Reference Material & Documentation Updates:

Streamlining "First Contact" introductory examples.
Incorporating supplemental demonstrations of agents integrated with diverse frameworks or showcasing specific A2A features.
Developing more comprehensive reference guides for the common client/host libraries.
Implementing automated generation of human-readable HTML documentation directly from the JSON Schema definition.

Project Provenance

A2A Specification is maintained as an open source initiative by Google LLC, governed under the Apache License and open to collaborative development from the global engineering community. WIKIPEDIA: XMLHttpRequest (XHR) is an API in the form of a JavaScript object whose methods transmit HTTP requests from a web browser to a web server. The methods allow a browser-based application to send requests to the server after page loading is complete, and receive information back. XMLHttpRequest is a component of Ajax programming. Prior to Ajax, hyperlinks and form submissions were the primary mechanisms for interacting with the server, often replacing the current page with another one.

== History == The concept behind XMLHttpRequest was conceived in 2000 by the developers of Microsoft Outlook. The concept was then implemented within the Internet Explorer 5 browser (1999). However, the original syntax did not use the XMLHttpRequest identifier. Instead, the developers used the identifiers ActiveXObject("Msxml2.XMLHTTP") and ActiveXObject("Microsoft.XMLHTTP"). As of Internet Explorer 7 (2006), all browsers support the XMLHttpRequest identifier. The XMLHttpRequest identifier is now the de facto standard in all the major browsers, including Mozilla's Gecko layout engine (2002), Safari 1.2 (2004) and Opera 8.0 (2005).

=== Standards === The World Wide Web Consortium (W3C) published a Working Draft specification for the XMLHttpRequest object on April 5, 2006. On February 25, 2008, the W3C published the Working Draft Level 2 specification. Level 2 added methods to monitor event progress, allow cross-site requests, and handle byte streams. At the end of 2011, the Level 2 specification was absorbed into the original specification. At the end of 2012, the WHATWG took over development and maintains a living document using Web IDL.

== Usage == Generally, sending a request with XMLHttpRequest has several programming steps.

Create an XMLHttpRequest object by calling a constructor: Call the "open" method to specify the request type, identify the relevant resource, and select synchronous or asynchronous operation: For an asynchronous request, set a listener that will be notified when the request's state changes: Initiate the request by calling the "send" method: Respond to state changes in the event listener. If the server sends response data, by default it is captured in the "responseText" property. When the object stops processing the response, it changes to state 4, the "done" state. Aside from these general steps, XMLHttpRequest has many options to control how the request is sent and how the response is processed. Custom header fields can be added to the request to indicate how the server should fulfill it, and data can be uploaded to the server by providing it in the "send" call. The response can be parsed from the JSON format into a readily usable JavaScript object, or processed gradually as it arrives rather than waiting for the entire text. The request can be aborted prematurely or set to fail if not completed in a specified amount of time.

== Cross-domain requests ==

In the early development of the World Wide Web, it was found possible to brea