This is a submission for the Google I/O 2026 Writing Challenge
I spent the past two weeks shipping eight Gemini agents to the Google Cloud Rapid Agent Hackathon. One per partner integration: MongoDB, Elastic, Fivetran, GitLab, Dynatrace, Arize Phoenix, plus a RAG drift watcher and a Gemini-on-TrueFoundry observability dashboard. All of them are built on the Agent Development Kit (ADK 1.x), Vertex AI, and the partner's MCP server.
Then ADK 2.0 dropped at I/O. So this is the honest reflection: which parts of those eight agents would I rewrite tomorrow, which parts hold up, and what the new framework changes about how I would have started.
What stayed the same
The MCP wiring is the same shape. Every one of those agents instantiates an McpToolset against a partner's stdio or HTTP MCP server. ADK 2.0 keeps that primitive intact. Whatever else changes, the model context protocol is the stable seam, and that is the right design call. My MongoDB agent's connection logic to the official mongodb-mcp-server is verbatim copy-pasteable into a 2.0 codebase.
Vertex AI as the routing layer also stays. GOOGLE_GENAI_USE_VERTEXAI=TRUE and the Cloud Run deploy command (adk deploy cloud_run --with_ui) are unchanged. The packaging contract held.
What changes, in order of how much it bites
1. The "two MCP toolsets" pattern gets replaced by a sub-agent graph. All eight of my agents have the same shape: one McpToolset for the partner MCP, one optional second McpToolset for agent-safety-mcp as a guardrail layer. That works in 1.x. In 2.0, the right shape is a graph: a planner sub-agent that decides whether to call the partner tools or the safety tools first, with explicit edges. It is more powerful (a real "if the schema is dangerous, route to safety first" branch) and it kills the implicit ordering my 1.x prompts have to enforce.
2. The system prompt is no longer the only place orchestration lives. Today my agents enforce ordering through prose like "before answering, run validate_args on any non-trivial call." That works but it is fragile. ADK 2.0's graph framework makes the dependency explicit. I would expect the "validate before execute" relationship to migrate out of the prompt and into the graph definition, which is more readable, testable, and survives model swaps.
3. Managed Agents API simplifies the deployment story. Right now I have eight Cloud Run services, eight env-var bundles, and eight Dockerfiles. The Managed Agents API lets you spin up a custom agent in a Google-hosted environment with one call. For hackathon submissions where I need a stable demo URL judges can click, that is a real time savings. I would have used it for the four of my eight agents that do not need a custom Docker image (mostly the HTTP-MCP ones like the Elastic and GitLab agents).
What I want to test next
Cross-agent state in the graph. Several of my submissions feel like they should be one multi-agent project, not eight standalone agents. The Dynatrace investigator should be able to hand its findings to the GitLab pipeline auditor when a problem points at a recent merge. ADK 2.0's graph orchestration plus a shared state object is the natural way to model that. I will probably take a single hackathon project and re-architect it as a 4-sub-agent graph just to learn the new conventions.
Gemini 3.5 Flash as the cheap planner. Several of my agents use Gemini 2.0 Flash because it was the right cost/latency point. Gemini 3.5 Flash is the new entry, and I want to A/B it head-to-head on the same hackathon prompts. Specifically: does it reduce the per-task tool-call count, or does it spend the new capability on better answers at the same tool budget? The cost-per-correct-tool-call delta is what matters in production, and that is exactly what my eight existing agents are set up to measure.
WebMCP. I did not have a use for this two weeks ago. I do now: my GeminiLens observability dashboard could expose its analysis as a browser-native tool, so a Hermes-style personal agent running in the browser could ingest GeminiLens insights without an explicit integration. The Chrome 149 origin trial is the moment to prototype that.
What I would do differently if I started today
I would still ship the eight agents. I would not wait for ADK 2.0 patterns to settle. Hackathon deadlines do not wait for framework maturity, and the partner MCP servers were available now. But I would have known that the next round of partner-integration agents I write should be a single graph, not eight repos. And I would have spent the last day of the contest on a Managed-Agents-API redeploy to give the judges a faster cold start.
The shipping bar for an agent the day before I/O was "wires to MCP, runs on Cloud Run, ground every claim." The shipping bar the day after is "wires to MCP, runs on Managed Agents, orchestrates sub-agents through an explicit graph, every claim grounded, every model swap testable." That is a higher bar in three ways and a strictly looser bar in zero. Worth the reset.
Top comments (0)