Google's Android Agents Finished UI Tasks 77% Faster. The Trick Was a CLI, Not Better Docs.

Google opened Android Studio to outside coding agents this week. The headline is "Bring Your Own Agent": more than 40 agents that speak the open Agent Client Protocol (ACP) can now run inside the IDE, including Claude Agent, Codex and Google's own Antigravity. Fine. That's the part everyone will write about.

The more useful detail is buried lower down. Google also shipped an Android CLI as an official plugin for Claude Code, Codex and Antigravity, and says that in its internal tests agents using the android preview command finished UI tasks 77% faster with up to three times fewer tokens. In a separate A/B test, the same CLI helped an agent find and fix memory leaks nearly twice as fast, using about 25% fewer tokens.

Those gains didn't come from a smarter model. The model was the same in both arms. What changed was the tooling around it.

What Google actually built

Three things, and none of them is a chatbot.

• A command line interface that gives agents a fast, scriptable way to preview UI and run checks, instead of clicking through an emulator the way a human would.
• More than 30 "Android Skills", which are small bundles of documentation for specific jobs like Play policy checks and foldable layouts.
• Deep IDE hooks, so an agent can ask for project structure, resolve symbols, read Logcat and use the profiler directly.

Notice what's missing: a better prompt. Google went after the tool surface the agent touches.

Your docs are not an agent interface

Most teams, when they think about agents using their product, point at the docs site and call it done. Docs are written for a person who skims, searches and gives up after twenty minutes. An agent reads all of it, burns tokens on the parts that don't matter, and still guesses at the parts you left implicit.

A CLI with predictable output and a short skill file per task is a different thing. It's narrow, it's cheap to read, and it fails loudly. That's where the "three times fewer tokens" comes from. The agent stops wandering.

If you run a platform, an SDK, an internal API or even a big monorepo, you have the same choice Google had. You can keep improving the prose, or you can ship the thing the agent can call.

Measure it like Google did

The part I'd copy first is the method. Google didn't claim the tooling was better. It ran the same task with and without it and counted time and tokens. That's a test you can run on a Friday afternoon.

Pick three tasks your users (or your own engineers) hand to agents all the time. Run each one with the current setup, then with a thin CLI or a skill file added. Record wall-clock time, tokens and whether the result passed review. If the numbers don't move, you saved yourself a quarter of work. If they do, you now have a business case.

The protocol is the boring part, which is good

ACP is JSON-RPC over a subprocess, governed by a group that includes Zed, JetBrains, GitHub, Google and Cognition. Implement it once and the agent works in any compliant editor. That makes the agent a swappable part, which is healthy. It also means the thing you can still differentiate on is the environment the agent runs in.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!