Android’s Agent-First Era: Build-Time vs Runtime

The word “agent” now means two different things in Android, and they are easy to mix up. One is the AI that helps you write your code. The other is the AI you ship inside your app for your users. Google has just released tooling for both in the same season, which is exactly why some people might get confused. That’s the reason the whole article hangs on two lines:

Skills + CLI = build-time, your productivity. ADK = runtime, your product.

Crédits Diego Jimenez

Why all this land now? Development is shifting from “human in the IDE” to “human supervising an agent”, and Google is designing for that openly. At the same time, on-device models like Gemini Nano have matured to the point where they can run real agent logic on a phone. So Google is pushing on two fronts at once: making agents better at building Android apps, and making it easy to put agents into the apps themselves. The rest of the article follows those two fronts.

A useful detail before we split: the build-time side leans on an open standard (agentskills.io), so it is not locked to one assistant, and the runtime side (ADK) is open source. It means (for now?) that Google is competing on tooling and knowledge, not lock-in.

Axis 1: build-time.

Agents that work alongside you while you develop. They read your project, apply current best practices, run migrations, and drive the toolchain. The payoff is your productivity. This is where Android skills and the Android CLI live.

Axis 2: runtime.

A framework to build agents that run inside the app you ship. The payoff is a product feature for your users, often running privately on-device. This is ADK for Kotlin and Android (or Koog from Jetbrains).

Build-time: agents that help you build

Android skills are small instruction files (SKILL.md plus optional resources) that teaches an agent one Android best practice. The agent reads the short description and pulls in the full skill only when it is relevant, so its context stays clean.

**The Android CLI** is one android command that handles SDK setup, emulators, deploy, scaffolding, and docs search. Its standout feature talks to a running Android Studio to analyze files, find symbol usages, and render Compose previews, so the agent can see your code the way the IDE does.

android update          // keep it current
which android           // check it is installed
android init            // set up for agents
android skills list     // see official skills
android skills add --skill edge-to-edge

Community skills are just as easy to add. A strong example is Chris Banes’ repo for Android (github.com/chrisbanes/skills) or the compose performance skills from Skydove (github.com/skydoves/compose-performance-skills)

npx skills add chrisbanes/skills

Use cases

The clearest win is everyday modernization. Ask your agent to make an app edge-to-edge, and with the right skill, it applies the pattern Google recommends today rather than the stale one it learned in training. The same holds for the bigger, more painful jobs: migrating screens from XML to Compose, adopting Navigation 3, or upgrading to AGP 9. These are exactly the multi-step tasks where an agent tends to improvise and drift. A skill turns them into a repeatable recipe, so the result is consistent whether you run it on one screen or fifty.

Performance work is where community skills really shine, because the nuances move faster than any model’s training data. Chris Banes’ repo is a good illustration. His compose-recomposition-performance skill walks an agent through chasing jank and unnecessary recomposition, while compose-state-hoisting and kotlin-flow-state-event-modeling steer it toward the correct state and Flow patterns instead of the lossy defaults a model often reaches for. You are effectively lending the agent the judgment of someone who has debugged these problems for years.

The CLI covers the mechanical half of the loop. From a single script, an agent can scaffold a new project, spin up an emulator, and deploy the build, all without clicking in the IDE. And because skills are just folders you control, a team can package its own conventions, the “how we do things here” rules, into a shared skill so every developer’s agent follows the same playbook.

Axis 2, Runtime: agents you ship inside the app

What is ADK?

The **Agent Development Kit** lets you build and run AI agents within your Android app, not just as a coding helper. It is an open-source framework that supports Kotlin and Java, and the same agent code scales from a single tool-calling agent to complex multi-agent systems. The agent code you write is identical to the standard ADK Kotlin guide; only the Gradle dependency and how you invoke it at runtime differ.

A minimal agent is oneLlmAgent with a name, an instruction, a model, and a set of tools. Tools are plain Kotlin functions annotated with@Tool, and you run the agent from a coroutine, collecting its responses as events to drive your UI. Here is the gist, trimmed from Google's HelloTimeAgent quickstart:

class TimeService {
    @Tool
    fun getCurrentTime(
        @Param("City to get the time for") city: String
    ): Map<String, String> = mapOf("city" to city, "time" to "10:30am")
}

val rootAgent = LlmAgent(
    name = "hello_time_agent",
    description = "Tells the current time in a city.",
    model = Gemini(name = "gemini-flash-latest", apiKey = /* from your backend, never hard-coded */),
    instruction = Instruction("Tell the time in a city using the getCurrentTime tool."),
    tools = TimeService().generatedTools(),
)

The striking part is how few changes are needed to go on-device: swap the Gemini(...) model for one GenaiPrompt backed by ML Kit (GenaiPrompt.create(generativeModel, name = "gemini-nano")) and the same agent now runs offline. You then drive it from a coroutine with an InMemoryRunner, collecting events to update your UI.

The mobile angle: on-device with Gemini Nano

This is the part that makes ADK interesting on phones rather than just another agent SDK. The Android artifact can run inference on-device using Gemini Nano via the ML Kit GenAI API, so an agent can operate without network access and keep data on the device. You can even mix the two: a cloud Gemini model as the orchestrator, with on-device models handling the privacy-sensitive sub-tasks.

One important caveat to flag for readers: never embed API keys in a shipped app. For cloud models, calls should go through your own backend or Firebase AI Logic so keys are never exposed in client code.

ADK is not alone: Koog

It would be misleading to present runtime agents in Kotlin as a Google monopoly. JetBrains ships a direct competitor, Koog, an open-source framework for AI agents in Kotlin and Java covering the same building blocks: tools, workflows, persistence, memory, and observability. Same problem, different philosophy. ADK pulls you into the Google ecosystem and shines if you bet on Gemini Nano on-device, whereas Koog is model-agnostic, leans into Kotlin Multiplatform and OpenTelemetry observability, and runs local models on Android through LiteRT. The practical tie-breaker today is maturity: Koog has reached a stable 1.0 with a one-year API stability guarantee, while the ADK Android artifact is still in its early stages. For a production Kotlin backend, that guarantee is a concrete argument.

Worth noting, JetBrains plays on Axis 1 too, with its own Skill Manager and skill repository, so both vendors are advancing on both fronts at once.

Why is it evolving, and where is it heading?

Step back, and both axes point the same way. AI assistance has moved from autocomplete to agents that can set up, build, test, and, increasingly, run as part of the product. What makes either leap possible is not a smarter model so much as better grounding and better plumbing: the current project context for the coding agent and a clean on-device runtime for the in-app one.

The open-standard, open-source choice matters across both. By not locking developers into a single assistant or runtime, Google leaves room for the community to extend things, and community repos are early evidence that the build-time ecosystem is already growing beyond Google’s own capabilities. On the runtime side, on-device inference quietly shifts what an “AI feature” can be, since it no longer requires a round trip to a server.

Where does it tend?

On Axis 1, toward agents who own more of the upgrade-and-migration treadmill that developers keep deferring. On Axis 2, toward agentic features becoming a normal part of apps rather than a novelty, with privacy-preserving on-device models as the default for sensitive work. The honest assessment for now: all of it is optional. It is genuinely useful if you already work with agents, automate heavily, or want in-app AI; otherwise, it is easy to skip.

But it is the kind of option that tends to become standard quickly.

Takeaways

The one mental model to keep: Skills and the CLI make you faster at building the app; ADK lets you put an agent into the app. Different ends of the lifecycle, same agent-first wave.

Care about Axis 1 now if you are agent-heavy or CI-heavy in your workflow. Care about Axis 2 now if an in-app or on-device AI feature is on your roadmap. Otherwise, keep an eye on both. A good first experiment: run android init with one official skill plus chrisbanes/skills on a side project, and separately wire up the ADK Kotlin quickstart to feel the runtime side.

Sources

• developer.android.com/tools/agents/android-skills
• developer.android.com/tools/agents/android-cli
• github.com/chrisbanes/skills
• developer.android.com/ai/adk
• androidengineers.substack.com/p/announcing-adk-for-kotlin-and-adk
• Koog 1.0 (JetBrains)