The Agent2Agent Protocol (A2A)

Original Article ↗ Hacker News Discussion ↗

Understanding A2A vs MCP

  • Many commenters struggle to see how A2A materially differs from MCP and standard APIs; several ask for concrete end‑to‑end JSON examples “over the wire.”
  • Rough emerging consensus (including from people working on A2A/MCP):
    • MCP: “agent ↔ environment” — exposing tools, prompts, resources to a model in a standardized way.
    • A2A: “agent ↔ agent” — capability discovery, tasks, collaboration, long‑lived workflows, and messaging between otherwise isolated agents.
  • A2A adds notions like tasks, readiness, asynchronous completion, push notifications, and agent discovery via .well-known/agent.json cards.

Comparison to REST/RPC and Prior Standards

  • Multiple participants argue MCP/A2A are “just RPC over HTTP/JSON” and question why not simply use REST/OpenAPI/GraphQL with conventions like /capabilities and /task_status.
  • Others counter that:
    • Standardizing schemas and flows reduces LLM hallucination around tool use.
    • Action‑oriented RPC semantics fit better than forcing everything into pseudo‑REST.
  • Several draw parallels to SOAP/WSDL, CORBA, FIPA, KQML, Agent Tcl/D’Agents, seeing this as another cycle of over‑engineered interop standards.

Security, Prompt Injection & “Agent Worms”

  • MCP itself is seen as protocol‑sound but dangerous in practice: exposing tools that act on behalf of users while ingesting untrusted text is highly prompt‑injection‑prone.
  • Key points:
    • Any toolset an agent can access must be considered one security boundary; you must be comfortable with any combination of tool use, not just intended workflows.
    • Human‑in‑the‑loop is recommended in MCP, but not mandated; “vibe coding” patterns actively try to remove humans.
    • Several argue that arbitrary third‑party content + privileged tools is fundamentally unsafe; sandboxing helps but doesn’t solve core social‑engineering‑like risks.
  • A2A raises additional concern about “agentic worms” propagating across agents in loosely supervised networks.

Motivations, Strategy & Ecosystem Control

  • Many interpret A2A as a strategic land‑grab: owning the “agent interop” layer, enabling agent marketplaces, billing, and SaaS for agents on top of Google Cloud.
  • The long list of big consultancies and enterprise vendors as “partners” is widely seen as a red flag: more about selling billable‑hours ecosystems and agent registries than solving core technical problems.
  • Others push back that A2A is Apache‑licensed, open, and could be used in air‑gapped environments, so any “moat” would be more ecosystem/social than legal.

Perceived Usefulness & Real-World Agents

  • There’s skepticism about the value of LLM‑to‑LLM/agent‑to‑agent chains vs. having one agent call deterministic APIs:
    • Agents are often just rebranded workflows; many question real production use beyond demos.
    • Some see genuine need in complex enterprise setups: a company “main agent” coordinating with external HR, travel, tax, or facilities agents that own private data and workflows.
  • Others argue existing MCP tool servers could already wrap such “agents” without A2A.

Spec Quality, Developer Experience & Protocol Fatigue

  • Some early readers find the A2A spec promising—a “sane superset” that addresses MCP pain points (auth, discovery, out‑of‑band data, state).
  • Others call it underspecified (timestamps, session IDs, field limits, auth extensibility) and warn of fragmentation, incompatible “extensions,” and enterprise complexity.
  • Strong desire across the thread for:
    • Concrete, prettified JSON traces and message examples.
    • Clear examples of how LLM outputs trigger tool/agent calls.
  • Many express exhaustion with rapidly proliferating, overlapping protocols and acronyms (MCP, A2A, vendor‑specific agent SDKs), seeing “architecture astronaut” behavior instead of focusing on robust solutions.