Across the enterprise AI projects we work on at Bluprintx, one problem comes up consistently: every agent lives in its own silo. An orchestration agent built on LangGraph has no reliable way to hand off work to a supplier's agent running on a completely different stack. You could wire them together with bespoke integration code, but that approach doesn't scale.
The Agent2Agent (A2A) protocol is the answer to exactly that problem, and having worked through its specification and applied it across client engagements, we consider it the most coherent attempt yet at giving AI agents a shared language for collaboration.
Key Takeaways
- A2A is an open standard, originally launched by Google in April 2025 and now governed by the Linux Foundation, designed for secure communication between AI agents built on any framework.
- It solves the interoperability gap: agents built on LangGraph, BeeAI, CrewAI, or Google ADK can now discover each other and collaborate without exposing their internal logic.
- The core building blocks are Agent Cards (capability advertisements), Tasks (units of work), Messages (conversational turns), and Artifacts (tangible outputs).
- A2A complements MCP, not competes with it. MCP connects agents to tools and data; A2A connects agents to each other.
- Enterprise adoption is real: over 150 organizations, including AWS, Microsoft, Salesforce, SAP, and IBM, now support the protocol, with native integration in Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud.
What Is the Agent2Agent (A2A) Protocol?
At its core, the A2A protocol is an open communication standard for AI agents. It enables agents from different vendors, built on different frameworks, and deployed on different infrastructure to discover each other, authenticate, and delegate work, all without custom integration code on either side.
Think of it the way HTTP standardized how web servers and browsers talk to each other. Before HTTP, every connection was a one-off engineering project. A2A does the same thing for agent ecosystems: it replaces bespoke wiring with a shared protocol both sides already speak.
Google announced the A2A protocol on April 9th, 2025, seeing the need for a common language that allows AI agents built on different frameworks to collaborate well across diverse systems. The protocol is a collaborative effort with growing support from more than 100 leading technology companies. Then, on June 23, 2025, Google donated the full specification, including SDKs and developer tooling, to the Linux Foundation, establishing it as a vendor-neutral, community-governed standard. The SDK ecosystem has since expanded from a single Python implementation to five production-ready languages, including JavaScript, Java, Go, and .NET.
This governance move matters. Under a single vendor, a protocol like A2A could become a proprietary moat. Under the Linux Foundation, it becomes infrastructure, something every company can build on without betting on a single provider's roadmap.
The Problem A2A Solves
Imagine your internal inventory agent detects a product shortage. It needs to place a restock order with an external supplier, but the supplier's AI agent was built by a different team, on a different framework, running on different cloud infrastructure. Without A2A, your options are limited: build a custom integration, rely on a human intermediary, or give up on automation entirely.
A2A aims to break down silos and enhance agent interoperability, acting as a common language or universal translator for agent ecosystems. It doesn't require agents to share their internal implementation, their memory, or their proprietary logic. It only requires that they both speak A2A at the boundary, the same way two web servers can exchange data over HTTP without knowing anything about each other's backend.
Core Architecture: How A2A Actually Works
Understanding A2A means understanding four interconnected concepts: the client-server model, Agent Cards, Tasks, and the message/artifact exchange layer. If you're thinking about how this fits into your broader infrastructure, our Engineering & Cloud Solutions practice covers the integration layer that makes multi-agent architectures production-ready.
Client Agents and Remote Agents
A client agent is responsible for formulating and communicating tasks, while the remote agent is responsible for acting on those tasks in an attempt to provide the correct information or take the correct action.
The remote agent (A2A server) exposes an HTTP endpoint implementing the A2A protocol. To the client, the remote agent operates as an invisible system, with no need for the client to understand its internal implementation. This opacity is the point. An agent can consume another agent's capabilities without knowing, or caring, whether that agent is built on LangGraph, Google ADK, or something proprietary.
The Agent Card: An Agent's Digital Resume
An Agent Card is a JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements. It is typically served at a well-known URL (/.well-known/agent.json), making it discoverable without prior configuration.
When a client agent needs help with a task, it retrieves Agent Cards from potential remote agents, reads what those agents can do, and selects the best match. This capability discovery mechanism is what makes multi-agent ecosystems dynamic rather than statically wired.
The three operational units in A2A are:
- Tasks are the fundamental unit of work. Tasks are stateful and progress through a defined lifecycle, from submitted to working to completed (or failed). Tasks can complete immediately or run for hours, with the protocol providing state updates throughout.
- Messages are the conversational turns between agents. Messages may contain multiple Parts, such as text, file attachments, or structured data, supporting multimodal interaction. Each message carries a role, either "user" (client-sent) or "agent" (server-sent), mirroring the familiar structure of a conversation.
- Artifacts are the outputs. An artifact is a tangible product generated by the A2A server as a result of its work. It can be a document, image, spreadsheet or any other deliverable. Like messages, artifacts consist of one or more parts and can be incrementally streamed.
Key Technical Features
Built on Existing Standards
A2A emphasizes reusing existing standards, adopting HTTP(S) as the transport layer, JSON-RPC 2.0 as the messaging format, and Server-Sent Events (SSE) for streaming. This lightweight protocol design reduces both the learning curve and implementation complexity.
This is a deliberate design choice. Choosing JSON-RPC 2.0 over HTTP means any developer who has worked with REST APIs can understand and implement A2A without learning an entirely new paradigm.
A2A supports three interaction modes:
- Synchronous: The client sends a request and waits for a complete response.
- Streaming: The server pushes incremental updates via Server-Sent Events, useful for tasks that produce output progressively.
- Push Notifications: For long-running or disconnected scenarios, the server POSTs updates to a webhook URL the client registered, authenticating incoming notifications via signed JWT, HMAC, or mTLS.
Long-Running Task Support
Many real enterprise workflows can't complete in a single API call. A hiring workflow might take hours. A supply chain rebalancing task might span days. A2A is centered around the concept of Task and supports long-running asynchronous workflows, including scenarios involving multi-turn human-in-the-loop interactions, enabling real-time feedback, notifications and task status updates.
Modality Agnostic
A2A isn't limited to text. The protocol supports audio, video streaming, files, images, and structured JSON data within its Part model. This makes it suitable for multimodal workflows where agents need to exchange more than plain-text instructions.
A2A and MCP: Two Protocols, One Stack
A common point of confusion is the relationship between A2A and the Model Context Protocol (MCP), which was introduced by Anthropic in 2024.
They serve different layers of the same stack:
- MCP connects an individual agent to external tools, APIs, and data sources. It's vertical integration, the agent reaching out to the resources it needs.
- A2A connects agents to each other. It's horizontal integration, one agent delegating to another.
A2A defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources. Together, they form a foundational layer for interoperable, multi-agent systems.
In a practical deployment, an agent might use MCP to query an internal database, then use A2A to hand off a derived task to an external specialist agent. The two protocols are designed to coexist, not compete.
Real-World Enterprise Use Cases
Supply Chain Automation
A retail store might have its own inventory agent that uses MCP to interact with databases storing information about products and stock levels. This is where a strong data and analytics foundation becomes essential: clean, unified data is what makes agent decisions trustworthy. If the inventory agent detects products low in stock, it notifies an internal order agent, which then uses A2A to communicate with external supplier agents and place orders.
This scenario illustrates the real payoff: a workflow that previously required human intervention, detecting a shortage, contacting a supplier, placing an order, can now run end-to-end across organizational boundaries, automatically.
Talent Sourcing and Recruitment
A hiring manager instructs a client agent to find qualified candidates for an open role. The client agent, using A2A, discovers specialized HR remote agents, one that searches job boards, one that screens resumes, one that checks references, and delegates subtasks to each. Results flow back as structured artifacts: shortlists, scoring reports, candidate summaries. No single agent needs to do everything, and none of them need to understand each other's internals.
The Broader Impact
What these scenarios share is a shift in what's possible at scale. Rather than building monolithic agents that try to do everything, organizations can compose specialized agents from different providers, letting each do what it does best. A2A enables independent AI agents to communicate through standardized message formats, allowing agents from different vendors and frameworks to work together seamlessly, like how HTTP enables universal web connectivity.
Security, Privacy, and Opacity
Preserving Internal Logic
One of A2A's most important design principles is opacity. Agents collaborate at the boundary, through tasks, messages, and artifacts, without ever revealing how they work internally. A supplier's agent never sees your inventory logic. Your orchestration agent never sees the supplier's pricing models. Both sides are protected.
Enterprise-Grade Authentication
Enterprise A2A security relies on enforcing transport-level encryption, cryptographically verifying the Agent Card, and authenticating every call. The spec aligns its security model with the OpenAPI Specification: agents declare the schemes they accept in the Agent Card's securitySchemes field.
This means A2A integrates naturally with existing enterprise identity and access management infrastructure, rather than introducing a parallel security model that teams have to learn from scratch.
Adoption and Momentum
The ecosystem around A2A has grown quickly. As of April 2026, more than 150 organizations support A2A, including Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday, and IBM. Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively into their platform offerings.
The GitHub repository has surpassed 22,000 stars. Frameworks including Google ADK, LangGraph, AG2, and CrewAI now support A2A natively, meaning organizations building on any of these stacks can participate in multi-agent workflows today without rebuilding anything from scratch.
For authoritative resources, the protocol specification lives at a2a-protocol.org, the open-source project is maintained at the A2A GitHub repository, and IBM's technical overview provides a useful vendor-neutral breakdown of how the protocol works in practice.
What This Means for Enterprise AI Strategy
The practical implication of A2A isn't just technical, it's architectural. Organizations no longer need to standardize their entire AI stack on a single framework to enable collaboration between agents. Teams can choose the right tool for each domain and let A2A handle the handoffs.
That shifts the design question from "which framework should we standardize on?" to "what specialized capabilities do we need, and how do we compose them?" It's a more modular, more maintainable approach to enterprise AI, and it's one that becomes more powerful as the ecosystem of A2A-compatible agents grows. If you're ready to think through what that looks like for your organization, our Strategy & AI team can help you build the roadmap.
FAQ
What is Agent2Agent (A2A)? A2A is an open communication protocol that allows AI agents from different vendors and frameworks to discover each other, authenticate, and collaborate on tasks, without needing shared infrastructure or exposing internal logic. It was launched by Google in April 2025 and is now governed by the Linux Foundation.
What is the difference between A2A and MCP? The Model Context Protocol (MCP) connects an individual agent to external tools, APIs, and data sources, it's about an agent accessing resources. A2A connects agents to each other, it's about agents delegating tasks and collaborating across boundaries. The two protocols are designed to work together: MCP handles vertical integration (agent to tool), and A2A handles horizontal integration (agent to agent).
Do agents need to be built on the same framework to use A2A? No. A2A acts as a universal messaging tier, allowing agents built on completely different frameworks, such as Google ADK, LangGraph, CrewAI, or IBM's BeeAI, to interact seamlessly. The protocol is transport-level; it doesn't care what's running underneath.
How do agents find each other using A2A? Agents publish Agent Cards: structured JSON documents hosted at a well-known URL (/.well-known/agent.json) that describe the agent's capabilities, supported modalities, authentication requirements, and interaction endpoints. A client agent retrieves and reads these cards to identify the right remote agent for a given task.
Is A2A production-ready? Yes. As of 2026, over 150 organizations, including AWS, Microsoft, Salesforce, and IBM, support A2A in production. Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively. SDKs are available in Python, JavaScript, Java, Go, and .NET.
How does A2A handle security between organizations? A2A aligns with the OpenAPI security model, meaning agents can declare their supported authentication schemes (such as OAuth 2.0 or API keys) directly in their Agent Card. All communication runs over HTTPS, Agent Cards can be cryptographically signed, and push notifications use JWT, HMAC, or mTLS for verification. Critically, agents never expose their internal logic, memory, or tooling, only their outputs.
