A2A Hit 150 Orgs — Why Most Agent Pilots Still Fail

Agent2Agent just crossed 150 supporting organizations in its first year under the Linux Foundation. Most enterprises still can't get a single agent pilot to production.

The Adoption Numbers Are Real

A2A turned one year old in April 2026 with growth that looks genuinely impressive on paper: more than 150 supporting organizations, up from roughly 50 twelve months earlier, over 22,000 stars on the core repository, and SDKs shipping in Python, JavaScript, Java, Go and .NET. Azure AI Foundry, Amazon Bedrock AgentCore and Google Cloud's Agent Development Kit all ship it. The protocol also picked up real technical maturity along the way — version 0.3, released in August 2025, added gRPC as an alternate transport and JWS-signed Agent Cards, closing a gap where an unsigned Agent Card was just an unauthenticated JSON file sitting at a predictable URL.

What A2A Actually Solves — and What It Doesn't

The protocol's own documentation draws a clean line: MCP wires an agent to tools; A2A wires an agent to other agents, possibly running on a different vendor's stack, in a different language, owned by a team you never talk to. An Agent Card — a JSON document published at /.well-known/agent-card.json — lists what an agent can do and how to authenticate with it, so agent A never has to learn how agent B was built.

That design earns its keep in a specific situation: when the other agent is genuinely outside your control, when the interaction is a real multi-turn task rather than a single function call, or when you need to discover capabilities at runtime instead of hardcoding them. It does not earn its keep everywhere. As one practitioner write-up on the protocol put it, plenty of A2A demos show three agents accomplishing what three function calls would — standing up an Agent Card, a task store, and JSON-RPC plumbing for a single in-process call is pure overhead. The same analysis argues the 150-organization number should be read as an interoperability signal, not proof of production load — the number that would actually prove production use is how many teams keep the integration after their first authentication failure and compliance review, and that number is far smaller.

The Pilot Trap: Why Tooling Maturity Isn't Adoption

That gap between protocol maturity and production reality shows up directly in enterprise agent programs. Microsoft's 2026 Agentic Transformation Patterns Playbook names "many pilots, no portfolio" as the first of five scale-breakers most enterprises hit. One practitioner analysis of that framework reports that, in its observation of mid-sized to large enterprises through the back half of 2026, roughly 80-90% of agent pilots either fail outright or settle into a permanent pilot state — never retired, never scaled, just consuming budget at low levels indefinitely.

The same analysis offers a diagnostic: an organization is in the pilot trap when it has five or more AI agent pilots, no clear portfolio owner, no defunding decision in the past 12 months despite at least one stalled pilot, no shared infrastructure across pilots, and no quarterly review that forces an explicit go/no-go call.

How to Tell If You're Actually Ready to Graduate

The same source lays out a six-point graduation test: a pilot is ready to move from pilot to portfolio status only when it has produced measurable business value against pre-defined KPIs, has a named owner who can take it to production, can run on shared infrastructure without a custom rebuild, has a risk-tier classification with appropriate controls, has executive sponsor commitment to fund the graduation work, and has its failure modes characterized with a response plan. A pilot meeting three or fewer of those, the analysis argues, should be retired honestly rather than left to consume budget by inertia. Building that shared infrastructure isn't free — the same practitioner estimate puts the platform-engineering investment at roughly 1-2 FTEs of dedicated work over a 6-12 month period, a number the source itself frames as a starting point to calibrate, not a fixed rule.

Three Ways Organizations Fool Themselves

The same practitioner analysis names three anti-patterns that produce visible activity without ever producing a real portfolio. The "pilot factory" authorizes new pilots faster than it retires old ones, so the inventory keeps growing while investment per pilot stays low. The "lighthouse pilot that never extends" ships one flagship pilot to production with full discipline and showcases it as proof the program works, but the infrastructure behind it is too custom to reuse, so the next ten pilots restart from scratch. The "vendor-led pilot suite" runs well while an outside vendor or systems integrator is driving it, then degrades once the engagement ends because it never built in-house capability. All three look like progress on a slide deck while producing none of the discipline a real portfolio requires.

What to Watch Next

The recommended fix compresses into a 90-day sequence: days 0-30 for a full inventory and triage of every pilot, days 30-60 to name a portfolio owner with real defunding authority and pick the first graduation candidate, and days 60-90 to start the shared-infrastructure build that the second and third graduating agents can reuse. If you're evaluating A2A for a new project, the practical filter is simpler than the protocol spec: skip it if a direct API call, a shared MCP server, or in-process orchestration already does the job, and only reach for it when the other agent is genuinely outside your control.