google/adk-python: A Code-First Agent Toolkit That Puts Workflows Before Chatbots

What Problem ADK 2.0 Actually Solves

Most agent frameworks stop at a single agent that calls tools in a loop. ADK 2.0 addresses the next step: orchestrating multiple agents and tasks into a deterministic execution flow. The README describes a Workflow Runtime that supports routing, fan-out/fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop, and nested workflows. That is a different problem from simply prompting a model. The target user is a developer who wants software engineering principles applied to agent creation: testable, versionable logic. It is not for someone who wants a quick chatbot demo; the emphasis on graph edges and structured delegation points to production-oriented systems. The code-first nature means you define agents and workflows in Python, which gives you version control and unit-testing opportunities that a visual builder would not. The README also mentions an Agent Config feature for building agents without code, but the core identity is code-first.

The Workflow Runtime and Task API Are the Core Mechanism

The framework splits agent logic into two main classes: Agent and Workflow. An Agent defines instructions, tools, and behavior. A Workflow composes those agents into a directed graph. The README gives a minimal example: you create two agents, each with a simple instruction, then a Workflow with edges that connect a START node to the first agent and then to the second. The execution engine follows those edges, passing state along. The Task API adds a structured layer for agent-to-agent delegation, supporting multi-turn task mode, single-turn controlled output, and mixed delegation patterns. This is not a free-form conversation; it is a controlled hand-off. The framework also supports tool confirmation, which is a human-in-the-loop guard that pauses tool execution until a user explicitly approves. That mechanism matters for any agent that can take destructive actions. The combination of a graph runtime and a task protocol gives you a way to build systems where the flow is predictable, not emergent from the model's whims.

Getting It Running: Commands and Config You Will Actually Use

Installation is a standard pip command: pip install google-adk. The README recommends a companion constraints file for transitive dependency protection, one per Python version from 3.11 to 3.15. For Python 3.11, you download constraints-3.11.txt and pass it with the -c flag. That is an unusual step for a Python package, but it signals that the dependency tree is large enough to warrant pinning. Optional integrations come via pip install "google-adk[extensions]". After installation, you run an agent locally with the adk command: adk run path/to/my_agent. For a multi-agent directory, you use adk web path/to/agents_dir, which launches a development UI for testing and debugging. The quick start shows that an Agent takes name, model, and instruction parameters. The model string in the example is "gemini-3.5-flash", which suggests a Gemini default, but the framework claims to be model-agnostic. The Workflow constructor takes an edges list, where each edge is a tuple that includes a start node and one or more target nodes. That is the entire API surface you need for a simple linear pipeline.

A Genuine Limitation: The 2.0 Breaking Changes and Session Compatibility

The README title marks this release line as ADK 2.0, and the repository keeps a CHANGELOG.md at the top level. If you run an existing deployment on an older version, read the changelog before upgrading rather than assuming a drop-in change, and test any persisted session data against the new version first.

Where ADK 2.0 Might Be the Wrong Tool

ADK 2.0 is heavily oriented toward Google's ecosystem. The README mentions optimization for Gemini, and the deployment targets are Cloud Run and Vertex AI Agent Engine. The tool ecosystem includes OpenAPI specs and MCP tools, but the tight integration with Google services is explicit. If your organization runs on AWS or Azure, or if you use a non-Google model provider as your primary, the model-agnostic claim needs scrutiny. The README says it is model-agnostic, but the quick start example hardcodes gemini-3.5-flash. Also, the framework is Python-only. The project has sibling repositories for Java, Kotlin, Go, and TypeScript, but those are separate codebases, not bindings. A polyglot team cannot share agent logic across languages. If your workflow is simple, such as a single agent with a couple of tools, ADK 2.0 is overkill. The graph runtime and task delegation add conceptual overhead that a plain function-calling loop would not justify.

The Real Alternative: A Code-First Graph vs. a Declarative Agent Chain

The closest alternative to ADK 2.0 is not a chatbot library; it is another orchestration framework such as LangGraph (from the LangChain ecosystem). LangGraph also models agents as a graph with nodes and edges, supports state, and allows human-in-the-loop. The key difference is in the programming model. LangGraph is built around a state machine where you define nodes as functions and edges as conditional transitions, and it is framework-agnostic about the model provider. ADK 2.0, based on the README, uses a higher-level Agent and Workflow abstraction with a Task API for delegation. That means ADK gives you more structure out of the box, but it also imposes that structure on your design. LangGraph is more low-level and flexible, at the cost of writing more glue code. Another difference is deployment: LangGraph has its own cloud offering, while ADK targets Google Cloud Run and Vertex AI. If you are already on Google Cloud and want a managed agent runtime, ADK is the natural fit. If you need to avoid Google-specific services, LangGraph or a similar provider-neutral graph library gives you fewer constraints.

Maintenance and Upgrade Cost: Bi-Weekly Releases and Breaking Changes

The release cadence is roughly bi-weekly, which is fast for a framework. The latest releases listed are v2.13.0 on 2026-10-23, v2.12.0 on 2026-10-13 and v2.11.0 on 2026-10-02. For adopters, the cost is real: you must track releases and read changelogs carefully. The README advises using constraints files to protect against transitive dependency changes, which is a sign that the dependency graph shifts often. The development version on the main branch may contain experimental changes, so the stable PyPI release is the safer choice. The license is Apache-2.0, which is permissive and does not impose copyleft obligations. That allows you to embed ADK in proprietary products, but you are still responsible for the dependencies. The project also provides companion samples in a separate repository (adk-recipes) and a web UI project (adk-web), which adds more moving parts to learn. Before adopting, verify that the bi-weekly release rhythm fits your organization's change management process.

Editorial conclusion

Adopt ADK 2.0 if you are a Python developer building multi-agent systems that need deterministic routing, fan-out/fan-in, and human-in-the-loop confirmation, and you are comfortable with a code-first approach. Do not adopt it if you want a no-code visual designer; the config feature exists but code is the primary path. Before committing, verify that your chosen model and deployment target (Cloud Run or Vertex AI Agent Engine) are supported. The project is under active bi-weekly releases, so pin your dependency and review the changelog for breaking changes.

Frequently asked questions

Official sources

1. google/adk-python on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases