Google ADK 2.0 Makes Agent Workflows Look Less Like Prompt Soup

Google ADK 2.0 is the part of the agent-platform story that actually matters after the keynote lights go down. Not because it gives developers another place to say “agent,” but because it moves orchestration out of the prompt and into something closer to software: graphs, tasks, state, retries, typed handoffs, and places where deterministic code can do deterministic work.

That sounds less cinematic than a demo of Gemini driving an IDE. Good. Cinematic agent demos have not been the bottleneck. The bottleneck has been building systems that a tired engineer can debug on Monday morning without reading 400 turns of transcript archaeology.

Google’s ADK Python v2.0.0, published May 19, marks Agent Development Kit 2.0 as generally available. The Python repo had roughly 19,758 stars, 3,417 forks, and 833 open issues during the research window, with an Apache-2.0 license and Python 3.11+ requirement. The release also comes with a real migration warning: breaking changes across the agent API, event model, and session schema. ADK 2.0 sessions are readable by ADK 1.28+ with extra fields ignored, but older 1.x versions are not compatible.

Graphs are the antidote to prompt soup

The headline capability is the new workflow runtime. ADK 2.0 supports graph execution, routing, fan-out and fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop checkpoints, and nested workflows. Google’s docs describe graph workflows as deterministic processes that combine AI reasoning with code logic: nodes, edges, branching, state, function chains that do not require model calls, and a more predictable control plane than “please decide what to do next.”

That is the right direction. The first wave of agent frameworks often treated architecture as a very long system prompt. Ask the model to plan, ask it to delegate, ask it to remember constraints, ask it to recover from failure, ask it to tell you what happened. This is fine for a hackathon demo and a terrible way to operate production workflows. In software, control flow belongs somewhere reviewable. If a migration fans out across ten services, retries only the failing step, and blocks on a human approval before deployment, that shape should be visible in code or configuration. It should not be inferred from vibes.

The second major piece is ADK’s Task API, which supports structured agent-to-agent delegation, multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in-the-loop flows, and task agents as workflow nodes. That matters because delegation is where many coding-agent systems currently lose accountability. A parent agent says “go investigate auth,” a child agent disappears into its own transcript, and the only durable artifact is a summary that may or may not include the important caveat. Structured tasks make delegation inspectable. They give the orchestration layer a thing to track, retry, approve, and audit.

The migration warning is part of the story

The breaking-change note is not an inconvenience to wave away. It is evidence that ADK 2.0 is changing the runtime surface, not just repainting names. Agent API changes affect how tools and models are invoked. Event-model changes affect observability. Session-schema changes affect replay, dashboards, persistence, and any downstream tool that assumes a particular shape of history. If your team has built evaluation harnesses or custom monitoring around ADK 1.x, this is a real framework migration.

The practitioner move is boring and correct: pin versions, run migration tests against old sessions, verify that event streams still feed your observability pipeline, and check that humans can still understand failed runs. Do not discover in production that half your session history is readable by one component and ignored by another. Agent systems already have enough ways to lie about state; schema drift does not need to be one of them.

The compatibility note is useful here. ADK 2.0 sessions can be read by ADK 1.28+ with extra fields ignored. That gives teams a bridge, but only if they are already on a sufficiently recent 1.x version. If not, upgrade in stages. Treat session data as operational data, not disposable chat logs. Once agents start editing repos, opening PRs, and calling tools, the transcript becomes evidence.

Agents building agents raises the review bar

The most quietly interesting docs update is ADK’s “coding with AI” path. Google now points developers toward Agents CLI skills and an ADK Docs MCP server for Gemini CLI, Antigravity, Claude Code, and Cursor. In plain English: Google expects developers to use agents to build agent workflows. That is probably inevitable, and it is also where teams can get sloppy fast.

If an AI assistant generates an ADK workflow, the graph shape can create a false sense of rigor. A workflow rendered as nodes and edges looks engineered even when the underlying prompts, task contracts, and error paths are weak. The answer is not to ban AI-generated agent code. The answer is to review it like infrastructure. Are task boundaries typed? Are retries bounded? Does the human approval checkpoint happen before the dangerous action, not after? Are model calls reserved for judgment-heavy steps while deterministic code handles parsing, routing, validation, and bookkeeping? Is there an evaluation suite that intentionally breaks tools, returns malformed data, and tests partial failure?

That is the biggest practical takeaway from ADK 2.0: steal the architecture even if you do not adopt the framework. Use graphs where workflows have real control flow. Use typed tasks where delegation crosses boundaries. Keep deterministic operations out of the model when code can do them cheaper and more reliably. Add human review where authority changes, not merely where the UI looks scary.

Teams already using LangGraph, Temporal-style orchestration, custom DAGs, or homegrown tool loops should evaluate ADK 2.0 on migration cost, observability, deployment path, and failure recovery. The comparison should not be “which framework has the most agent nouns?” It should be “which one lets us explain why the run failed, replay the relevant state, and safely resume the work?”

Google’s agent platform push will get wrapped in the usual I/O spectacle, but ADK 2.0’s useful contribution is almost aggressively practical. It says agent development should look more like normal software engineering: explicit execution graphs, structured task delegation, versioned session data, and reviewable control flow. That is less magical than prompt soup. It is also how this stuff survives contact with real repositories.

Sources: GitHub — Google ADK Python v2.0.0, ADK docs, ADK graph workflows, Coding with AI in ADK, ADK README