A company that had just shipped its own coding agent opened the same panel in its own IDE to more than forty rivals, Anthropic's and OpenAI's among them. That is not a concession, and reading it as generosity misses the move: look at what the visiting agent is actually handed and you can see which half of the stack Google thinks is worth owning. The guest brings a model. The host keeps the emulator, the build system, the log stream, the project context and the skills — and the switching cost that collapsed last week was yours, not theirs.
What shipped
Android Studio Rabbit 2 went stable with a feature called Bring Your Own Agent, announced at the Android Dev Summit in Mountain View on 28 and 29 October 2026. It is built on the Agent Client Protocol — an open protocol, not a Google one, and worth spelling out because at least one outlet reported it as the "Agent Context Protocol," which is a different thing entirely.
| Piece | What it is | Where it runs |
|---|---|---|
| Bring Your Own Agent | Agent picker in the IDE, 40+ ACP-compatible agents | Android Studio Rabbit 2, stable |
| Named options | Claude Agent, Codex, Junie, Google Antigravity | Same window, same tools |
| Tool access granted | Android Emulator, build systems, Logcat, Android skills | Host-provided |
| Android CLI plugins | Plugins for Claude Code and Codex | Terminal and CI, no IDE |
Setup is a picker: open the agent window, or go to Settings, Tools, AI, Agents, choose an agent, authenticate with that vendor, and send a prompt. The authentication step is the quiet part — you sign in to the agent's vendor, not to Google, which tells you whose relationship the model call belongs to.
The tools are the asset
Enumerate what an Android coding agent needs in order to be useful and almost none of it is the model. It needs to build the project, which means the build system and its cache. It needs to run the app, which means the emulator. It needs to see what happened, which means Logcat. It needs to know what the project is, which means the indexed source and whatever conventions the repository carries. Rabbit 2 hands a visiting agent all of that, plus the Android skills — the packaged, platform-specific instructions that encode how Android work is actually done.
That bundle is expensive to build and nearly impossible for an agent vendor to replicate from outside. An agent without it is a chat window that guesses at your Gradle configuration; with it, the same agent can compile, install, run, read the crash and try again. So the model becomes the cheap, swappable layer — exactly what a forty-option picker tells you it is — and the tool surface becomes the thing you cannot route around. Google gave away the part that commoditised itself and kept the part that did not.
This is the same structural point the agent harness argument makes from the other direction: the capability you observe is a property of the harness at least as much as the model, which is why leaderboards that rank a model on one scaffold keep failing to predict what a different scaffold does. Rabbit 2 is that claim turned into a product decision — one tool surface, forty interchangeable models, and the surface is the moat.
The CLI plugins are the tell
If the thesis were simply "own the IDE," the sensible follow-up would be to make the Android tool surface reachable only through the IDE window. Google did the opposite in the same breath: the Android CLI picked up plugins for Claude Code and Codex, so the same agents can work from a terminal or inside CI with no IDE running at all.
That is a bet that the valuable thing is the tool surface rather than the window onto it. It also happens to be the right call for where coding agents are going — the long-running, unattended job belongs in CI, not in a panel somebody has to keep open, and an agent that can only be driven from a GUI cannot be put on a schedule. Shipping both doors at once means the host does not have to guess which one wins.
For readers, the practical consequence is narrower than the strategy: you can now standardise on one agent across the IDE and your pipeline, or run different ones in each, without rebuilding the integration. The agent became a configuration value.
What this changes for you
The useful inversion is this: for the last two years the advice on picking a coding agent was to evaluate the agent. That advice is now close to backwards for Android work, because the agent is the layer you can change on Tuesday and the tool surface is the layer you inherit. If you are choosing, spend your evaluation budget on whether the host exposes what your workflow needs — can the agent run an instrumented test, read a crash from a physical device, see your build variants — and treat the model as a thing you will swap twice a year anyway.
If you are building an agent, the risk that matters stopped being a benchmark position. Forty competitors in the same picker means your differentiation has to survive being handed identical tools, and the existential risk is being cut off from a host's surface rather than losing a leaderboard. Which is a strong argument for implementing ACP rather than a bespoke IDE plugin: the protocol is the thing that makes you present in a window you do not own.
The part nobody standardised
An open protocol for connecting agents to tool surfaces is good, and it is worth being clear about what it does not carry. ACP standardises how an agent connects and converses with a host. It does not specify which tools a given guest may reach, under what authorisation, with what audit trail — and the list of tools on offer here is a capable one. An agent with the build system, the emulator and Logcat can execute code on your machine, read your application's runtime output, and modify your source tree.
That is the right capability set for the job and it is also the blast radius. The host decides what to lend; the protocol will not decide it for you, and a picker with forty entries is forty different vendors' software reaching the same surface on your machine. The questions to ask of a host are the ordinary ones — what does a guest agent get by default, can you narrow it, does anything record what it did — and they are questions about the IDE's authorisation model rather than about the protocol. The Agent Client Protocol covers what the spec does and does not undertake; vetting a third-party skill covers the other half of what Rabbit 2 now loads, since Android skills are content an agent executes against your project.
None of this makes the feature a bad idea. It makes it a feature whose security properties are set by the host, in a window where the host has just invited forty guests.
FAQ
What is Bring Your Own Agent in Android Studio?
A feature in Android Studio Rabbit 2, now stable, that lets you run a third-party coding agent inside the IDE's agent window. It is built on the Agent Client Protocol and supports more than forty ACP-compatible agents, with Claude Agent, Codex, Junie and Google Antigravity among the named options.
Which protocol does it use?
The Agent Client Protocol, an open protocol for connecting coding agents to host editors. Note that at least one report called it the "Agent Context Protocol," which is a different name for a different thing.
What can a visiting agent actually do?
Google's documentation lists access to Android Studio tools including the Android Emulator, build systems and Logcat, plus the ability to use Android skills. In other words it can build, run, observe and modify the project — which is the point, and also the blast radius.
Do I need the IDE to use these agents?
No. The Android CLI separately added plugins for Claude Code and Codex, so the same agents work from a terminal or in CI with no IDE running. That is the better place for long-running unattended jobs.
Who pays for the model calls?
You authenticate with the agent's own vendor during setup, so the model relationship is between you and that vendor rather than running through Google. Check each vendor's terms for the specifics — the setup flow tells you whose account is being used, not what it costs.
Does this mean the choice of coding agent no longer matters?
It matters less, and differently. The agent is now the layer you can change without rework, while the host's tool surface is the layer you inherit — so evaluate whether the host exposes what your workflow needs before you spend long comparing models.
Further reading
On this wiki:
- The Agent Client Protocol — what the spec covers, and what it leaves to the host.
- The agent harness — why measured capability belongs to the scaffold as much as the model.
- Agent skills — the packaged instructions an agent loads against your project.
- Coding agent architecture — how the pieces fit when you build one yourself.
- Vetting a third-party skill — reviewing content an agent will execute.