Google’s July 1 explanation of ADK 2.0 makes a clear argument: production agents should not use a language model to orchestrate every step when ordinary workflow logic can do the routing more predictably.
ADK 2.0 introduces workflow support around agents. Google’s docs say the release supports Python and Go and includes graph-based workflows, dynamic workflows, and collaborative workflows. ADK Python 2.0 reached general availability on May 19, 2026, and ADK Go 2.0 reached general availability on June 30, 2026.
The timing matters because agent frameworks are shifting from demo surfaces into production control planes. Once agents touch customer workflows, payment operations, internal systems, or regulated processes, “let the model decide the sequence” becomes a reliability and governance problem.
The workflow is the boundary
Google’s core claim is structural. Language models are often asked to handle routing, scheduling, error handling, and other orchestration work that traditional code already handles well. That can work, but it can be slower, more expensive, and more variable than deterministic execution.
ADK 2.0 workflows are meant to split the job. Use code and graph routing where the sequence is known. Use a model or specialized agent where ambiguity and reasoning are actually needed.
That is a useful production distinction. A refund process, approval flow, data-validation sequence, or support escalation may include AI judgment, but the business process still has steps that must happen in a known order. The model should not need to infer those steps from a long prompt every time.
Migration details show the architecture changed
The ADK docs make the shift visible in the migration notes. ADK 2.0 introduces a workflow runtime, treats agents, tools, and functions as nodes in a workflow graph, and changes event handling.
For Python, the docs say ADK 2.0 adds node_info and output fields to the core event schema. For Go, the docs list additional event fields such as isolationScope, Routes, RequestedInput, Output, and nodeInfo. The Go 2.0 migration also changes the module import path to google.golang.org/adk/v2.
Those are not cosmetic changes. They show that ADK is moving from a hierarchical agent executor toward a graph-managed runtime where the framework owns routing, persistence, retries, and pauses.
The trade-off is control over flexibility
Workflow boundaries make agents more predictable, but they also make architecture choices sharper.
If a process is mostly known, ADK 2.0’s workflow model can reduce model burden and make failure states easier to reason about. If a task is genuinely open-ended, an agent still belongs in the loop. The design question is where the boundary sits.
Google’s own guidance is conservative: use a workflow when business logic is predefined, strict compliance matters, explicit failure states matter, or orchestration should minimize tokens and latency. Use an agent when the task is open-ended or needs adaptive reasoning.
