Google ADK: the agent runtime, not another chatbot SDK
What Agent Development Kit actually is — build, run, evaluate, deploy — and when it is the right layer vs rolling your own loop.
ADK is Google’s open-source Agent Development Kit: a framework for building, debugging, evaluating, and deploying agents as software — not as one-off chat scripts.
It is the same family of ideas powering agent surfaces inside Google’s own products. Public docs position it as multi-language (Python first, plus TypeScript, Go, Java, Kotlin) and model-agnostic enough to not lock you into a single vendor API for every call.
What problem it solves
Raw LLM APIs give you tokens. Chat UIs give you a transcript.
Production agents need:
- a runtime loop (plan → tool → observe → continue)
- tools with clear contracts
- session / state across steps
- multi-agent composition (orchestrator + specialists)
- eval hooks so you can tell if a change made the agent worse
- a path to deploy without rewriting the whole thing
ADK is aimed at that stack. Think “agent application framework,” not “wrapper around generateContent.”
Mental model
| Layer | ADK’s job | Your job |
|---|---|---|
| Model | call through adapters / providers | pick models, cost/latency tradeoffs |
| Agent | define behavior, tools, handoffs | domain judgment, prompts, policies |
| Runtime | run the loop, stream events, keep session | boundaries: secrets, blast radius |
| Eval | harness patterns for agent quality | golden tasks, failure cases |
| Deploy | CLI / API / cloud packaging paths | product shell: auth, tenancy, UI |
If you skip that split, you either reimplement a half-broken runtime or bury product logic inside framework glue.
Core pillars (the official story, restated)
- Build — agents + tools, from single agent up to multi-agent workflows
- Interact — run locally, inspect traces/events, not black-box “it said OK”
- Evaluate — treat agent behavior like software under test
- Deploy — ship the same definitions beyond your laptop
The interesting part is orchestration: not only free-form “agent goes brrr,” but workflow-style agents when you want predictable pipelines (A then B then human gate).
That matches how serious agent products actually ship: autonomy inside a fence, determinism at the edges.
ADK vs “just use LangGraph / Crew / custom”
Peers solve overlapping problems. ADK’s pitch is:
- code-first multi-agent systems
- Google Cloud / Gemini-friendly path without being Gemini-only forever
- lifecycle coverage (build → eval → deploy), not only graph wiring
Choose ADK when you want a standard agent runtime and are fine adopting its primitives (agents, tools, sessions, runners).
Roll your own or pick another framework when:
- your loop is tiny and stable already
- you need a graph model that ADK fights
- the team already has deep investment in another runtime
Framework churn is real. Keep domain logic thin at the ADK boundary: tools and policies should survive a runtime swap.
What “good ADK usage” looks like
root agent (orchestrator)
├─ specialist A + tools
├─ specialist B + tools
├─ shared session / context
└─ human approval before irreversible side effects
Bad usage:
- one mega-agent with 40 tools and no stop condition
- no eval set (“we vibe-checked it”)
- deploy with prod credentials in the agent’s default tool env
Same rules as any agentic system: verify in the loop, sandbox the blast radius.
Decision rule
Use ADK when you are building an agent product or multi-agent system and need a maintained runtime for sessions, tools, and composition.
Do not use ADK when you only need a single LLM call with a function or two — that is an API client, not an agent framework.
ADK does not replace product engineering. It replaces the part where every team reinvents the agent loop poorly. The judgment — what to automate, what to gate, what “done” means — is still yours.
get new posts
Occasional notes on agentic development. No spam.