Loading content
The Agent2Agent Protocol defines a vendor-neutral language through which independent agent applications advertise capabilities, delegate tasks, and exchange results. It addresses interoperability between agents and complements protocols such as MCP, which structure access to tools, data sources, and external systems.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
The Agent2Agent Protocol (A2A) is an open standard that defines communication, collaboration, and task delegation between independent AI agents.
A2A was originally developed by Google and later donated to the Linux Foundation. It is positioned as an open, vendor-neutral communication protocol for agent-to-agent interoperability, maintained via a Technical Steering Committee with representation from organizations including AWS, Cisco, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow, plus ongoing community support; it is licensed under the Apache License 2.0. Conceptually, A2A targets the agent-to-agent layer and is designed to complement MCP, which standardizes agent-to-tool integration.
Think of A2A as an “inter-agent network contract” that treats remote agents as opaque counterparts rather than as tool calls. Typical flow: (1) A client agent discovers a remote agent through its Agent Card (JSON metadata at /.well-known/agent-card.json) and extracts capabilities, endpoint, and security schemes. (2) The client authenticates according to the advertised Security Scheme (e.g., using a JWT) and sends messages. (3) The remote agent turns those messages into a Task with a defined lifecycle (e.g., submitted → working → completed/failed/canceled). (4) Progress is handled asynchronously and streamed back (e.g., via Server-Sent Events), and results return as Artifacts—without exposing the remote agent’s internal memory, tools, or reasoning. This lets agents collaborate across framework, runtime, and system boundaries as “remotely callable specialists.”
Agents advertise capabilities and connectivity through an Agent Card so an invoker can decide and route requests without reading implementation code.
A Task is the ID-based contract unit for work, with explicit states from acceptance through completion, failure, or cancellation.
Messages carry the interaction payload; Artifacts are the returned outputs (e.g., documents or data) associated with a task.
Callers treat remote agents as not inherently trusted until authentication succeeds; remote internals remain hidden while only capabilities and outcomes are exposed.
Multi-step jobs typically run asynchronously, with progress communicated via streaming mechanisms.
A2A is useful when agents from different teams, vendors, or frameworks must collaborate across system and trust boundaries without sharing internal prompts, tools, or memory. It fits delegation and coordinated sub-tasks where one agent calls another as a remote specialist. Limits/trade-offs: for simple queries that would be a local tool call, A2A can multiply latency and cost. If trust boundaries are handled loosely, security issues can surface—so each A2A interaction needs proper identity and authorization safeguards. Finally, clients should model work asynchronously via the task lifecycle instead of expecting a single synchronous response, otherwise timeouts and missing progress updates become likely.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.