Google ADK 2.0 Makes Graph Workflows the Center of Its Agent Framework Bet

Google ADK 2.0 is not another “our agent can call tools now” release. It is Google putting a stake in the ground on the part of agent systems engineers keep rediscovering the hard way: prompts are not process definitions. If the workflow matters, put the workflow in a graph.

The Python google-adk 2.0.0 release, published as general availability, makes graph-based workflows and the Task API the center of Google’s open-source agent framework bet. That makes it a different story from Google’s Managed Agents announcement in the Gemini API. Managed Agents is the cloud-runtime pitch: let Google host the agent harness and environment. ADK 2.0 is the code-first orchestration pitch: keep control of routing, state, retries, human approvals, fan-out/fan-in, loops, and delegation in your application.

Those two bets are not contradictory. They are Google covering both ends of the stack.

Graph workflows are the correction to prompt-shaped architecture

ADK 2.0’s release notes describe a “model-agnostic” multi-agent workflow engine for non-linear, conditional, and cyclical execution patterns. The README calls out Workflow Runtime and Task API as the marquee additions. Workflow Runtime supports routing, fan-out/fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop, and nested workflows. The Task API supports structured agent-to-agent delegation, multi-turn task mode, single-turn controlled output, mixed delegation patterns, and task agents as workflow nodes.

The important word there is not “agent.” It is “structured.” A lot of early agent systems tried to encode process into giant instruction blocks: first inspect the repo, then make a plan, then run tests, then ask for approval, then update the ticket, unless the build fails, in which case retry, unless the failure is unrelated, in which case summarize. That may work once. It is not an architecture.

Graph workflows move deterministic control back into code. Nodes can be agents, tools, functions, or human input. Edges define explicit process flow. Some nodes can call models; others can be plain functions. That matters because not every step in an agentic workflow needs generative reasoning. Parsing a file, checking a policy, routing by status, retrying a failed API call, or waiting for a human approval should not depend on the model remembering a paragraph from the system prompt.

This is the same direction the serious framework ecosystem is moving. LangGraph made stateful graph execution the center of LangChain’s agent strategy. Microsoft Agent Framework is investing in workflows, intermediate event semantics, and type-safe orchestration. CrewAI has been pushing Flows alongside crews. Google ADK 2.0 joining that convergence is the useful signal: production agents are becoming graph runtimes with model-powered nodes, not autonomous chat loops with optimistic tool access.

Delegation needs an API, not vibes passing messages to vibes

The Task API may become the more interesting piece over time. Agent-to-agent delegation is easy to demo and hard to operate. One agent asks another agent to do something, the second returns some text, and everyone claps until the first agent needs to know whether the answer is final, partial, failed, awaiting human input, or constrained to a particular output contract.

ADK 2.0’s Task API is Google’s attempt to make delegation a runtime primitive instead of a prompt convention. Multi-turn task mode, single-turn controlled output, mixed delegation patterns, human-in-the-loop, and task agents as workflow nodes all point in the same direction: the relationship between agents should be inspectable and structured enough to test.

That is where practitioners should focus their evaluation. Do not ask whether ADK can create a cute two-agent demo. Every framework can. Ask how a delegated task is represented, how state moves across the boundary, how cancellation works, whether output schemas are enforced, how human approval interrupts are modeled, and whether traces show delegation as a first-class event rather than a blob of conversation.

The release notes also mention native inter-agent routing, inter-agent messaging, control-state handoffs, and context-variable propagation across collaborative multi-agent flows. Those features are easy to gloss over, but they are the difference between “the assistant talked to a helper” and “the runtime can prove which worker owned which part of the job.” In regulated, enterprise, or simply expensive workflows, that difference matters.

The migration warning is the part to read twice

ADK 2.0 comes with breaking changes to the agent API, event model, and session schema. Google says sessions generated by ADK 2.0 are readable by ADK 1.28+ with extra fields ignored, but they are incompatible with older 1.x versions. That is a reasonable compatibility story, but it should still stop teams from treating this like a casual patch update.

Agent event models and session schemas become data contracts faster than teams expect. Persisted sessions feed replay tools. Events feed dashboards, eval harnesses, billing reports, alerting, product UI, and audit trails. Once a framework changes those shapes, the migration is not just “does the sample agent run?” It is “does every downstream consumer still know what happened?”

If you have production or near-production ADK usage, build a migration harness. Replay representative sessions. Verify event consumers. Check dashboards. Test human-in-the-loop pauses. Confirm state serialization. Make sure older workers are not trying to consume 2.0 session shapes. The fact that ADK 1.28+ can read 2.0 sessions by ignoring extra fields helps, but ignoring fields is not the same as understanding semantics.

Google’s Python requirement also moves to Python 3.11+, with installation through pip install google-adk and optional integrations via pip install "google-adk[extensions]". The project advertises a roughly bi-weekly release cadence. That cadence is good for momentum and bad for teams that do not pin versions. Pin versions.

Google is also teaching coding agents how to write Google agents

One subtle part of the ADK 2.0 ecosystem is the “Code with AI” documentation. Google is not just documenting ADK for humans; it is packaging ADK knowledge for coding assistants. The docs mention development skills and MCP access to ADK docs, with examples for Gemini CLI, Antigravity, Claude Code, Cursor, and any MCP-compatible coding tool. The repository comparison from v2.0.0b1 to v2.0.0 also shows a large set of added .agents/skills, including adk-agent-builder, adk-architecture, adk-debug, adk-git, adk-sample-creator, adk-setup, and adk-style.

That is a useful developer-experience move and a revealing one. The next framework battle is not only over APIs; it is over how well coding agents can consume the framework’s patterns. Documentation is becoming runtime input. Skills are becoming scaffolding. MCP docs servers are becoming the way assistants keep up with fast-moving frameworks.

There is a risk here too. If teams let coding agents generate graph workflows from half-understood docs, they can produce very polished architecture-shaped slop. ADK’s graph model helps because control flow is explicit and reviewable, but humans still need to inspect the graph. The right loop is: use a coding assistant to draft the workflow, then review nodes, edges, state transitions, retries, and output contracts like production code. Because it is production code.

The broader Google strategy is now clearer. At I/O, Google tied ADK 2.0 into Gemini 3.5 Flash, Antigravity 2.0, Antigravity CLI and SDK, Managed Agents in the Gemini API, Google AI Studio, and enterprise agent platform work. Managed Agents says: if you want a hosted runtime with an isolated environment and an Antigravity-powered harness, call the API. ADK 2.0 says: if you want to own the orchestration layer, here is the graph runtime.

That gives builders a real architectural choice. Use ADK when you need explicit workflow topology, testable control flow, model-agnostic nodes, deterministic code steps, and structured delegation. Use managed runtimes when operational compression matters more than portability and you are willing to accept provider-specific lifecycle, billing, and policy surfaces. In many systems, the answer may be both: ADK for application-level orchestration, managed agents for contained sub-tasks that need a hosted execution environment.

The practical checklist is simple. Do not build a multi-step production workflow as one heroic prompt. Model deterministic steps as functions or tools. Use graph nodes and edges for routes you need to audit. Evaluate Task API delegation separately from ordinary tool calls. Test session and event migrations before rollout. Compare ADK against LangGraph, Microsoft Agent Framework, CrewAI Flows, and your existing orchestration on the boring surfaces: event inspection, state handling, retries, human approval ergonomics, deployment path, and failure behavior.

The editorial take: ADK 2.0 is Google admitting that useful agents need software architecture, not just better instructions. That is good news. The agent frameworks worth using in 2026 will not be the ones that make the model sound most autonomous. They will be the ones that let engineers keep ownership of the control flow while using models only where reasoning actually belongs.

Sources: Google ADK Python 2.0.0 release, ADK documentation, ADK graph workflows, ADK technical overview, ADK Code with AI docs, Google I/O 2026 developer highlights