A year ago, if you wanted two agents built on different frameworks to hand work to each other, you wrote bespoke glue code: custom serialization, custom auth handshakes, custom everything. In a multi-agent system, a coordinator agent managing the work and specialist agents executing specific tasks had to be wired together by hand - the coordinator needed to know exactly how each specialist worked, what inputs it accepted, and how to parse its outputs. That was the integration tax every team paid.
The Agent2Agent (A2A) protocol, initially introduced by Google in April 2025, is the attempt to standardize that contract away. At its one-year mark, the protocol - now hosted by the Linux Foundation - has surpassed 150 supporting organizations and moved from initial release to a production-ready open standard.
Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively into their platform offerings. That breadth matters: IBM's ACP (Agent Communication Protocol) merged into A2A under LF AI & Data in August 2025 - A2A's largest potential competitor joined it voluntarily.
What A2A actually does
The clearest way to understand A2A is to understand what it is not. It is not MCP. Where MCP connects an agent to tools and data, A2A connects one agent to another. They are designed to be used together. A retail store's inventory agent might use MCP to interact with databases storing product and stock information; 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.
Mechanically, A2A is built on familiar plumbing. The protocol runs on HTTP, JSON-RPC, and Server-Sent Events. There are no new standards to learn - if you know how REST APIs work, the mechanics will feel familiar.
The primitive at the center of everything is the Agent Card.
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 officially hosted at /.well-known/agent-card.json under the agent's base URL, retrievable via a simple HTTP GET request.
Instead of requiring a central directory or human configuration, an orchestrating agent fetches another agent's card, reads what it does, and decides whether to delegate a task to it.
That card is not static. A2A offers a dynamic capability registration process where agents can advertise new functions as they become ready - substantially different from traditional capability exchange systems that need session resets to handle new capabilities.
Agents can also set up detailed access control based on client identity, authentication status, or other factors - for instance, showing different capabilities to authenticated versus anonymous callers.
Once discovery happens, the protocol defines a task as its unit of work. A task represents a unit of work needed to accomplish a request - it has a unique ID and progresses through a lifecycle of defined states: submitted, working, input-required, completed, failed.
Many A2A implementations also support streaming updates via Server-Sent Events so that a long-running agent task can report intermediate progress rather than behaving like a single blocking API call. That last point matters a lot in practice: agent work is usually slow, multi-step, and contingent.
Authentication is a discoverable contract too: each agent publishes its supported auth methods in the Agent Card under
securitySchemes, and then declares the required permissions per skill.
What is genuinely new here
The architectural idea - agents discovering and delegating to each other - is not new. Research multi-agent systems have existed for decades, and frameworks like CrewAI and LangGraph already handle multi-agent workflows. The difference is that earlier orchestration frameworks automate multi-agent workflows within their own ecosystems, while A2A acts as a messaging tier that lets agents "talk" to each other despite distinct architectures.
Google's ADK, for example, supports A2A natively, which means an ADK agent can discover and invoke an agent built with LangGraph or CrewAI through A2A's standardized task interface. Cross-vendor, cross-framework delegation that doesn't require either side to expose its internals - that's the part that is actually new at this scale.
The practical payoff that adoption seems to confirm: eliminating "spaghetti integrations" by giving organizations a reusable, auditable way to compose specialist agents into cross-domain workflows, without forcing a single framework, model, or toolchain.
Where it is honest to be skeptical
The spec is tidy. Production reality is messier.
A2A is still early-stage, and some missing pieces matter for production-grade orchestration: there's 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.
The trust problem is the sharpest one. Cross-agent prompt injection is a safety vulnerability where malicious instructions embedded in content processed by interconnected AI agents cause one agent to pass or execute harmful commands in another agent's context. A2A does not include any specific security control against this.
The Agent Card itself is an attack surface. Agent Cards are often treated as trusted metadata sources; when fields like description, skills, or example prompts are directly embedded into client-agent system prompts without filtering or context isolation, malicious cards can manipulate downstream LLM behavior.
An attacker can clone a legitimate agent's card, register the rogue agent at a similar-looking domain, and wait for misconfigured client agents to discover it - and without cryptographic verification of the card's origin, clients have no reliable way to distinguish the real agent from the copy.
A2A and MCP provide the plumbing for agent interoperability, but they do not yet enforce the fine-grained confidentiality, integrity, and consent guarantees required for sensitive data exchange.
None of this is a reason to avoid the protocol. It is a reason to treat it the way you treat any HTTP API that handles sensitive work: authenticate properly, validate all inputs, apply least-privilege, and don't trust capability declarations from agents you don't control.
The one-year verdict
A2A moved faster than most open standards do. The Linux Foundation hosting, the IBM ACP merger, and platform-level integration at Google, Microsoft, and AWS mean there is no serious competing standard on the horizon. Vertical adoption already spans supply chain, financial services, insurance, and IT operations, where organizations use A2A to coordinate autonomous systems across tools, vendors, and environments.
The Agent Card is a small thing that does consequential work. A teammate like Beagle - living inside Slack or Teams, receiving delegated tasks from orchestrators - is exactly the kind of agent that benefits from a stable discovery contract: one JSON file that says what it knows how to do and how to authenticate with it.
What the protocol cannot do is make trust automatic. Two agents that have never met, exchanging tasks over HTTP, are not inherently safer than two humans exchanging emails. The handshake is standardized. The judgement about whether to trust the other party still belongs to the people who built the system.