Google ADK for Kotlin reaches version 1.0 with feature parity to Python

Google has released Agent Development Kit (ADK) for Kotlin 1.0, a framework for building AI agents that now reaches feature parity with the Python and Java versions of ADK, according to an InfoQ report. This means teams already living in the JVM/Android ecosystem no longer need to jump to Python just to write a project's agentic logic: orchestration, tools, memory, persistence, and human-in-the-loop workflows now have idiomatic APIs in Kotlin.

ADK for Kotlin is built on Kotlin Multiplatform, which means the same agent code runs both in server-side applications and on mobile devices. According to Google, the architecture is "completely agnostic to specific model backends, session providers, or memory systems," meaning it doesn't lock developers into a single LLM provider or a single way of persisting state.

What's new in version 1.0

The list of features arriving with this release is what actually closes the gap with Python and Java:

• Hierarchical multi-agent systems, in which a parent agent can delegate tasks to child agents;
• Context compaction and multi-turn conversations, with automatic context management and history summarization to reduce token consumption;
• Session management, allowing an agent's state to be paused, serialized, and restored;
• First-class Java interoperability, relevant for any legacy Java codebase that needs to incorporate agents without rewriting everything.

For those maintaining long-running systems or services that need to survive restarts, session management is the item that solves a real practical problem: agents that get stuck in long loops or that need to be resumed after a process failure.

Compile-time typed tools

One of the most relevant design decisions in ADK for Kotlin 1.0 is how it handles tools that the agent can call. Instead of relying on runtime reflection, as is common in Python agentic frameworks, Kotlin uses the @Tool and @Param annotations, processed by KSP (Kotlin Symbol Processing) to generate function schemas at compile time.

In practice, this trades runtime cost for build-time checking, with two effects: stronger type safety (a tool signature error breaks the build, not production) and less startup overhead, which matters on mobile targets, where every millisecond of cold start counts. Arjun Kumar, an Android engineer at PiNCAMP, commented on the release on LinkedIn, saying that "handling tool schemas at compile time with KSP keeps startup fast on mobile targets."

Human confirmation before sensitive actions

ADK for Kotlin also formalizes human-in-the-loop workflows through the requireConfirmation flag in a tool's declaration. The example given by Google is straightforward:

@Tool(
 name = "transferFunds",
 requireConfirmation = true
)
fun transferFunds(...)

With this, any high-impact action (a bank transfer is the example used, but it applies to any destructive or irreversible operation) requires explicit user approval before it's executed. Combined with Android's native persistence services, the framework allows chat sessions to be stored in Room, indexed memory in AppSearch, and files directly in device storage.

Joske Vermeulen, who runs the AI Dev Weekly newsletter, gave practical advice on how to adopt this feature: start with a single resumable agent and explicit tool confirmation before moving on to an agent hierarchy, because "production maturity depends more on lifecycle recovery and deterministic tool boundaries than on the number of agents." It's a direct counterpoint to the hype around complex multi-agent architectures: ADK offers the building block, but the recommendation from those who have already tested it is simplicity first.

Skills and on-demand procedural knowledge

Another new element is skills, a way of managing procedural knowledge stored in SKILL.md files. These files are dynamically loaded only when needed, in what Google calls progressive disclosure. This avoids having an entire domain-specific playbook enter the model's context on every call, saving tokens and reducing the cost of each agent interaction, a real problem for anyone paying per API token in production.

On-device AI: the Android differentiator

The part that doesn't exist in the Python and Java versions is the Android-native feature set for combining local and cloud AI. For on-device inference, ADK for Kotlin supports both LiteRT-LM and ML Kit (the latter still in beta). For hybrid scenarios, the framework integrates with Firebase AI Logic, allowing the Android app to run the agent locally when possible and fall back to the cloud model when the task requires more capability.

For Brazilian Android developers, this combination solves a concrete market problem: unstable or expensive connectivity across much of the country makes local inference not a luxury but a UX necessity. An agent that degrades in a controlled way, from device to cloud, is more defensible in production than an app that freezes without 4G.

What remains open

ML Kit remains a beta feature, so teams that depend on API stability may prefer to start with LiteRT-LM. It's also worth noting that ADK for Kotlin is open source and available on Google's GitHub, which allows auditing how routing between the local model and the cloud model is decided internally before putting this into production with sensitive user data.

For those already maintaining agents in Python with ADK and considering migrating parts of the system to Android or to a JVM back-end, the announced parity is a signal that portability has stopped being a promise and become a practical call: it's now possible to write the agent logic once in Kotlin Multiplatform and reuse it both on the server and in the app.