Google ADK (Agent Development Kit)

Overview

Google's Agent Development Kit, usually called ADK, is an open-source, code-first framework for building, evaluating and deploying AI agents. You write agents as ordinary code, combine them into teams or workflows, test them in a local web interface, run evaluation sets against them, and deploy them to Google Cloud or your own servers.

ADK is tuned for Gemini models and Google Cloud, but it is not locked to them. It can call other models through connectors, use tools from MCP servers, and talk to agents built with other frameworks through the A2A protocol. Its distinctive idea is that it mixes two kinds of control. Some agents let the model decide what to do next. Others follow a fixed, predictable structure that you define.

An everyday comparison is a restaurant kitchen. The head chef (an LLM agent) decides how to handle an unusual order. But many dishes follow a fixed card: prepare, cook, plate, in that order (a sequential workflow). Some stations work at the same time, such as grill and salad (a parallel workflow). The pastry cook repeats a step until the texture is right (a loop). ADK gives you both the thinking chef and the fixed cards.

What it is

ADK is a set of libraries plus a command-line tool. It is licensed under Apache 2.0. Python came first, and Google has since published versions for Java, Go and TypeScript, with feature levels that differ by language.

Where it came from

Google announced ADK at Google Cloud Next on 9 April 2025, alongside the Agent2Agent (A2A) protocol. It described ADK as the same framework it used inside its own agent products. The first release was in Python. Java followed, and later Go and TypeScript.

The 1.x line established the core: LLM agents, sub-agents, workflow agents, tools, sessions, evaluation and deployment. In 2026 Google released ADK 2.0. Its main addition is a workflow runtime, a graph-based engine for composing deterministic flows, with support for routing, fan-out and fan-in, loops, retries, state, human-in-the-loop pauses and nested workflows. ADK 2.0 also changed the agent API, the event model and the session schema, so upgrading from 1.x needs care. Not every language reached 2.0 at the same time.

How it works

Step 1: Define agents

The basic unit is an LLM agent. You give it a name, a model, an instruction, a description and a list of tools. The description matters: other agents read it when deciding whether to delegate work to this one.

Step 2: Give it tools

A plain function becomes a tool, and ADK builds its schema from type hints and the docstring. A long-running function tool can pause a run while outside work finishes. An agent can be wrapped as a tool so another agent can call it and get an answer back. Built-in tools include Google Search grounding and code execution. MCP toolsets let an agent use any MCP server.

Step 3: Compose agents

There are two ways to combine agents.

• Delegation. An LLM agent lists sub-agents. The model can transfer control to whichever sub-agent fits the request. This is flexible but less predictable.
• Workflow agents. A SequentialAgent runs its sub-agents in order. A ParallelAgent runs them at the same time. A LoopAgent repeats them until a condition is met or a maximum count is reached. These do not use a model to decide the order, so the structure is predictable. ADK 2.0 adds a richer graph-based workflow runtime for the same purpose.

Agents in a workflow share session state. One agent can write a value under a key, and the next agent can read it, often by naming the key in its instruction.

Step 4: Run and observe

A runner executes the agent tree for a given user and session. Each step produces an event: a model response, a tool call, a tool result or a state change. Session services store history; in development they live in memory, in production they can live in a managed service or a database.

Step 5: Add control with callbacks

Callbacks run before and after the agent, before and after each model call, and before and after each tool call. You can use them to validate input, block a tool, redact output, log, or change instructions on the fly. This is where many guardrails live.

Step 6: Evaluate and deploy

The adk web command starts a local interface that shows the conversation, each tool call and the event trace. The adk eval command runs an evaluation set: saved conversations with expected tool calls and responses. The adk deploy command targets Google Cloud's managed Agent Engine runtime, Cloud Run or GKE. You can also host an ADK app yourself.

Key concepts and terms

A worked example

This scenario is illustrative. A travel company builds a trip-proposal agent.

1. A ParallelAgent runs three research agents at once: flights, hotels and local events. Each writes its findings to session state under its own key.
2. A SequentialAgent wraps that parallel step and then runs a "planner" LLM agent, which reads the three keys and drafts a three-day itinerary.
3. A LoopAgent follows. Inside it a "checker" agent tests the plan against the budget of 1,500 euros and the traveller's dates. If the plan fails, a "reviser" agent fixes it. The loop stops when the checker passes the plan or after three rounds.
4. A before-tool callback blocks any booking tool, so the agent can only propose, never buy.
5. The team keeps an evalset of 40 past requests. After each change they run adk eval and compare tool-call paths and final answers.

In this design the model decides details, but the overall shape is fixed. That makes cost and latency easier to predict.

Strengths and limitations

Strengths:

• Mixes model-driven delegation with predictable workflow agents.
• Built-in local dev interface, evaluation and deployment commands.
• Strong integration with Gemini, Google Search grounding and Google Cloud.
• Open source under Apache 2.0, with several language versions.
• Native A2A support and MCP tools for interoperability.

Limitations:

• Smoothest on Google Cloud and Gemini; other models and hosts need more setup.
• Feature levels differ between the Python, Java, Go and TypeScript versions.
• The 1.x to 2.0 upgrade has breaking changes in the API and session schema.
• Free-form agent transfer can be hard to predict in large agent trees.
• Shared state keys can collide if naming is careless.

How it compares with alternatives

Practical guidance and best practices

1. Use workflow agents for anything with a known shape, and LLM delegation only where judgement is needed.
2. Write precise agent descriptions, since other agents route on them.
3. Give each agent a narrow tool set.
4. Name state keys clearly, for example by agent and purpose, to avoid collisions.
5. Set a maximum iteration count on every LoopAgent.
6. Put safety checks in callbacks, not only in instructions.
7. Build an evalset early and run it after every change.
8. Pin your ADK version and read the migration notes before moving to 2.0.

Common mistakes

• Letting a root agent transfer freely among many sub-agents when a fixed sequence would do.
• Running parallel agents that write to the same state key.
• Testing only in adk web and never building an evalset.
• Assuming a feature in the Python version exists in another language version.
• Allowing booking, payment or delete tools without human-in-the-loop approval.

Frequently asked questions

What is Google ADK?

ADK, the Agent Development Kit, is Google's open-source, code-first framework for building, evaluating and deploying AI agents and multi-agent systems.

When was it released?

Google announced it at Google Cloud Next on 9 April 2025, together with the A2A protocol. ADK 2.0, with a graph-based workflow runtime, followed in 2026.

Does ADK only work with Gemini?

No. It is optimised for Gemini and Google Cloud, but it can use other models through connectors and can run outside Google Cloud.

What are workflow agents?

They are agents that orchestrate sub-agents without asking a model what to do next: SequentialAgent runs them in order, ParallelAgent runs them together, and LoopAgent repeats them until a condition or limit.

How does ADK relate to A2A?

A2A is an open protocol for agents to talk across frameworks. ADK can expose an agent over A2A and can call remote A2A agents.

How do I test an ADK agent?

Use adk web to explore behaviour interactively, then save representative conversations as an evalset and run them with adk eval after every change. See evals.

Glossary

• ADK: Google's Agent Development Kit.
• LLM agent: an agent driven by model decisions.
• Workflow agent: an agent with fixed orchestration logic.
• Sub-agent: a child agent in an agent tree.
• Session state: shared key-value data within a conversation.
• Callback: code run before or after a step.
• Evalset: a saved set of test conversations.
• Agent Engine: Google Cloud's managed runtime for deployed agents.
• A2A: the Agent2Agent protocol.

Summary

Google ADK is an open-source framework for building agents as code, combining model-driven delegation with predictable sequential, parallel and loop workflows, and, since ADK 2.0, a graph-based workflow runtime. It ships with a local dev interface, evaluation and deployment commands, and fits Gemini and Google Cloud especially well. Use fixed workflows where the shape is known, keep tools narrow, put guardrails in callbacks, and run evalsets after every change.

Related

It belongs to Agent SDKs in my stack, under Agentic AI. Others in the same group: