ADK, in enough depth to read the docs
Lesson 2 of 5 in Google’s Agent Stack: ADK, Agent Runtime, and the Names That Keep Moving.
ADK’s docs assume you already know one distinction, and everything else in them hangs off it: is this component’s control flow decided by a model, or written in code?
An LLM-driven agent is the thing you met in foundations — a model, a tool set, a loop, a stopping condition — where the model chooses the next step from what it just observed. A workflow in ADK is the opposite: Sequential, Loop, and Parallel workflows (plus custom template workflows, and graph workflows in ADK 2.0) are orchestration constructs whose execution order is fixed by the code you wrote.
Older ADK material called these workflow agents — SequentialAgent, ParallelAgent, LoopAgent — versus LLM agents. With ADK 2.0 the terminology shifted toward “workflows”. The vocabulary moved; the distinction did not.
LLM-driven agent
Who decides the next step: the model, each iteration.
You give it instructions, a model, and a tool set; it reasons over the accumulated context and emits either a tool call or a final answer. ADK states it “can work with almost any generative AI model” and documents integrations for Gemini, Gemma, Claude, OpenAI models, Ollama, vLLM, LiteLLM, and LiteRT-LM — including locally running models.
Use it when the path through the tools cannot be enumerated in advance: triage, research, debugging, anything where step three depends on what step two found.
Cost: every step is a sampling decision, so behaviour varies run to run and you test it with evals, not assertions.
Sequential workflow
Who decides the next step: your code. A → B → C, always.
The classic pipeline: extract, then validate, then summarise. Individual stages may each be LLM-driven; the order is frozen.
Use it when you already know the correct sequence. If you can draw the flowchart, do not pay a model to rediscover it on every run.
Cost: none you did not choose. This is the reproducible part of your system, and you should want more of it than feels exciting.
Parallel workflow
Who decides the next step: your code, fanning out.
Run independent branches concurrently and gather the results — three retrievals against three sources, or one summariser per document.
Use it when branches do not depend on each other’s output. Latency drops toward the slowest branch instead of the sum.
Cost: concurrency is a correctness problem. Two branches writing the same state, or the same external system, is a race you now own.
Loop workflow
Who decides the next step: your code decides that it repeats; something must decide when to stop.
Draft, critique, revise — bounded iteration in code rather than hoping the model chooses to iterate.
Use it when the improvement pattern is known and repeatable. This is the state-machine answer to “reflect until good enough”.
Cost: loops need an exit that is not vibes. Set a maximum iteration count and a substantive termination check.
Graph workflow (ADK 2.0)
Who decides the next step: your code, expressed as a graph.
ADK 2.0 introduces graph workflows that, in the docs’ words, “orchestrate complex tasks through structured, graph-based architectures” with explicit execution paths — the standard answer once sequential-plus-parallel stops expressing your topology.
Use it when you need branching, joins, and conditional paths that a linear pipeline cannot represent.
Note: ADK TypeScript 2.0 is documented as GA with graph workflow support; the release date of ADK 2.0 was not established when this module’s research pack was checked, so check adk.dev for what shipped when.
Interactive sorting exercise: Six requirements from one real support-automation project. Sort each into the component type that should own it. The test is the foundations test: does the next step genuinely need to be chosen at runtime?
The second thing ADK’s docs assume you know is its tool taxonomy. Four categories, and the difference between them is where the tool’s contract comes from:
Function tools are your own code — a Python or TypeScript function whose signature becomes the schema the model sees. MCP tools come from an MCP server, so the contract is owned by someone else and discovered at runtime. OpenAPI tools are generated from an existing API specification, which is how a company with two hundred internal REST endpoints gets tools without writing two hundred wrappers. Built-in tools ship with the framework — Google Search is the documented example. Tool authentication is a first-class concern across the categories, which is the framework admitting that most real tools need a credential that is not the agent’s.
That context paragraph deserves a second read, because it is context engineering moved into the framework. Filtering stale events, summarising old turns, and loading artifacts lazily are exactly the three things teams hand-roll after their first long-running agent blows its context window — and exactly the three things that change your agent’s behaviour without changing your code. When an ADK agent “forgets” something you believe it was told, the automatic context management is the first place to look, not the last.
Which ADK version am I reading about?
As of September 2026, google/adk-python maintains two parallel release lines: the current 2.x line (latest v2.9.0, released 10 September 2026) and a 1.x line still receiving backported fixes (latest v1.39.1, 27 August 2026).
That matters when you copy a snippet from a blog post. ADK Python hit v1.0.0 on 20 May 2025 at Google I/O as a production-ready stable release, having launched in Preview on 9 April 2025 at Cloud Next ’25. A “current” tutorial could therefore be written against three materially different APIs. Versions move fast — check the releases page rather than trusting any course, including this one.
Is every language SDK at feature parity?
Do not assume so. Five languages exist; the docs’ own feature banners are per-language. ADK TypeScript 2.0 is documented as GA with graph workflow support, and the A2A quickstarts are listed for Python, Go, and Java, with Kotlin appearing for consuming remote agents.
The reliable habit: on any ADK page, read the language banner at the top of the feature you want before you pick the language for your project. Parity claims age badly in multi-language SDK families.
Does ADK lock me into Gemini?
No. ADK states it can work with almost any generative AI model, and documents integrations for Gemini, Gemma, Claude, OpenAI models, Ollama, vLLM, LiteLLM, and LiteRT-LM, including locally running models.
Two useful consequences. First, ADK is a legitimate framework choice even in a shop that has standardised on a non-Google model. Second, model-agnosticism is the property that lets you A/B a cheaper model behind the same agent definition — the single most reliable cost lever in agent engineering.
What is Agent Garden?
A sample and template collection, available in Preview from 9 April 2025, that ships alongside ADK. Useful for orientation; not an architecture. Read the samples for the idioms, then delete them — starter templates have a way of becoming production code that nobody chose.
Key terms: workflow, orchestration, state machine, context engineering, context window, tool
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.