A Slack message lands in your engineering channel. A triaging agent catches it, classifies it as a billing issue, and needs to hand it to a finance agent running on a completely different stack - different vendor, different framework, different company. Without a shared protocol, that hand-off is custom glue code someone wrote at 11 pm. That is the problem the Agent-to-Agent (A2A) protocol exists to solve, and as of early 2026, it finally looks like the glue code days are numbered.
The Agent2Agent Protocol (A2A) is an open communication standard, developed by Google and released on April 9, 2025, that enables AI agents to discover, authenticate, and delegate tasks to other AI agents across different platforms and frameworks. It is worth pausing on what that sentence actually means, because it is easy to conflate A2A with MCP, and they operate at different layers entirely.
What A2A does that MCP does not
The A2A protocol addresses a different problem than MCP. Where MCP connects an agent to tools and data, A2A connects one agent to another. Think of MCP as the vertical bus - your agent reaching down into a Notion database or a Zendesk API. A2A is the horizontal bus - your agent reaching sideways to another agent that belongs to a different team, vendor, or runtime.
Picture an auto repair shop. From the outside, the customer sees a single "repair agent." Internally, that repair agent collaborates over A2A with specialized diagnostic, estimate, and parts-procurement agents, and each of those specialists uses MCP to reach its own inventory systems or parts catalogs. A2A is the horizontal bus; MCP is the vertical bus.
The mechanics are deliberately boring, which is the point. A2A uses HTTP, Server-Sent Events, and JSON-RPC 2.0 for transport, and Agent Cards for capability advertisement.
Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements, analogous to a service descriptor in microservice architectures. An orchestrating agent fetches a card, reads what the downstream agent can do, and decides whether to delegate - no central registry required, no prior configuration.
Tasks represent units of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, canceled, and failed, and carrying structured payloads that can include text, files, and structured data.
The input-required state matters more than it looks: it is how a long-running delegated task can pause and surface a question to a human, then resume from the same task ID, potentially days later.
What the v1.0 release actually changed
A2A v1.0, released in early 2026, is the version that turned the spec into something production-grade. The four changes in v1.0 each address a real deployment problem.
The most important is Signed Agent Cards. By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack. Signed Agent Cards are effectively the trust model that makes decentralized discovery viable at all.
The second change is multi-tenancy. A single endpoint can now host multiple agents, letting SaaS providers serve different agents per tenant.
The third is multi-protocol bindings: the same logical agent can be exposed over both JSON-RPC and gRPC. The fourth is version negotiation, which provides spec-level guarantees for backward-compatible migration from v0.3 to v1.0.
A2A v1.0 is not a new idea - it is the same idea, minus the rough edges that were blocking production deployment.
How the consolidation happened
The governance story is as important as the technical spec. On June 23, 2025, Google donated A2A to the Linux Foundation, establishing the Agent2Agent Protocol Project under neutral governance. That move mattered because enterprise architects will not build on a protocol one vendor controls.
Then the real signal arrived. IBM's ACP was folded into A2A in a merger announced by the Linux Foundation on August 29, 2025. IBM had built ACP independently to power its BeeAI platform; when A2A came on the scene a month later, IBM immediately saw alignment in how both teams approached the challenge of enabling agents to communicate and began exploring how to bring the efforts together. ACP is now officially merged with A2A under the Linux Foundation umbrella. The protocol's largest potential competitor chose to join rather than compete.
At the April 2026 one-year mark, 150+ orgs run A2A in production - including Microsoft, AWS, Salesforce, SAP, ServiceNow, and Deutsche Bank - and native support ships in Google ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, AutoGen, and Microsoft Agent Framework. The Technical Steering Committee now includes representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow.
Where it still falls short
The adoption numbers are real, but the gaps are also real, and the hype tends to paper over them.
There is no core machine-readable skill I/O schema, no fully standardized "invoke skill X" primitive, and authorization can become indirect ("authorization creep") if not designed carefully. That last one is subtle: when you delegate to a remote agent, that agent may itself delegate further, and the permissions it carries can accumulate in ways the originating agent never intended.
HTTP's stateless nature fundamentally conflicts with the reality of AI agent interactions. Consider a supply chain optimization that unfolds over hours or days, with multiple agents contributing analysis, awaiting approvals, and coordinating with external systems. HTTP connections timeout, clients disconnect, and the state is lost. There is no inherent mechanism for durable state management, resumable conversations, or persistent messaging. The polling and webhook options in the spec help, but teams still need to build the state persistence layer themselves.
The most common failure mode in A2A agent implementations is mixing protocol concerns with business logic.
When the component that handles A2A messages also contains the domain rules, you end up unable to test either cleanly. The pattern to avoid: a fat AgentExecutor that both speaks the protocol and decides what to do. Keep those layers separate from day one.
A key risk involves attackers using A2A discovery to find agents, then exploiting vulnerabilities exposed through those agents' MCP tool connections. Finding an agent via A2A that uses an insecure MCP server is an indirect attack path. Threats like "tool squatting" - maliciously registering fake tools - are more dangerous when combined with A2A's discovery mechanism. Signed Agent Cards close the card-forgery door, but they do not audit what an agent does with its MCP connections once it receives a delegated task.
In many small systems, adopting A2A is architecture cosplay - borrowing the vocabulary of distributed agent systems without any of the actual boundary problems that make the protocol valuable. If you have one agent, use HTTP. A2A earns its keep when you have agents that belong to different owners and need genuine trust boundaries between them.
For teams already running multi-agent workflows across Slack and Teams - think a triage agent delegating to a Jira-aware planning agent from a different vendor - A2A is the first protocol worth building toward rather than around. The spec is at a2a-protocol.org, and the GitHub repo recently crossed 22,000 stars. A teammate like Beagle, operating inside Slack and Teams, would sit naturally on this stack: receiving delegated tasks over A2A, executing them against workspace context, and returning structured artifacts back to the calling agent. Whether that is useful to you depends entirely on whether your agent boundaries are real or hypothetical.
The honest answer right now: the standard is solid, the gaps are known, and enterprises are starting to use it for real multi-agent boundaries. The worst outcome would be if developers only use it in demos while production systems fall back to custom APIs and queues. The protocol is ready for that bar. Whether implementations will be is a different question.