Alternatives, adjacent efforts, and the architect’s question

ACP — merged, not competing

The Agent Communication Protocol came out of IBM’s BeeAI project as a REST-first interop protocol under the Linux Foundation. Its site now states it is part of A2A and publishes a migration guide. If you inherit an ACP integration, your forward path is documented; if you are choosing today, ACP is not a live alternative.

AGNTCY — complementary infrastructure, not a rival protocol

AGNTCY (“Building the Internet of Agents”) is an open-source interop stack organised as “AGNTCY a Series of LF Projects, LLC”, with a Technical Steering Committee of Cisco, Dell, Google, Oracle, and Red Hat. Its components cover federated agent discovery, the SLIM secure messaging protocol, identity, observability, and OASF schemas.

It positions itself as complementary rather than as an A2A competitor — its AgentBridge component connects coding agents and other CLIs over A2A. The interesting read: A2A standardises the conversation; AGNTCY is attacking the surrounding infrastructure (registries, identity, telemetry) that A2A deliberately leaves out — remember, the spec prescribes no registry API.

ANP — a community effort, sized honestly

The Agent Network Protocol is a separate, GitHub-hosted protocol stack for the “Agentic Web”, covering decentralised identity (DID:WBA), discovery, messaging, and payments; ANP 1.1 uses a three-layer architecture and adapts AP2 for its payment layer.

Its site names no corporate backers and no standards-body affiliation, and its adoption signals are far weaker than A2A’s. Read it as an experimental community project with interesting ideas about decentralised identity — not as an industry alternative you can staff a roadmap on.

AP2 and x402 — the extension ecosystem

Google announced the Agent Payments Protocol (AP2) in mid-September 2025 with more than 60 organisations including American Express, Coinbase, Mastercard, PayPal, and Worldpay. AP2 “can be used as an extension of the Agent2Agent (A2A) protocol and Model Context Protocol (MCP)” — payments layered on top rather than baked into either core. An A2A x402 extension for crypto payments shipped alongside it with Coinbase, the Ethereum Foundation, and MetaMask.

How extensions stay out of the core

A2A supports protocol extensions and custom bindings, negotiated with the A2A-Extensions header, and the project describes a tiered promotion process for capability additions specifically so the core stays stable.

That is the structural answer to “will this protocol bloat?” — vertical concerns like payments, industry-specific metadata, or bespoke transports live in extensions and get promoted only if they earn it. When you evaluate an integration, check which extensions the other side requires; a shared core version does not imply a shared extension set.

Do you actually need agent-to-agent interop?

Interactive decision tree — outcomes:

• Supervisor-worker, in process. No protocol.

  One repo, one deploy: call the function. You get no benefit from a wire protocol and you avoid latency, partial failure, credential rotation, and version skew. Revisit only when something genuinely detaches — a separate team, a separate release train, or an external consumer.

• Wrap it as an MCP tool.

  Stateless in, typed out, no conversation to have — that is the vertical axis. The A2A docs themselves allow such skills to be exposed as MCP-compatible resources, so you are not bending anyone’s intent. Simpler contract, fewer states, no lifecycle to manage.

• Your existing RPC or queue is probably enough — but steal the task model.

  Two known internal services can talk over whatever you already operate and monitor. What is worth borrowing from A2A regardless is its task shape: a server-owned id, an explicit lifecycle with terminal and interrupted states, and outputs as addressable artifacts. Most home-grown agent-to-agent calls fail because they lack exactly that, not because they lack a standard.

• Adopt A2A internally — with direct configuration.

  Many agents and unknown future consumers is the case where a standard pays: one client implementation, N providers, no bespoke adapters. Use direct configuration or a curated registry you own rather than public well-known discovery, pin the A2A-Version you tested, and record which capability flags each agent actually implements.

• A2A is the right call — pilot it like a preview.

  Cross-organisation, stateful delegation is the case the protocol was built for. Given September 2026 support levels, treat it as a pilot: pin versions and bindings, exchange capability matrices with the other side (transport, modality, streaming) before you promise behaviour, keep credentials least-privilege, treat inbound cards and artifacts as untrusted input, and wire CancelTask to a real kill-switch.

• Ship a bespoke contract now, shaped like A2A.

  If nothing preview-labelled can carry the launch, agree a narrow API or webhook contract with the partner — but model it on A2A: server-generated task ids, an explicit state enum with interrupted states, artifacts separate from conversation. When platform support hardens, migration is a translation layer rather than a redesign. That is the same route ACP integrations took into A2A.