Your IDE Stopped Choosing Your Coding Agent: What the Agent Client Protocol Changes for Engineering Teams
Android Studio now accepts any coding agent that speaks the Agent Client Protocol, joining JetBrains IDEs and Zed. The editor and the agent have become two separate purchases. That makes agents easier to switch and compare, and it makes them harder to govern. Here is what engineering leaders should decide before every developer picks their own.
What Changed When Android Studio Opened Its Doors?
On 24 September 2026, Google announced Bring Your Own Agent for Android Studio. Developers can now connect a third-party coding agent directly inside the IDE, with Anthropic's Claude Agent, OpenAI's Codex and Google's own Antigravity as launch partners. The built-in Gemini agent is still there, but it is now one option among several in the same agent window.
The interesting part is not the partner list. It is how the feature is wired. Android Studio gives any connected agent the full project graph, build configuration, Compose Previews, Android SDK tools and emulator control, and it lets agents act on their own for routine work while pausing for approval on riskier actions. Google even calls out a scenario that would have sounded odd two years ago: if one agent runs out of quota or underperforms, another one can take over the same task.
Android Studio is following others here. JetBrains announced in October 2025 that it would co-develop the Agent Client Protocol with Zed and support it natively in IntelliJ IDEA, PyCharm and WebStorm. Zed then reached version 1.0 at the end of April 2026, with external agents running side by side as a headline feature. Three of the main IDE families for professional developers now treat the coding agent as a plug-in rather than a built-in product.
For most of 2024 and 2025, choosing an AI coding tool meant choosing an editor. You picked Cursor, Windsurf, Copilot in VS Code or JetBrains with its own assistant, and the agent came bundled with it. That bundle is coming apart. For engineering leaders, the decision has become two decisions, and most tooling policies were written when it was only one.
Key Takeaways
- Android Studio added ACP-based Bring Your Own Agent support in preview on 24 September 2026
- JetBrains IDEs and Zed already run external agents through the same protocol
- Editor choice and agent choice are now separate decisions, and policies need to reflect that
What Is ACP, and How Is It Different From MCP?
The Agent Client Protocol is an open standard, built on JSON-RPC 2.0, for the conversation between an editor and a coding agent. In the stable specification, the editor launches the agent as a subprocess and talks to it over standard input and output, organizing work into sessions and turns. The editor shows diffs, asks the user for permission and exposes files and terminals. The agent does the reasoning and the edits. People often describe it as the Language Server Protocol for agents, and the comparison holds: LSP meant a language only needed one server to work in every editor, and ACP means an agent only needs one integration.
It is easy to confuse ACP with the Model Context Protocol, which we covered in our piece on how MCP is rewriting software architecture. They solve different problems and stack on top of each other. ACP connects the editor to the agent. MCP connects the agent to tools and data, such as your issue tracker, database or internal APIs. A third standard, A2A, connects agents to other agents. A modern setup can use all three at once: a developer prompts an agent in JetBrains through ACP, the agent pulls a ticket through MCP, and it hands a subtask to a review agent through A2A.
The ecosystem has grown quickly. JetBrains and Zed launched a shared ACP registry in January 2026, and by October it listed 42 agents, including Claude Agent, Codex, Gemini CLI, GitHub Copilot, Cursor, Goose, Cline, Junie and OpenCode, with 19 editors and IDEs listed as clients. Neovim, Emacs and Sublime Text connect through plugins.
There is one large gap. VS Code, still the most widely used editor, has no native ACP support, and its tracking issue remains open. Microsoft's position, as a VS Code engineer put it when JetBrains joined, is that not everything an agent SDK offers is available via ACP, so it prefers deeper, agent-specific integrations. If your team lives in VS Code, the portability is partial for now. If it lives in JetBrains, Android Studio or Zed, the portability is already here.
| Protocol | Connects | Typical question it answers | Origin |
|---|---|---|---|
| ACP (Agent Client Protocol) | Editor to coding agent | Can I run this agent inside my IDE? | Zed, 2025, co-developed with JetBrains |
| MCP (Model Context Protocol) | Agent to tools and data | Can the agent read my tickets, logs or database? | Anthropic, November 2024 |
| A2A (Agent2Agent) | Agent to other agents | Can one agent delegate work to another? | Google, 2025, now under the Linux Foundation |
Key Takeaways
- ACP standardizes the editor-to-agent link; MCP standardizes agent-to-tool access
- The ACP registry listed 42 agents and 19 editor clients as of October 2026
- VS Code has no native ACP support yet, so portability depends on where your team works
Why Does Separating the Editor From the Agent Matter Now?
Agents are no longer an experiment. JetBrains' 2026 Developer Ecosystem research, covering more than 15,000 developers, found that 90% use coding agents at least weekly and 68% use them daily. When a tool sits in the middle of daily work, the cost of switching it matters a great deal, and until recently, switching agents meant switching editors, keybindings, extensions and habits.
The market also keeps moving under teams' feet. In our article on the Cursor cutoff and AI tool continuity, we walked through three times in eighteen months when a corporate decision changed which models a coding tool could offer. Each time, teams that were tied to one bundled product had to wait for fixes. With ACP, a team that loses access to one agent can switch to another in the same editor, with the same project context, in an afternoon.
Leaderboards also shift every few weeks. Reports from the same JetBrains survey say Claude Code overtook GitHub Copilot as the most-used AI tool at work, a change that would have looked unlikely a year earlier. Agents differ by language, codebase size and task type, and the best agent for refactoring a legacy Java service may not be the best one for building a Compose screen. A protocol that lets developers use the right agent for each task, without changing their environment, matches how the work is actually done.
Finally, there is quota. Usage limits and per-token pricing mean that a heavy agent user can hit a ceiling mid-sprint. Google designed Android Studio to let a second agent pick up when the first runs dry. That is useful for productivity, but it also means a single developer's work may pass through two or three vendors in one day, which matters for the governance questions below.
What Gets Easier: Evaluating Agents on Your Own Code
The biggest practical win is evaluation. Comparing coding agents used to mean asking volunteers to install a new editor for two weeks and report back based on impressions. Now you can run the same task, in the same IDE, with the same project context, through three different agents and compare the diffs. That turns an argument about preferences into a small, repeatable experiment.
A good internal evaluation does not need a research team. Pick ten to twenty real tickets from your recent backlog that cover your common work: a bug fix, a small feature, a test-writing task, a dependency upgrade and a refactor in a messy module. Run each through two or three candidate agents with identical instructions. Measure what matters to you: how many attempts it took, whether the result passed CI, how much a reviewer had to change, and how many tokens or dollars it cost. Repeat every quarter, because the results will change.
Portable conventions make this work. Agents are only comparable if they read the same instructions. Project-level files such as AGENTS.md and the reusable skill files we described in our piece on agent skills belong to the repository, not to one vendor. If your coding standards, test commands and architectural rules are written there, every ACP agent inherits them. If they sit in a vendor-specific settings panel, you will be rewriting them every time you switch.
Procurement improves too. When the editor and the agent are separate line items, you can negotiate them separately, keep a second agent under contract as a fallback and avoid a full migration if one vendor raises prices. For a 50-person engineering team, that negotiating position is worth real money.
What Gets Harder: Governance, Sprawl and the Remediation Bill
The same openness that makes agents easy to switch also makes them easy to multiply. With 42 agents a click away, a 40-person team can easily end up with a dozen in use, each with its own data retention terms, model providers, permission defaults and billing. Few security teams can answer basic questions about that: which agents have read our source code this month, where did that code go, and which ones can run shell commands without asking?
The protocol helps less than you might hope. ACP standardizes the wire format, not the quality or safety of the agent on the other end. According to one detailed review of the protocol, the registry is curated but shows no usage statistics or reviews, and remote transports such as streamable HTTP and WebSocket only moved into active development in July 2026. A protocol that is still maturing, connected to agents that vary a lot in reliability, needs more oversight from your own team, not less.
There is also a cost that rarely shows up in tool budgets. An ActiveState survey of 307 security, platform and engineering leaders, released in October 2026, estimated that engineers spend at least 139 hours a year fixing issues introduced by AI-assisted development, roughly the capacity of seven full-time engineers for every 100. It is a vendor-commissioned estimate and should be read that way, but the direction is consistent with what we see in client codebases. Each additional agent in use brings its own habits and its own failure modes, and your reviewers have to learn all of them.
The upside is that the IDE now sits between the agent and your machine. JetBrains describes the model as one where the IDE mediates access to files, the terminal and other tools. That gives you one place to enforce permission defaults across every agent, instead of configuring each vendor's tool separately. The control point exists. Most teams just have not used it yet.
Key Takeaways
- Easy switching can quickly turn into a dozen unmanaged agents with different data and permission terms
- ACP standardizes the connection, not the agent's reliability or safety
- The IDE is now a single place to enforce permissions across every agent, so use it
The Policy You Need: An Approved Agent List, Not an Editor Mandate
Many companies still answer the AI tooling question with an editor mandate: everyone uses Cursor, or everyone uses Copilot in VS Code. With ACP, that approach controls the wrong thing. A better policy standardizes the layers that carry risk and leaves room for choice in the layers that do not.
Start with an approved list of agents, usually two or three. Each one should have a signed data processing agreement, a known model provider, clear retention terms and an enterprise plan you control, not a developer's personal subscription. Approve agents for specific uses if you need to. A fast, cheap agent might be fine for test generation, while a stronger one is reserved for changes to authentication or payments.
Next, set permission defaults centrally. Decide which actions agents may take without asking, such as reading files, running tests and editing within the working tree. Decide which actions always need approval, such as network calls, package installs, Git pushes and anything that touches credentials. Encode those defaults in IDE configuration that is checked into the repository or distributed through your device management, so a new developer gets them on day one.
Finally, put the knowledge in the repository rather than in the tool. Instruction files, skills, MCP server configurations and test commands should live in version control and be reviewed like code. That is what lets you switch agents in an afternoon, and it is also what keeps a consistent standard when five developers are using three different agents on the same codebase.
What This Means for Outsourced and Nearshore Teams
Bring Your Own Agent raises an obvious question for anyone working with an external engineering partner: whose agent is it? A vendor's developers may arrive with their own subscriptions and preferences, and with ACP it takes them a minute to connect an agent to your codebase that you have never reviewed. If your contract and onboarding do not say which agents may touch your code, you have effectively let your partner decide.
At Stepto, we treat the agent as part of the delivery setup we agree with each client, not as a personal choice. Our dedicated development teams work with the client's approved agents, under the client's enterprise accounts where possible, so data processing terms and audit trails stay with the client. Where a client does not yet have a policy, we help write one, starting with an approved list, permission defaults and a repository conventions file, and then we use that same setup ourselves.
Portability also helps the client. Because our engineers keep coding standards, test commands and architectural rules in the repository rather than in a tool's settings, the client can change agents, or bring the work in-house, without losing the conventions that made the agents useful. That is the same principle we apply to code ownership in general: nothing important should live only in the vendor's head or the vendor's tools.
Time zones matter more than people expect. Agent policies change often, as vendors adjust terms, models get deprecated and new agents join the registry. A nearshore team in Serbia works the same hours as European clients and overlaps the morning in the US. When a policy changes, it can be discussed and applied the same day, rather than discovered in a code review a week later.
A 90-Day Plan for Moving to Bring Your Own Agent
In the first 30 days, take inventory. Ask every developer, including contractors, which agents they use, through which accounts and on which repositories. Expect surprises. Then pick two or three agents for a formal trial and confirm their data processing terms before anyone uses them on production code.
Between days 30 and 60, run the evaluation. Use ten to twenty real tickets, the same instructions and the same IDE through ACP. Record pass rates, review effort and cost per task. At the same time, move your conventions into the repository: an AGENTS.md or equivalent, skill files for recurring tasks and the MCP configuration your agents need. Write down your permission defaults and ship them as configuration.
Between days 60 and 90, publish the policy and make it routine. Announce the approved agents and what each is approved for, retire unapproved accounts, add agent usage to your security review checklist and schedule a quarterly re-evaluation. Include your outsourcing partners explicitly, both in the policy and in the contract.
None of this requires a large platform team. It requires one engineering lead with a mandate and a few weeks of focused effort. If you do not have that capacity in-house, it is exactly the kind of work a small embedded team can take on alongside your roadmap.
Key Takeaways
- Days 1 to 30: inventory every agent, account and repository in use, contractors included
- Days 30 to 60: compare candidate agents on real tickets and move conventions into the repo
- Days 60 to 90: publish an approved list with permission defaults, and re-evaluate every quarter
The Bottom Line
The Agent Client Protocol has turned the coding agent from part of the editor into a component you choose, test and replace. That is good news for teams that hated being locked into one bundle, and it is a real risk for teams that never decided which agents may touch their code. Teams that handle this well will standardize on fewer things, but the right ones: an approved list of agents, permission defaults enforced in the IDE and conventions that live in the repository. If you want engineers who already work that way and can help set up the policy while shipping your roadmap, a dedicated nearshore team from Stepto is a good place to start.
Building a team in Eastern Europe?
StepTo builds dedicated nearshore engineering teams in Belgrade, Serbia. Engineers start in 2-4 weeks, with a two-week paid trial and from $4,500 per developer per month.
