This is a submission for the Google Cloud NEXT Writing Challenge
I Built Multi-Agent Systems Before NEXT '26 — Here's What the New ADK, MCP & A2A Stack Actually Changes
I'll be honest: when Google Cloud NEXT '26 started announcing updates to the agent platform, my first reaction wasn't excitement — it was relief.
Over the past few months, I've been systematically building up on the Google Cloud agent ecosystem — starting from the Cloud Technical Series OnBoard Edition (January 2026, hands-on AI Agents), then AI in Action (March 2026, Gemini Enterprise & agentic CX), through Code Vipassana Season 14 ("Building Serverless Data Agents", Outstanding rating), and finally the Gen AI Academy APAC Edition where I built and deployed a live Multi-Agent Productivity Assistant on Cloud Run. I've written real code with ADK, integrated MCP tools, debugged agent routing issues at 11pm, and even submitted a PR to the MCP Toolbox Java SDK to fix a broken run command that was tripping up developers.(https://github.com/exedistrict-ux/mcp-toolbox-sdk-java/pull/1) to fix a broken run command that was tripping up developers.
So when I say the announcements at NEXT '26 — specifically around ADK, MCP becoming universal, and the A2A Protocol — are genuinely meaningful, I'm not speaking as someone who read a blog post. I'm speaking as someone who felt these pain points firsthand.
Let me show you exactly what changed and why it matters.
The Pain I Was Solving (Before NEXT '26)
In my Gen AI Academy project, I built a multi-agent system with a ProductivityCoordinator primary agent that routed requests to three sub-agents: TaskAgent, NotesAgent, and CalendarAgent — all deployed serverlessly on Google Cloud Run.
The architecture worked. But building it was messier than it should have been.
The biggest friction points were:
1. Tool integration required too much manual wiring. Connecting each sub-agent to its data source meant writing custom adapter logic every time. There was no standard interface — you just hoped your patterns were consistent.
2. Agent-to-agent communication was hardcoded. My ProductivityCoordinator knew about TaskAgent, NotesAgent, and CalendarAgent at build time. If I wanted to add a new sub-agent, I had to modify the coordinator's routing logic manually. There was no discovery mechanism.
3. MCP tools existed, but weren't seamlessly integrated. I integrated three MCP tools as sub-agents in my project. It worked, but it required explicit configuration for each one. The dream of "just point your agent at a service and it works" wasn't quite reality yet.
Now look at what NEXT '26 announced.
1. ADK: From Pattern to Platform
When I built my multi-agent system, I was following the ADK pattern — primary agent coordinating sub-agents, tools attached via function definitions, deployed on Cloud Run. It worked, but I was essentially implementing the pattern myself with Flask and Python.
The ADK announced at NEXT '26 formalizes all of this. The AgentRuntime handles what I was doing manually: session management, scaling, retry logic, state persistence across requests.
Here's roughly what my coordinator looked like before:
# My Gen AI Academy project — manual routing
class ProductivityCoordinator:
def route(self, message: str):
if "task" in message.lower():
return self.task_agent.handle(message)
elif "note" in message.lower():
return self.notes_agent.handle(message)
elif "calendar" in message.lower():
return self.calendar_agent.handle(message)
elif "dashboard" in message.lower():
# Multi-step: call all three simultaneously
return self.aggregate_all(message)
With the new ADK, the AgentRuntime handles the plumbing. You focus on defining skills and tools — not writing routing logic from scratch.
from google.cloud.agents import ADK, Tool
@Tool(name="manage_tasks", description="Add, list, or complete tasks")
def manage_tasks(action: str, task_title: str = None) -> dict:
# Your task logic here
return result
agent = ADK.create_agent(
name="productivity-coordinator",
model="gemini-2.0-flash",
tools=[manage_tasks, manage_notes, manage_calendar]
)
This isn't a trivial improvement. The boilerplate I wrote for my Code Vipassana S14 project would shrink dramatically.
2. Universal MCP: The Integration Problem, Solved
This is the announcement that made me stop and re-read twice.
Every Google Cloud service is now MCP-enabled by default.
In Code Vipassana Season 14, one of the sessions I attended was specifically on building secure multiagent systems with Model Armor and MCP Toolbox for Databases. I also attended the session on building a schema-aware agent with BigQuery. In both cases, MCP tools required explicit setup — you had to define the connection, configure credentials, and write the integration.
That's now gone. Here's what the new model looks like:
{
"protocol": "mcp",
"tool": "bigquery.query",
"parameters": {
"project_id": "my-project",
"query": "SELECT * FROM productivity.tasks WHERE status = 'pending'"
}
}
Your agent sends a standard MCP request. The Cloud service handles auth, execution, and returns a standardized response.
I actually found the typo in the MCP Toolbox Java SDK's README while working through one of these integrations — the run command said mvn sprint-boot:run instead of mvn spring-boot:run. A small thing, but the kind of friction that breaks developer flow. I submitted a PR to fix it. The broader point: this tooling was still rough. Universal MCP support is Google acknowledging that and doing something about it.
3. A2A Protocol: The Missing Piece in My Architecture
This is the one that would have changed my Gen AI Academy project the most.
My ProductivityCoordinator was hardcoded. It knew its sub-agents at build time. That's fine for a bounded project, but it doesn't scale. If you want a genuinely modular agent architecture — where new specialists can be added without modifying the orchestrator — you need a discovery mechanism.
The Agent-to-Agent (A2A) Protocol and Agent Registry are exactly that.
# How my Gen AI Academy project COULD have been built
registry = AgentRegistry.connect()
# Coordinator dynamically discovers what's available
available_agents = registry.find_agents(domain="productivity")
# Routes to the right specialist at runtime — not build time
result = await available_agents.route(
task=user_message,
context=session_context
)
With A2A, adding a new sub-agent (say, an EmailAgent) doesn't require touching the coordinator at all. It registers itself, announces its capabilities, and the orchestrator discovers it dynamically.
This is what I was manually approximating. Now there's a protocol for it.
Memory Bank: The Problem I Didn't Fully Solve
In my productivity assistant, state was in-memory per session. Tasks, notes, and calendar events persisted within a session but not across them. That was fine for a demo, but in production it's a real limitation.
Memory Bank addresses this directly — agents can store and retrieve context across sessions using semantic similarity:
agent = ADK.create_agent(
name="productivity-coordinator",
memory=MemoryBank(
store="long_term",
retrieve_strategy="semantic_similarity"
)
)
A user's task priorities, their preferred working style, their recurring meeting patterns — all of this can now persist. This is the difference between a demo and a product.
What I'm Still Watching
A few honest caveats from someone who has been in the weeds:
Agent Identity and IAM integration is the piece I'm most cautious about. In my Code Vipassana S14 session on secure multiagent systems, we saw how quickly authorization complexity compounds when you have multiple agents accessing different data sources. The Agent Identity feature looks right architecturally — each agent gets its own service account — but I'll want to see how it handles cross-agent delegation in practice before trusting it in a production billing or HR system.
The "serverless" promise depends heavily on cold start behavior. My Cloud Run deployment for the productivity assistant had noticeable cold starts. Agent Runtime inherits Cloud Run's runtime, so the same tradeoffs apply. For latency-sensitive agentic workflows, this matters.
A2A's Agent Registry is only as useful as what's registered in it. The discovery mechanism is elegant, but in a real enterprise environment, you'll need governance around what gets registered and how capabilities are described. That's an organizational challenge as much as a technical one.
The Full Picture
Here's how the stack connects, from my perspective as someone who has built pieces of this manually:
User Request
│
▼
Orchestrator Agent (ADK + AgentRuntime)
│
├── MCP ──► Any Google Cloud Service (BigQuery, Spanner, GCS...)
│ [No custom adapters. Default on everything.]
│
├── A2A ──► Agent Registry ──► Specialist Agents
│ [Dynamic discovery. No hardcoded routing.]
│
├── Memory Bank
│ [Persistent context across sessions.]
│
└── Agent Gateway + Agent Identity
[IAM at the agent level. Centralized policy.]
Six months ago, I was building the middle three layers by hand. ADK gave me the pattern but not the platform. MCP tools existed but weren't universal. Agent-to-agent communication was ad-hoc.
NEXT '26 is Google Cloud saying: we're making this the platform, not just a pattern.
Where to Start
If you want to get hands-on with this stack:
- Code Vipassana — The lab series I went through. Season 14 covered serverless data agents end-to-end. Highly recommend the ADK and MCP sessions specifically.
- Gen AI Academy APAC Edition — Cohort 1 just wrapped. Watch for the next cohort if you want structured hands-on time with the full stack.
- ADK Docs: cloud.google.com/agent-development-kit
- A2A Protocol: cloud.google.com/a2a
The NEXT '26 Developer Keynote sessions are available on the DEV homepage — the demos of ADK + MCP + A2A working together are worth watching even if you've read all the docs.
I'm Gaurang Bhatt — Code Vipassana Season 14 Troubleshooter, Gen AI Academy APAC participant. Currently building on Google Cloud and occasionally fixing typos in SDKs at odd hours. What are you building with the new agent stack? Drop it in the comments.
Top comments (0)