Saltar para o conteúdo principal
engineering·5 min de leitura

Android Studio Lets You Bring Your Own Agent. Bring Your Own Rules Too

Android Studio Rabbit 2 runs more than 40 coding agents, from Claude Agent to Codex, with real Android tools. The choice is good. The rules are still yours to write.

Por Pedro Pinho·3 de Novembro de 2026·Atualizado 3 de Novembro de 2026
Android Studio Lets You Bring Your Own Agent. Bring Your Own Rules Too

Google released Android Studio Rabbit 2 on 28 October 2026 with a feature it calls Bring Your Own Agent. You can now run more than 40 coding agents inside the IDE, including Claude Agent, OpenAI's Codex, JetBrains' Junie and Google Antigravity, according to Google's announcement. That is good news for Android teams. It also means the question changes. It is no longer "which agent does the IDE give us?" It is "which agents do we allow, and what may they do?"

What did Google actually ship?

Rabbit 2 is a stable release, ready for production use. The parts that matter for agents:

  • Bring Your Own Agent. Any agent that speaks the Agent Client Protocol (ACP) can run in the agent window. You pick one in Settings > Tools > AI > Agents, sign in and start.
  • Real tools for the agent. Agents can use the Android Emulator, the build system and Logcat, plus Android skills for tasks like moving XML views to Jetpack Compose or upgrading to AGP 9.
  • A skills manager. You can see, install and remove the skills an agent is allowed to use.
  • Change Review. An AI review of agent changes, pending commits or the Git log, with recommended fixes and a guided walkthrough of the diff.
  • Admin policies for Gemini Enterprise. IT can define approved skills, agents and model endpoints across teams.

At the same event, The Decoder reports, Google also made its Android CLI available as an agent plugin for Claude Code, Codex and Antigravity. Google says its internal tests showed UI tasks finishing 77% faster with up to three times fewer tokens. Those are Google's numbers on Google's tests, so treat them as a reason to try it, not as a result.

Why is choice a good thing here?

Because the agent was never the hard part. The Android tooling was.

Until now, a general coding agent could edit Kotlin files but could not easily see the emulator, read Logcat or run the right Gradle task. So it guessed. Giving any agent the same Android tools means you can pick on what matters to you: quality on your code, price, or the provider your company already has a contract with. Google says as much in the announcement. If you need a specific provider "to align with an enterprise agreement", you can have it.

What does the choice leave to you?

Everything that is not a button in the IDE.

Forty agents means forty possible places your code can go. Each agent signs in to its own provider, with its own terms on data retention and training. If every developer picks their favourite, you end up with a codebase sent to five companies and no record of which.

The tools the agent gets also deserve a second look. Running the emulator and reading Logcat is low risk. Running any Gradle task is not. A build can sign a release, upload to a store or call a script that reaches your backend. An agent that can run builds can, in principle, do all of that.

What rules would I write?

  • A short list of approved agents. Two or three, chosen on your own code, with providers whose data terms you have read. If you are on Gemini Enterprise, put the list in the admin policy so the tool enforces it.
  • No release keys on developer machines. Signing and store uploads belong in CI, behind a person's approval. Then it does not matter which agent can run Gradle.
  • Skills are code. A skill tells the agent how to do a task. Review new skills like you review a dependency, and remove the ones nobody uses.
  • Review stays human. Change Review is a useful first pass. It is not the approval. A named person still reads the diff and merges it.

Should Android teams switch agents now?

Not because of this release alone. If your current agent works well on your code, keep it, and use Rabbit 2 to give it better tools. If you have been stuck with an agent you do not like because it was the only one inside the IDE, this is the moment to run a fair comparison.

Run it on your own app. Take five real tickets: a crash from Crashlytics, a layout bug on a foldable, a Compose migration, a dependency upgrade, a small feature. Give each agent the same tickets and read every diff. Count how many you would merge without changes. That number tells you more than any benchmark.

We compared the general-purpose harnesses in Best AI Coding Agent Harness in 2026. The same advice holds inside Android Studio. Pick on your own work, then set the permissions before the first prompt, not after the first incident.

Where Alongside fits

Choosing which coding agents a team may use, and what they are allowed to run, is the kind of work covered by Alongside's technical advisory.

android studiobring your own agentcoding agentsagent client protocolandroid development

Partilhar este artigo