Google Cloud NEXT '26 dropped 50+ announcements. The one that changes everything isn't the shiny AI model. It's a protocol.
Everyone came to Google Cloud NEXT '26 for the model war — Gemini 3.1, the Apple-Gemini bombshell, TPU 8t connecting 134,000 chips into a single Virgo fabric. Those headlines are real. But buried beneath the flash is the announcement that defines how software is actually built in 2027 and beyond:
Agent2Agent (A2A) protocol v1.0 is in production at 150 organizations. The Linux Foundation now governs it. And it's already baked into six major frameworks.
That's not a product announcement. That's infrastructure. And infrastructure is where all the leverage lives.
Why Multi-Agent Systems Have Been Broken
Let's strip the marketing away.
An agent is just a loop: observe → reason → act → repeat. The moment you need two agents to collaborate — a procurement agent handing off to a finance agent, a customer service bot escalating to a specialist — you hit a fundamental problem:
How do they talk?
Today, most "multi-agent" systems are secretly monoliths. They use shared memory, shared queues, or vendor-specific SDKs that chain agents together within one platform. It works until you need your Salesforce Agentforce bot to hand a task to your ServiceNow agent. Then you write glue code. Then you maintain it. Then you regret your life choices.
This is the exact same problem the internet solved in the 1990s. Before HTTP, every web server talked a different language. After HTTP: one protocol, universal interoperability, an explosion of innovation. A2A is making the same move for agents.
What A2A v1.0 Actually Delivers
1. Agent Cards — The DNS of the Agent World
Every A2A-compliant agent publishes an Agent Card: a JSON manifest served at /.well-known/agent.json that declares what the agent can do, what inputs it accepts, what auth schemes it supports, and how to reach it.
{
"name": "Procurement Agent",
"version": "1.2.0",
"capabilities": ["create_purchase_order", "check_vendor_status", "approve_spend"],
"input_schema": {
"type": "object",
"properties": {
"vendor_id": { "type": "string" },
"amount_usd": { "type": "number" }
}
},
"auth": { "schemes": ["oauth2", "api_key"] },
"endpoint": "https://procurement-agent.acme.com/a2a"
}
This is discovery. This is what lets a general-purpose orchestrator find and call a specialist agent without prior integration work. It's DNS + OpenAPI, applied to agents.
2. Task Lifecycle — State That Survives Handoffs
A2A defines a standard task state machine: submitted → working → input-required → completed/failed/cancelled. Real enterprise tasks take minutes to hours, not milliseconds. A2A task state lives in the protocol, not in one vendor's database — so it survives network interruptions, agent restarts, and platform migrations.
3. Streaming & Push Notifications
A2A supports Server-Sent Events for streaming task updates. Long-running agents push incremental progress back to the orchestrator without polling. For a research agent crawling documents for 20 minutes, this isn't a nice-to-have. It's the difference between a system that works and one that times out.
The Code That Matters
Here's a minimal A2A agent server using the new ADK v1.0 (Python, stable release):
from google.adk.agents import LlmAgent
from google.adk.a2a import A2AServer, AgentCard, Capability
card = AgentCard(
name="inventory-checker",
version="1.0.0",
capabilities=[
Capability(
name="check_stock",
description="Returns current inventory level for a given SKU",
input_schema={"sku": "string"},
output_schema={"quantity": "integer", "warehouse": "string"}
)
]
)
agent = LlmAgent(
model="gemini-3-flash",
system_prompt="You check inventory. Be precise and fast.",
tools=[check_inventory_db]
)
server = A2AServer(agent=agent, card=card, port=8080)
server.start()
# → GET /.well-known/agent.json (Agent Card discovery)
# → POST /a2a/tasks/send (Task endpoint)
And calling it from an orchestrator:
from google.adk.a2a import A2AClient
client = A2AClient()
# Auto-fetches the Agent Card
inventory_agent = await client.discover("https://inventory.acme.com")
# Send a task
task = await inventory_agent.send_task({
"capability": "check_stock",
"input": {"sku": "WIDGET-42"}
})
# Stream progress in real time
async for update in task.stream():
print(f"Status: {update.status} | {update.message}")
result = await task.result()
print(f"Stock: {result['quantity']} units at {result['warehouse']}")
This runs cross-platform. The inventory agent could be on Agent Engine. The orchestrator could be LangGraph, CrewAI, or AutoGen. A2A bridges them without custom serialization or SDK lock-in.
The Ecosystem Play Is Already Working
The number that should get your attention: 150 organizations in production — not pilot.
Google announced A2A at Google I/O 2025 with 50 partners on paper. Twelve months later, it's in live production at 150 organizations, and governance has moved to the Linux Foundation's Agentic AI Foundation. That last detail is critical — it signals A2A is not a Google product anymore. It's an industry standard in the making, the same way the Linux Foundation stewards Kubernetes, OpenTelemetry, and gRPC.
Native A2A support now ships in:
- Google's ADK (Python, Go, Java, TypeScript — all stable v1.0)
- LangGraph
- CrewAI
- LlamaIndex Agents
- Microsoft Semantic Kernel
- AutoGen
When Microsoft's framework supports your protocol, you've won the framework war before it started.
My Honest Critique: What's Still Missing
I'm not here to write a press release. So let me be direct.
1. Security model is immature.
A2A supports OAuth2 and API keys — table stakes. But there's no standard for capability scoping, no canonical way to say "this orchestrator can call check_stock but not approve_spend." In enterprise environments, this granular authorization matters enormously. Today you implement it yourself.
2. Agent Card versioning is undefined.
What happens when an agent upgrades from v1.0.0 to v2.0.0 and changes a capability schema? A2A has no deprecation protocol, no capability negotiation, no backward-compatibility guarantees baked in. Every integration team will solve this differently until a standard emerges.
3. Observability is an afterthought.
There's no standard tracing header in A2A requests — no X-A2A-Trace-ID spec. When a task flows through five agents across three platforms and breaks, you're currently stitching together vendor-specific logs to reconstruct what happened. OpenTelemetry support is on the roadmap. It can't come fast enough.
These aren't dealbreakers. HTTP 1.0 didn't have keep-alive. It evolved. A2A will too. But go in clear-eyed.
Why This Is the Most Underrated Announcement of NEXT '26
Everyone will write about Gemini 3.2's expanded context window. Everyone will write about TPU 8t (Sunfish) and the Virgo Network connecting over a million chips into a single logical training cluster. Those are real stories.
But here's the thing about infrastructure: the network effects compound silently until they're obvious.
TCP/IP didn't make the front page when it shipped. Neither did HTTP. They became the substrate on which everything else ran. A2A — now stable, governed by a neutral foundation, adopted across competing frameworks — is positioning itself as the substrate for multi-agent systems.
The developers who understand it now, who build A2A-compliant agents and orchestrators that can discover any A2A endpoint, are the ones with a durable advantage as the agentic era matures. Not because Google said so in a keynote. Because 150 production deployments and Linux Foundation governance are the kind of signals that don't reverse.
What to Do This Week
- Read the A2A spec: google.github.io/A2A — clean, short, worth 20 minutes.
-
Install ADK v1.0:
pip install google-adk— stable, production-ready. -
Expose your next agent with an Agent Card. Treat it like a
README.md: required, not optional. - Watch the Developer Keynote (April 23, 10:30 AM PT) — live A2A cross-platform interop demos.
The agentic era isn't coming. It's here. And now it has a protocol.
Posted as part of the Google Cloud NEXT '26 Writing Challenge on DEV.
Top comments (0)