Google’s A2A Protocol Moves into the Agentic AI Foundation

A2A Gets a Neutral Home

Google’s Agent2Agent protocol, better known as A2A, is moving into the Agentic AI Foundation as a hosted project. The governance shift matters because a standard meant to connect agents from different vendors needs credibility beyond its original creator. Foundation stewardship gives developers and companies a more neutral venue for specifications, releases and long-term decision-making.

A2A is designed for one agent to discover another agent’s capabilities, delegate work, exchange progress and receive results. That is different from assuming every agent lives inside one application or vendor stack. Google’s contribution does not instantly make the protocol universal, but it gives the emerging ecosystem a shared technical starting point and a governance structure built for participation.

How A2A Differs From MCP

A2A and the Model Context Protocol address neighboring layers. MCP commonly connects a model or agent to tools, data and services. A2A focuses on coordination between agents that may have their own models, tools and internal logic. A travel-planning agent might use MCP to query a calendar, then use A2A to ask a separate expense-policy agent whether an itinerary complies with company rules.

The protocols can therefore complement each other rather than compete for one slot. MCP helps an agent reach capabilities; A2A helps capable agents collaborate. Real systems may use both, alongside ordinary web authentication, queues and APIs. The architecture becomes valuable when developers can replace one component without rewriting the entire workflow.

What the Protocol Standardizes

A2A documentation describes mechanisms such as agent cards for capability discovery and structured task exchanges built around familiar web technologies, including JSON-RPC. Standard messages can reduce bespoke integration work, especially when a task is long-running or produces multiple artifacts. They do not standardize an agent’s private reasoning or require every implementation to use the same model.

That boundary is important. Organizations can expose a controlled description of what an agent does while keeping its internal systems separate. A shared envelope also makes observability more practical: platforms can trace task states, failures and handoffs with consistent concepts. But specifications must stay precise as implementations encounter retries, partial results, versioning and conflicting expectations.

Governance Does Not Solve Security

Interoperable agents widen the trust boundary. A receiving agent must know who sent a task, what authority accompanies it and whether returned content is safe to use. Agent cards can be misleading, credentials can be overbroad and an apparently simple delegation can trigger consequential actions. Production deployments still need authentication, authorization, validation, rate limits, audit logs and human approval for sensitive steps.

The foundation move is consequently an institutional milestone, not an assurance that multi-agent systems are ready for every workload. Adoption will depend on compatible implementations, conformance testing and evidence that operators can diagnose failures across vendors. If contributors handle those unglamorous details well, A2A could become connective tissue for agentic software rather than another short-lived integration layer.

What Adoption Will Reveal

The next phase will be measured in implementations rather than announcements. Developers need stable software kits, test suites, version negotiation and examples that cover more than a happy path. Documentation must also explain recovery when agents time out, disconnect or return incomplete work. Buyers will look for multiple independent agents completing the same workflows without vendor-specific glue. A protocol becomes infrastructure only when switching costs fall and operators can predict behavior during failures.

Identity is likely to be one of the hardest tests. An agent may act for a user, a department or another service, and those authorities should not blur during delegation. Systems need a way to carry limited permissions without forwarding powerful credentials. They must also record which agent requested an action, which policy allowed it and which human can intervene when a chain behaves unexpectedly.

Neutral governance can help resolve these issues openly, but participation must remain balanced. If one vendor supplies most code and direction, formal hosting alone will not create a genuinely shared standard. Public roadmaps, documented decisions, conformance work and maintainers from several organizations are stronger signals. Clear intellectual-property terms and an accessible contribution process will matter for smaller implementers, too. The foundation’s success will ultimately be visible in boring reliability, portable integrations and accountable control, not the number of logos on a launch page.

What Readers Need to Know