Agent Development Kit

What ADK is

Agent Development Kit (ADK) is an open-source, code-first framework written in Python for building, evaluating and deploying AI agents ^[1]. Its source is published under the Apache-2.0 licence, and at the time of writing the project listed 22.1k stars and 4.3k forks ^[1]. "Code-first" means the agent's structure lives in ordinary source files rather than in a configuration file or a visual builder: an agent is a class you write, import and test like any other piece of software. The Python package is distributed as `google-adk`; it installs with `pip install google-adk`, requires Python 3.11 or newer, and ships releases at a cadence of roughly two weeks ^[1].

Two classes: Agent and Workflow

Agents are defined with two classes, Agent and Workflow, and a Workflow connects agents through edges that start at START ^[1]. The START node marks the entry point of the graph: the edges leaving it decide which agent runs first, and the edges after that decide what runs next. Because the wiring is written down rather than implied by a prompt, the shape of a multi-agent program can be read directly off the code.

The workflow runtime

Underneath sits a graph-based workflow runtime with routing, fan-out and fan-in, loops, retries, state management, dynamic nodes and human-in-the-loop steps ^[1]. Each of those pieces answers a control-flow need that appears once an agent stops being a single chat loop:

• Routing sends work down one branch or another depending on what has been decided so far.
• Fan-out starts several branches at once; fan-in waits for them and merges what they produced.
• Loops let a step repeat until a condition is met, and retries re-run a step that failed for a passing reason.
• State management carries data between steps, so later agents can see what earlier ones found.
• Dynamic nodes are steps whose identity is not fixed when the graph is written, so the graph can grow while it runs.
• Human-in-the-loop steps pause the run and wait for a person to approve or supply something before it continues.

Running these as part of the runtime, rather than as ad-hoc code around it, is what turns a collection of agents into a program with predictable control flow.

Tasks and delegation

A separate Task API handles agent-to-agent delegation, with a multi-turn task mode, and lets task agents act as workflow nodes ^[1]. Delegation here means one agent handing a piece of work to another and receiving a result; the multi-turn mode keeps the exchange going across several turns instead of a single request and response, and treating a task agent as a node means the same delegation can be placed in the graph alongside ordinary agents.

Models, deployment and other languages

ADK is optimised for Gemini but described as model-agnostic, deployment-agnostic and compatible with other frameworks ^[1]. Model-agnostic means the model behind an agent is a choice rather than a hard-coded assumption; deployment-agnostic means the code does not commit you to one runtime. For running agents, two paths are named: agents can be containerised on Cloud Run, or scaled with Vertex AI Agent Engine ^[1]. Ports of the framework exist for Java, Kotlin, Go and TypeScript ^[1], so teams that do not work in Python can use the same model of agents and workflows.

Where it sits

Agent frameworks differ mainly in what they treat as the unit of work: a prompt, a conversation, or a program. ADK takes the third view. Its vocabulary — graphs, edges, state, retries, human approval steps, delegation, container deployment — is largely the vocabulary of ordinary distributed software, applied to agents. That framing matters for anyone moving an agent from a demo to something that has to run repeatedly and be maintained, because the questions that come up are less about phrasing and more about what happens when a step fails, who has to sign off, and where the thing runs.