# Google ADK (Agent Development Kit)

Google's Agent Development Kit is an open-source framework for building, evaluating and deploying agents, with workflow agents, multi-agent designs and A2A support.

## 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](/tools/mcp) servers, and talk to agents built with other frameworks through the [A2A](/tools/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.

| Part | What it does |
|---|---|
| LLM agent (`Agent`) | A model with instructions, tools and optional sub-agents; it decides its own steps |
| Workflow agents | `SequentialAgent`, `ParallelAgent` and `LoopAgent` run sub-agents in a fixed pattern |
| Custom agents | Your own agent class with fully hand-written control logic |
| Workflow runtime | In ADK 2.0, a graph-based engine for deterministic flows with routing, fan-out, loops and retries |
| Tools | Function tools, agents as tools, built-in Google tools, MCP and OpenAPI tools |
| Sessions and state | Conversation history and a key-value state shared by agents in a session |
| Memory | Long-term information that survives across sessions |
| Callbacks | Code that runs before and after agents, model calls and tool calls |
| Runner and events | The engine that executes agents and emits a stream of events |
| CLI and dev UI | Commands to run, evaluate and deploy agents, plus a local web interface |

## 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](/tools/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

| Term | Meaning |
|---|---|
| LLM agent | An agent whose next step is chosen by the model |
| Workflow agent | An agent that runs sub-agents in a fixed sequence, in parallel or in a loop |
| Sub-agent | A child agent that a parent can delegate to or orchestrate |
| Agent transfer | The model handing control to another agent |
| AgentTool | Wrapping an agent so another agent can call it like a function |
| Session | One conversation, with its events and state |
| State | Key-value data shared by agents within a session |
| Memory | Information kept across many sessions |
| Callback | Hook that runs before or after an agent, model or tool call |
| Event | One recorded step in a run |
| Evalset | Saved test conversations with expected behaviour |
| A2A | Protocol for agents from different systems to talk to each other |

## 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

| Option | Strength | Trade-off |
|---|---|---|
| Google ADK | Workflow agents, eval and deploy tools, Google Cloud fit | Best inside Google's stack |
| [OpenAI Agents SDK](/tools/openai-agents-sdk) | Minimal primitives with handoffs and guardrails | Best with OpenAI models |
| [Claude Agent SDK](/tools/claude-agent-sdk) | Rich built-in file and shell tools | Built around Claude |
| [LangGraph](/tools/langgraph) | Model-agnostic graphs with checkpoints | You assemble more pieces |
| [Microsoft Agent Framework](/tools/microsoft-agent-framework) | Python and .NET with Azure integration | Best inside Microsoft's stack |

## 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](/tools/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](/tools/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.