Google Releases ADK for Kotlin 1.0, Bringing AI Agents That Run Inside Android Devices

On September 9, Google shipped version 1.0 of the Agent Development Kit (ADK) for Kotlin, its framework for building AI agents. The release brings the Kotlin edition up to the same feature level as the existing Python and Java versions, and it ships with Android extensions built in from the start. The core idea is that the same code style works for server-side Kotlin agents and for mobile AI that runs entirely on the device.

What the 1.0 release brings together

ADK for Kotlin arrived only a few months ago as 0.1.0, and version 1.0 now matches ADK 1.0 Core feature for feature. The pieces you need in production ship as standard: hierarchical multi-agent setups where a parent agent delegates work to specialized child agents, context compaction that summarizes conversation history to stay within token limits, human-in-the-loop flows that pause execution and wait for approval before a sensitive action, and session resumability that saves an interaction and picks it up later. First-party Java interoperability is also included, so existing Java applications can call Kotlin agents directly.

The foundation is a Kotlin Multiplatform (KMP) core. That core stays agnostic to any particular model backend, session provider, or memory system, so the choice between cloud Gemini and an on-device model can be swapped later. For enterprise use, the release also includes service implementations backed by Vertex AI for session management, RAG memory, and memory banks.

Annotations generate the tools

The first thing most developers will touch is defining the tools an agent can call. In ADK for Kotlin, you annotate an ordinary Kotlin function with @Tool and describe its arguments with @Param.

@Tool
suspend fun getServiceMetrics(
    @Param("Target service or database cluster") serviceName: String,
    @Param("Time window in minutes") windowMinutes: Int? = 15,
): ServiceMetrics

From that definition, KSP (Kotlin Symbol Processing) generates the function call definitions at build time. Because no runtime reflection is involved, schema type safety is guaranteed at compile time and suspend functions work as tools without extra wiring. Avoiding reflection also pairs well with Android, where fast startup and predictable behavior matter.

Moving procedures out of the code with skills

The second pillar is skills. Instead of hardcoding the operating procedures you want an agent to follow, you write them in a SKILL.md text file and load them only when they are needed.

For a database incident, for example, the procedure might read: check telemetry, correlate against recent deployments, review the safety rules before acting, then notify the team. Supporting assets can be bundled alongside the file, but the model fetches them only when it decides they are required, so the full text never has to sit in the prompt. Google calls this loading pattern progressive disclosure. When a procedure changes, only the text needs editing, with no rebuild required, which is where the design pays off in day-to-day operations.

Reusing standard Android components

The Android extensions stand out because they lean on existing Android architecture components rather than inventing new machinery to learn. Conversation sessions persist through Room, on-device memory with full-text indexing runs on AppSearch, and generated files land in app-private storage. In practice that means an agent can resume a conversation after the process is killed and the app restarts.

There are also choices on the model side. Cloud inference calls Gemini 3.8 Flash through Firebase AI Logic, while workloads that must stay on the device can switch to LiteRT-LM or ML Kit (beta). The same agent definition can therefore change only where it runs, depending on connectivity and confidentiality requirements. For irreversible actions such as a bank transfer, marking the tool as requiring confirmation makes the agent stop before execution, surface a prompt in the UI, and continue only after the user taps to approve.

Getting started means adding dependencies

Adoption starts with Gradle.

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

    // Optional Android extensions
    implementation("com.google.adk:google-adk-kotlin-firebase-android:1.0.0")
    implementation("com.google.adk:google-adk-kotlin-litertlm:1.0.0")
    implementation("com.google.adk:google-adk-kotlin-mlkit-android:1.0.0-beta")
}

The core engine and the annotation processor are the two required lines, and the Android extensions are added only as needed. Source code and sample applications are published in the google/adk-kotlin repository on GitHub, and the documentation lives at adk.dev.

Summary

ADK for Kotlin 1.0 matches the multi-agent capabilities of the Python and Java editions in Kotlin, then adds extensions that mesh with standard Android components such as Room, AppSearch, and LiteRT-LM. Defining tools through annotations and KSP, and externalizing procedures into SKILL.md with progressive disclosure, reflects a design that splits an agent into code and text so each stays maintainable on its own. It is an update worth watching as a sign that AI agents running entirely inside a smartphone are becoming a practical option.