HN Debrief

Ask HN: Is anyone using the A2A protocol?

  • AI
  • Developer Tools
  • Enterprise Software
  • Infrastructure

The post asks whether Google’s A2A protocol has moved from idea to real use. A2A is meant to let software agents discover each other, describe their capabilities through an Agent Card, and coordinate work over common patterns like polling, streaming, and webhooks. In practice, the answers landed on a narrower reading: A2A is seeing some use inside enterprises and Google-adjacent stacks, but it has not become the obvious standard for most builders. The strongest concrete adoption signal came from one commenter tracking package downloads, who put A2A far behind MCP and said its real traction is with enterprise platforms such as Gemini Enterprise, AgentForce, watsonx Orchestrate, and SAP Joule.

If you are building now, treat A2A as a compatibility layer for enterprise ecosystems, not as the default foundation for agent systems. Prioritize plain APIs or MCP unless you specifically need cross-team agent catalogs, long-running workflows, or integration with Google and large enterprise platforms.

Discussion mood

Mostly skeptical and underwhelmed. People see some enterprise and Google ecosystem usage, but the dominant view is that A2A is ahead of the actual need, overcomplicates simple cases, and trails MCP badly where adoption and immediate utility matter.

Key insights

  1. 01

    Enterprise adoption is about packaging, not autonomy

    A2A’s real appeal is boring in a good way. It gives teams one shape for agent endpoints, one metadata document for discovery, and built-in support for long-running tasks. That explains why it shows up in enterprise platforms. It is less about agents improvising with each other and more about making internally built components portable across Gemini Enterprise, AgentForce, watsonx Orchestrate, and SAP Joule.

    If you sell into large companies, A2A can be worth adding as an interface even if your product is not deeply agentic. Position it as interoperability and workflow plumbing, not as a breakthrough in agent intelligence.

      Attribution:
    • benclarkeio #1
  2. 02

    Trust and evals are the missing layer

    Discovery is not enough if nobody can verify what an agent actually does. An agent directory becomes close to useless without believable evaluations that test whether an agent matches its claimed skills and behavior. That shifts attention from protocol design to verification infrastructure.

    Do not assume a registry or Agent Card creates a usable ecosystem by itself. If you want third parties to compose with your agent, publish concrete evals and acceptance tests alongside the interface.

      Attribution:
    • fizx #1
  3. 03

    Google stack support is the clearest path

    The most concrete hands-on use case mentioned was in Google tooling. Gemini CLI can connect to remote A2A agents, and Google ADK agents can be exposed over A2A with minimal work. That makes A2A feel less like a universal standard and more like a practical extension point inside Google’s own agent ecosystem.

    If your team already builds around Gemini CLI or Google ADK, A2A has a near-term integration story. Outside that stack, require stronger justification before adding another protocol.

      Attribution:
    • fhrow4484 #1
  4. 04

    Protocol fragmentation is still getting worse

    Microsoft is rebuilding parts of its agent infrastructure around AHP, the Agent Host Protocol, instead of A2A. That is a strong sign the market is not converging yet on one shared layer for agent communication and hosting. Builders are still carving the space into different abstractions for hosts, tools, and inter-agent calls.

    Design your system so the protocol boundary is replaceable. Avoid hard-wiring your product to a single emerging standard until the categories themselves settle.

      Attribution:
    • roblourens #1

Against the grain

  1. 01

    Some teams are using A2A now

    Despite the skepticism, several practitioners said they are running A2A in production or at work, even if they described it as challenging or limited. The common thread is controlled environments where teams want independently developed agents to interoperate, especially in enterprise settings or inside Google-oriented tooling. That weakens the idea that A2A is purely speculative vapor.

    Do not dismiss A2A as imaginary if your environment looks like a large organization with multiple agent teams. It already has enough real usage to matter for enterprise compatibility decisions.

      Attribution:
    • lazharichir #1
    • techwizrd #1
    • time0ut #1
    • campak #1
    • fhrow4484 #1
  2. 02

    Agent identity may be the wrong abstraction

    The critique here is deeper than “too much complexity.” A2A assumes an identifiable agent that can be discovered, addressed, and described with an Agent Card, but some builders think that model does not match how agents really work. If an agent talking to another agent is not fundamentally different from an agent passing work to its future self, then the protocol is freezing the wrong concept too early.

    Before adopting A2A, check whether your architecture truly has stable agent identities or just tasks, tools, and state transitions. If identity is fuzzy, a workflow or tool protocol may fit better than an agent registry.

      Attribution:
    • simonreiff #1
  3. 03

    Payments and access control matter more

    One commenter argued the missing primitives are not new message formats but access control, discovery, and micropayments layered on ordinary HTTP. From that view, protocols like A2A and MCP are distractions until agents can authenticate, pay for access, and operate within existing permission boundaries. The protocol surface is not the bottleneck.

    If you expect external agents to call your system, spend time on auth, quotas, and billing before polishing agent-specific wrappers. Those constraints will shape the real interface more than the protocol brand.

      Attribution:
    • kordlessagain #1

In plain english

A2A ↩
Agent-to-Agent, a protocol intended to let software agents describe themselves, discover each other, and communicate in a standard way.
Agent Card ↩
A metadata document in A2A that describes an agent’s name, capabilities, inputs, and other details so other systems can discover and use it.
AgentForce ↩
Salesforce’s platform for building and running AI agents in enterprise workflows.
AHP ↩
Agent Host Protocol, a Microsoft protocol for talking to a host that manages multiple agents or harnesses.
CLI ↩
Command-line interface, a text-based way to interact with software tools from a terminal.
Gemini CLI ↩
A command-line interface for interacting with Google’s Gemini AI tools and models.
Google ADK ↩
Google Agent Development Kit, a toolkit for building software agents.
HTTP ↩
Hypertext Transfer Protocol, the basic protocol used for communication on the web.
MCP ↩
Model Context Protocol, a standard used by AI systems to connect to external tools, data sources, and services.
Micropayments ↩
Very small digital payments, often proposed for pay-per-use access to APIs or services.
OpenAPI ↩
A machine-readable specification format for describing the endpoints, inputs, and outputs of a web API.
REST ↩
Representational State Transfer, a common web API style where software communicates over standard HTTP requests.
SAP Joule ↩
SAP’s AI assistant and agent platform for enterprise software workflows.
watsonx Orchestrate ↩
IBM’s platform for orchestrating AI assistants and agents in business processes.

Reference links

Protocol references and implementations

Talks and explainers

Payments and infrastructure