How to Build a Kotlin AI Agent with ADK 1.0

Google's Agent Development Kit (ADK) for Kotlin reached version 1.0 on September 9, giving Kotlin developers a stable framework for building AI agents instead of assembling model calls, tools, sessions, and orchestration themselves. The release brings Kotlin support to feature parity with the core ADK while adding Android-specific paths for on-device and cloud agents. This tutorial builds a small Kotlin agent on the Java Virtual Machine (JVM), adds a tool, and runs it through ADK's development interface.

What ADK for Kotlin 1.0 changes for agent developers

ADK is a code-first framework for defining an AI agent's behavior, model, tools, sessions, and orchestration in application code. Version 1.0 for Kotlin is built for Kotlin Multiplatform and uses Kotlin Symbol Processing (KSP), a compile-time code generation system, to create function-tool integrations without relying on runtime reflection. The result is a Kotlin API that can describe an agent and its capabilities directly in code rather than hiding the workflow behind a separate visual builder.

The release also goes beyond a simple JVM wrapper. Google says ADK for Kotlin 1.0 supports human-in-the-loop workflows, context compaction, multi-agent systems, and Android extensions. On Android, developers can use LiteRT-LM for local models, Firebase AI Logic for cloud models, Room for persistent state, and AppSearch for semantic memory. Those features make the framework useful for both traditional Kotlin backends and applications that need AI agents closer to the device.

Set up the Kotlin project before creating the agent

The JVM quickstart requires Java 17 or later and Gradle 8.0 or later. Create a normal Kotlin JVM application and add the ADK core library together with its KSP processor. The processor is needed when your agent uses functions exposed as tools.

plugins {
    kotlin("jvm") version "2.1.20"
    id("com.google.devtools.ksp") version "2.1.20-2.0.1"
    application
}

repositories {
mavenCentral()
}

dependencies {
implementation("com.google.adk:google-adk-kotlin-core:1.0.0")
implementation("com.google.adk:google-adk-kotlin-webserver:1.0.0")
ksp("com.google.adk:google-adk-kotlin-processor:1.0.0")
}

kotlin {
jvmToolchain(17)
}

application {
mainClass.set("com.example.agent.MainKt")
}

The important version here is ADK Kotlin 1.0.0, which matches the stable release described in Google's September announcement and quickstart. Keeping the core, web server, and processor on the same ADK version avoids a common class of dependency mismatches when generated tool code and the runtime expect different APIs.

Give the agent a model and a clear job

An ADK agent needs more than a model name. The instruction defines what the agent is responsible for, while the model supplies the language-model reasoning used to respond. A useful first example is a small assistant that can answer questions about the current time by calling a Kotlin function rather than guessing.

package com.example.agent

import com.google.adk.kt.agents.Instruction
import com.google.adk.kt.agents.LlmAgent
import com.google.adk.kt.models.Gemini
import com.google.adk.kt.tools.GoogleSearchTool

val rootAgent = LlmAgent(
name = "search_assistant",
description = "An assistant that can search the web.",
model = Gemini(name = "gemini-3.1-flash-lite-preview"),
instruction = Instruction(
"You are a helpful assistant. " +
"Answer user questions using Google Search when needed."
),
tools = listOf(GoogleSearchTool())
)

The example uses ADK's built-in Google Search tool, so the model can retrieve information instead of relying only on its training data. The important architectural point is that the tool is part of the agent definition. The model decides when the tool is useful, while ADK handles the surrounding tool-call workflow.

Add your own Kotlin function as an AI tool

Built-in tools are useful, but real applications usually need access to their own business logic. ADK for Kotlin uses the @Tool annotation to expose Kotlin functions to an agent. KSP processes that annotation at build time and generates the code needed to register the function.

import com.google.adk.kt.tools.Tool

class WeatherTools {

```
@Tool
fun getWeather(city: String): String {
    return "Weather data for $city is available here."
}
```

}

This example deliberately returns a placeholder rather than pretending to access a real weather service. In a production application, the function would call your own service or another approved API and return verified weather data. The agent should not be given permission to invent the underlying result just because a tool exists.

You can then include the tool when constructing the agent. The model receives a description of the function and its input, and ADK manages the function-call exchange. This separation is useful because your application code remains responsible for the actual operation while the language model decides when that operation is relevant.

Keep tool descriptions precise

A tool is part of the agent's decision-making surface, so its name and description matter. A vague function such as doSomething() gives the model little information about when it should be called. A function such as getWeather(city) communicates both the operation and the required input.

Tool boundaries should also match the permissions your application is comfortable granting. A read-only lookup can be exposed directly, while actions that delete data, spend money, send messages, or change an account should normally require additional authorization or human confirmation. ADK can orchestrate the agent, but it does not remove the need for application-level access control.

Run the agent from Gradle before adding a UI

Once the project is configured, the quickest test is the interactive command-line interface. Load the required environment settings and run the Gradle application task.

gradle run

A successful launch gives you an interactive session where you can send a message and inspect the agent's response. This is a useful checkpoint because it separates problems in the model configuration from problems in a future Android or web interface. If the basic agent cannot answer from the command line, adding a graphical client will not fix the underlying configuration.

Use the ADK development UI to inspect the workflow

ADK Kotlin also provides a development web interface through its web server module. This gives developers a browser-based way to interact with and debug their agents while they are still building them. It is particularly useful when the application has several tools or agents because the model response alone does not always reveal where a workflow went wrong.

The development interface should be treated as a development aid rather than an application-facing production interface. Keep authentication, authorization, production logging, and deployment configuration separate from the local environment used to inspect your agent.

Move from one agent to a multi-agent workflow when the job requires it

A single general-purpose agent is not always the clearest architecture. ADK Kotlin supports modular multi-agent systems, where specialized agents can be composed into a larger workflow. One agent might gather information, another might analyze it, and a third might prepare the final response.

The advantage is not simply having more models involved. Specialization can give each agent a narrower instruction set and a smaller tool surface. That can make complex workflows easier to test and maintain. The trade-off is additional orchestration and model calls, so a multi-agent design should solve a real separation-of-responsibility problem rather than being added because the architecture looks more sophisticated.

Choose between cloud and on-device Kotlin agents on Android

Android developers get another choice with ADK Kotlin: the model does not always have to run in the cloud. Google documents LiteRT-LM as an on-device backend that can run supported open models locally and supports tool calling. ML Kit can provide access to Gemini Nano on Android, although the current ADK Kotlin documentation describes its ML Kit module as beta and notes that tool calling is not yet supported there.

Firebase AI Logic provides the cloud path for Android. This is significant for credential handling because the ADK Kotlin documentation recommends Firebase AI for Android cloud access instead of embedding a Gemini API key in the application. Developers can therefore build a hybrid system in which simpler or privacy-sensitive work stays on the device while more demanding tasks are delegated to a cloud agent.

Test the agent before treating it as production-ready

A successful conversational response is only the first test. Try inputs that should trigger each tool, inputs that should not trigger a tool, malformed arguments, unavailable services, and requests that should be refused because they exceed the application's permissions. Tool execution should also be tested independently of the model so that an apparently intelligent answer does not hide a broken application function.

For multi-agent systems, test the handoff between agents as well. Verify that the receiving agent gets the information it actually needs and that failures are visible instead of being silently converted into plausible-looking text. The goal is to make the agent's behavior predictable enough that a developer can reproduce a failure and identify whether it came from the model, orchestration, tool implementation, or external service.

What ADK Kotlin 1.0 is useful for now

ADK Kotlin 1.0 is most interesting when Kotlin itself is already part of the application stack. It gives developers a code-first way to define agents while sharing the broader ADK concepts around tools, orchestration, sessions, and multi-agent workflows. Android adds another dimension because the same agent architecture can be connected to local or cloud model backends.

The practical starting point is still small: create one agent, give it one clearly defined tool, run it locally, and verify its behavior before adding more capabilities. Once that foundation works, ADK's multi-agent and Android-specific features give you room to expand without replacing the basic agent model you started with.