ADK 2.0 is a framework for the whole agent life cycle
ADK 2.0 covers much more than calling a model with tools. The Python package defines agents, graph-based workflows, task delegation, sessions, state, evaluation, and deployment adapters. A workflow can route work, loop, retry, fan out, request human confirmation, or nest another workflow. The same project includes a command-line runner and a development web interface. That breadth makes sense for a team treating agents as maintained applications, with behavior that must be reviewed and tested in source control.
The tradeoff appears in the repository itself: our checkout contained 2,561 files and roughly 541,142 lines of source. ADK is optimized for Gemini, though the README says it can use other models and coexist with other frameworks. It also connects function tools, OpenAPI descriptions, and MCP services. This is useful when one team wants a standard runtime. It is a lot of machinery when the job is one prompt, one schema, and one response.
What happened when we ran it
Our sandbox installed ADK in 126 seconds, with 331 packages taking 1,696 MB on disk. The build succeeded in 8 seconds. We used commit 85b52f6, Python 3.12 on Debian, 3 CPUs, and 8 GB of RAM in an unprivileged container with no secrets. Those results show that the source can install and build in a clean environment, but the dependency footprint is closer to an application platform than a small Python helper.
The test step failed after 81 seconds. Pytest recorded 0 passed, 0 failed, and 2 skipped before stopping after 200 collection or setup errors. The final log lines name tests across tools, skills, URL context, Vertex AI Search, runner utilities, agent information, and instructions. The tail does not contain the underlying traceback, so it would be guesswork to assign a cause. Pip-audit also reported 3 known vulnerabilities. A team evaluating ADK should reproduce the suite in its own build image before treating the green build as release confidence.
The simple agent API sits above a 331-package install
The first user-facing example is easy to understand. Create an Agent with a name, model, and instruction, then point adk run or adk web at its directory. A separate Workflow object connects agents with graph edges. Evaluation has its own adk eval command, which is better than leaving quality checks as an informal prompt-testing habit. The README also links a samples repository and task-oriented guides for tools, events, plugins, and workflows.
Installation is less casual than the one-line command suggests. Our fresh environment needed 331 packages and 1,696 MB, and Google recommends a constraints file matched to Python 3.10 through 3.14 for transitive dependency protection. Real agents also need provider credentials and tool-specific secrets. Cloud Run and Vertex AI Agent Engine are deployment choices, not automatic outcomes of installing the package. Teams should budget time for identity, persistent sessions, observability, and the failure behavior of each external tool.
Version 2.0 makes migration a design task
The README puts the 2.0 warning near the top because the agent API, event model, and session schema changed. Sessions written by 2.0 can be read by ADK 1.28 or newer because older readers ignore added fields. Versions older than 1.28 are incompatible. That boundary matters for rolling deployments and stored conversations: upgrading one service without checking the readers around it can turn a library change into a data compatibility problem.
The latest GitHub release we fetched was v2.7.1, published on August 17, 2026. It restored an OpenTelemetry dependency ceiling and added session-initialization validation. The repository was pushed again on August 26, and GitHub reported 538 open issues and pull requests combined. That activity supports a strong community score, while the volume and recent bug reports also show a moving surface. Pin versions, read release notes, and test stored sessions when upgrading.
Non-Gemini paths need their own tool-call tests
Model portability is a real feature, but it should be verified at the tool-schema and event level. Recent open reports describe LiteLLM streaming keeping one reasoning part per delta, union schemas losing anyOf, and custom Vertex request mapping dropping tools without an error when fields are placed incorrectly. These reports are specific edge cases, not proof that every alternate provider is broken. They are enough to justify contract tests that assert which tool was called and what schema reached the provider.
ADK's issue tracker was being updated within 1 day of our review, and the repository has 14 CI workflow files plus a tests directory. That is a healthier maintenance signal than a release tag alone. It does not erase our clean-container result: 200 setup or collection errors prevented the suite from giving us pass or fail coverage. For a production trial, run the exact provider, session backend, tool types, and cancellation behavior your application will use.
ADK fits teams already choosing Google's agent stack
ADK is easiest to justify when several requirements arrive together: Python agent code, explicit workflows, Gemini, evaluation, MCP or OpenAPI tools, and a route to Google Cloud. The pieces share concepts and a runtime, which can be easier to govern than an assortment of homegrown loops. Human confirmation and task delegation are also first-class ideas in the README, so teams do not have to invent those structures around a bare model client.
Our 126-second install and 1,696 MB dependency footprint set the practical boundary. Small applications pay for scope they may never use, and contributors need to investigate why a clean 3-CPU container could not collect the tests. ADK deserves a focused proof of concept for a Google-centered platform team. It is a poor default for every Python chatbot. Start with one representative workflow, pin its dependencies, and require the provider and session tests to pass before expanding it.