Get Started with ADK: Introduction to Google's Agent Development Kit

A useful operations assistant needs access to facts. Without access to monitoring data, a language model cannot verify whether your payments service is healthy.

This is the problem we will explore in Get Started with ADK. We will build a small assistant in Python, give it a controlled source of service-status data, and then teach it to retain a service selection across messages.

The series follows the practical theme of my Google AI Agents Live + Labs article: put application logic and data access in code, and give the model a clearly defined job.

The learning path

Each implementation article includes complete file contents, commands, example prompts, and checks. Follow them in order; later parts explicitly identify which files to replace.

What ADK provides

Google's Agent Development Kit, or ADK, is an open-source framework for developing agents. It provides agent definitions, tool integration, runtime support, and development interfaces. This series uses its Python SDK with Gemini. See the official ADK overview for the broader framework.

Our application will use these components:

An LLM agent is configured with a name, model, instructions, and optional tools. Instructions guide model behavior; code implements the operations available to it. Google's agent documentation describes these configuration fields.

Step 1: Define the assistant's job

Our assistant will answer questions about two fictional services: payments and catalog.

The tutorial dataset will report:

These are fixed teaching examples. They do not represent live infrastructure, and the assistant will identify them as simulated data.

Write down the expected behavior before adding a model:

1. A known service returns the corresponding record.
2. An unknown service returns an explicit error.
3. A general question can receive a general explanation.
4. A service-health claim must come from a tool result.
5. The assistant cannot deploy, restart, or modify a service.

This gives us concrete behavior to check later. A fluent response alone will not demonstrate that the application works.

Step 2: Trace one request

Consider this question:

COPY
What is the status of payments?

Our intended flow is:

COPY
User question
    -> Model receives instructions and available tool definitions
    -> Model requests get_service_status(service_name="payments")
    -> Python looks up the demo record
    -> Tool result returns to the model
    -> Assistant explains the simulated status

The lookup result is repeatable. The wording of the assistant's explanation can vary. We will inspect both the tool result and the answer when checking the finished agent.

Step 3: Choose the project boundaries

We will start with one agent and a small in-memory dataset. That makes it possible to debug a wrong answer without also troubleshooting a database, cloud permissions, or an external monitoring API.

In a real service, the lookup function could call a monitoring endpoint. Its contract would still need to distinguish a successful lookup, an unknown service, and an unavailable data source. An API timeout should never become a healthy status.

We will also keep selection separate from authorization. Remembering payments in conversation state will mean only that the user selected it. It will not grant access to infrastructure.

Step 4: Prepare for the implementation

You should be comfortable creating files, running terminal commands, and reading basic Python functions and dictionaries. Part 2 covers the installation itself.

Choose a separate project folder for the tutorial. You will need a Python environment, internet access for model calls, and a Gemini API key. The shell examples use macOS or Linux; the setup article also includes Windows activation instructions.

The final project will contain:

COPY
adk-starter/
├── .gitignore
├── check_tools.py
├── requirements.txt
└── ops_assistant/
    ├── __init__.py
    ├── .env
    ├── agent.py
    └── tools.py

The .env file stays local. tools.py and the standalone check script arrive in Part 3. There is no application code to run in this introductory part.

Continue to Part 2: Build your first ADK agent to create the project and start a conversation.