Get started with Google Agent Development Kit

A common use case in generative AI is developing an agent, which is a system users interact with in plain language to accomplish a given task. Creating AI agents can require a lot of heavy lifting, even when you’re leveraging an existing commercial model.

Google recently released the Agent Development Kit, a library for Python and Java that handles many boilerplate aspects of creating AI agents. The Google Agent Development Kit supports developing agents for simple tasks or complex multi-step workflows. And while the toolkit works naturally with Google’s own AI models like Gemini, it’s not difficult to adapt it to most any AI model served through an API.

Setting up Google Agent Development Kit

The Agent Development Kit, or ADK for short, supports two languages, Python and Java. We’ll work with the Python version.

To get started with the kit, create a new virtual environment and install the ADK into it with pip install google-adk. Note that this installs a large number of dependencies—84, as of this writing—so be prepared to devote around 285 MB of space for the environment and its dependencies alone.

You’ll also want to create an.env file in the root of your project to hold the API keys for the AI services you’ll connect with. The ADK automatically detects.env files and uses their contents, so you don’t need to write any code to handle that.

Developing a basic AI agent

Let’s set up a basic agent that does nothing more than scour the Internet for answers to questions.

In your project directory, create a subdirectory named searchagent. Inside, we’ll place two files: __init__.py and agent.py.

Here’s the code for __init__.py

from. import agent

And here is agent.py:

from google.adk.agents import Agent
from google.adk.tools import google_search

root_agent = Agent(
name='search_assistant',
description='An agent that answers questions augmented with web searches.',
model='gemini-2.0-flash',
instruction='Answer questions provided by the user. Compare and contrast information gathered from Google with your own information. If you are given a statement that is not a question, reply, 'Please ask me a question.'',
tools=[google_search]
)

Whenever we want to create a distinct agent, we set up a subdirectory in our main project directory and give it a name (in this case, searchagent). This lets us have multiple agents in a single project, which can run on their own or interoperate.

The __init__.py file marks the directory as being an agent, by importing the actual agent code. The agent.py file sets up the agent itself, as described by the Agent object.

Each Agent uses a model API to interface with (here, it’s gemini-2.0-flash). Our initial commands to the agent, which prefix each input from the user, are defined in instructions. Note that these instructions can be far more detailed than what we’re providing here. The tools section provides additional tooling that can be used by the agent; google_search lets the agent use Google searches to augment its results.

To run this example locally using a web interface, open a command line, activate the venv, and use the command adk web. After a pause, you’ll get a prompt that the ADK’s web interface is running on port 8000.

Navigate to in your browser, and you’ll see the default ADK web interface, with the simpleagent agent ready to run. If you have multiple agents configured for a given project, the dropdown at the top left of the page lets you choose between them.

To ensure the agent is running properly, type a question to be researched in the pane at the bottom of the web page and press Enter. The results should show up in a few seconds:

IDG

The left-hand side of the web UI provides debugging information for each conversation you have with the agent. If you click the “bot” icon to the left of the conversation, you’ll see the back-end details for that conversation, including metadata returned by the service about its activity. The details will vary across services:

IDG

If you select the Token Streaming option at the top of the chat window, the results will be returned gradually, word-by-word, rather than all at once.

Developing a multi-agent architecture

One of ADK’s strengths is how it lets you create agent systems that involve more than one agent at a time. Interactions between agents can be composed using what are called workflow agents.

Workflow agents launch AI agent tasks, then handle how they execute in strongly predetermined ways. These aren’t AI agents themselves; they’re just programs written in Python or Java. But they can greatly expand on how agents operate.

Workflow agents come in several different varieties:

Sequential agents: A sequential agent feeds user input to a given LLM or workflow, takes the results, and then feeds them to another LLM or workflow (with some additional prompting for how that agent should handle the input). This way, one agent can be used to transform or refine the output of another. An example of this would be an agent that generates a text, and another agent that rewrites it in a specific verbal style.

Loop agents: A loop agent takes a given input, feeds it to an LLM or workflow, then re-runs the same process until some condition is met. This condition could be something entirely mechanical, like running the loop x times in a row. But it can also be about having another LLM agent check for some criteria; for instance, by asking, “Does this output satisfy these conditions?” An example would be one agent that generates a simplified text from a larger one, and another that determines whether the simplified text omits any crucial details; if it does omit details, then a new condensed text gets generated. This could continue indefinitely, or (more likely) for a fixed number of loops.

Parallel agents: Parallel agents execute two or more agent jobs side by side, then yield the results only when all the jobs are complete. No state is shared between the jobs as they’re running; they all have to be supplied with the needed data upfront. An example of this would be an agent that uses three different search engines as part of the fact-checking process for a document. Each fact-checking pass is conducted side by side with a different search engine, and the results are then combined after all the searches finish.

It’s important to remember that these agents are really just Python or Java programs. Because of that, they’re limited by the behaviors of conventional programs. For instance, a parallel agent is limited by whatever it attempts to do in parallel. If you use the agent to run multiple jobs on a remote service that only accepts one job at a time from your API key, you won’t have a parallel agent anymore.

Tools in the Agent Development Kit

Agents in the ADK can also rely on Tools to augment the way they work. A “Tool” in this context is just a piece of Python or Java code that interfaces with non-LLM components, such as fetching something from a URL endpoint, retrieving something from a database, or doing some other action that doesn’t require an LLM—although it may use data generated by an LLM to get things done.

ADK Tools come in three basic categories:

Function tools wrap existing functions in the language you’ve written. They return JSON, so all data types used for return values must be JSON-serializable by default. Functions can be set to run without blocking other behaviors, and can also function as agents—in effect, calling an agent as if it were a tool and using its response as the tool’s response.

Built-in tools provide common stock functions, like Google Search, so you don’t have to implement them from scratch. You can also run arbitrary code or run Google Vertex AI Search through built-ins.

Third-party tools let other developers provide tools to be used in your own workflows, like LangChain.

Any existing business logic you want to connect to an ADK-powered agent is best done with a Tool of some kind, rather than by copying the logic into the agent code. You can write the logic directly into the agent if you simply want to experiment, but anything production-worthy should be done through a Tool interface.

Example projects in the Agent Development Kit

One good way to start working with the ADK is to look at the existing roster of example projects and repurpose one for your own needs. They cover a broad variety of use cases and behaviors, so a pattern you want to replicate is likely already covered there:

LLM auditor: An automated fact-checking system with two agents: one to verify a claim, and another to produce a rewritten version of the original claim that conforms to the verified facts. This example uses a sequential agent architecture, so your own sequential agent system could be patterned after this.

Customer service: A customer-service agent that connects with different back-end services to perform various customer-service tasks. Many different tools are mocked up through this example (e.g., making video calls or speaking to services like Salesforce), so this example could be hitched to actual back-end services as needed.

Image scoring agent: Generates images and validates the results based on criteria supplied to another agent that evaluates the generated images. This example uses a loop agent, so a project that requires continuously refining input could use this as a basis.