I have changed code editors three times in five years and lost something every time. Snippets, key bindings, the reflex that knows which corner of the screen holds your files. None of that stung the way losing a configured assistant would, and that is the specific cost AWS is aiming at with the Agent Client Protocol inside Kiro. It is the most interesting thing I have read about agent tooling in months, and I want to be clear that I am reacting to the reporting rather than to hands-on time with the product.
The idea is small enough to state in one line. An assistant should not be a feature of the editor that happens to contain it. Let the editor do editing, let the agent do the agent’s work, and let the two negotiate over a documented wire format, the same arrangement editors already have with language tooling.
The lock-in nobody wants to name
What ships today as an agent-first development environment is, mostly, an agent in an editor costume. Open Cursor and you get Cursor’s agent. Open Windsurf and you get Windsurf’s. Run VS Code with Copilot and you get a third, with its own memory, its own shortcuts, and its own bill. Changing editors means starting over with an assistant that took a long time to get useful.
That friction gets tolerated because there is no alternative on offer. It is also, structurally, exactly the sort of thing a protocol dissolves, and the industry has done this before with a result everyone liked.
Why the language server comparison actually fits
Anyone who has moved between editors on the same codebase has been collecting the dividend from this pattern for years without thinking about it. Microsoft introduced a standard message format in 2016 so that completion, hover documentation, and jump-to-definition could run as their own program, reachable by any editor that spoke the format. Before it, every editor maintained its own partial implementation for every language, and the quality varied by whoever cared enough to maintain it. After it, almost none of them had to.
ACP aims the same move at agents. The agent takes the position the language server occupies. The editor stays an editor. The wire format carries the contract between them.
Concretely, per the source: the editor describes context to the agent, meaning the current file, the selection, recent edits. Replies come back as instructions to act, along the lines of applying a change, executing something, bringing up a different file. Neither side needs to know who wrote the other, which is the entire benefit.
What Kiro brings that a specification alone would not
Kiro is AWS’s spec-driven environment, which the source describes as less about conversing with your code and more about writing a structured specification and letting the agent produce an implementation you review as a diff. That shape gives ACP something substantial to standardize, covering the full loop of planning, editing, testing, and review rather than chat alone.
A few details make the effort worth watching, again as reported rather than as anything I have verified:
- AWS is shipping the protocol inside a real product, which matters because specifications without a working implementation tend to die quietly and without ceremony.
- The editor side has a head start, with Zed, JetBrains, and VS Code having shipped or begun Model Context Protocol integrations already.
- ACP sits one layer beneath MCP, moving the question from whether an agent can call tools to whether the editor and the agent can be separate programs at all.
- A specification-first design changes the interaction, closer to a colleague handing over a change request than a chat window guessing at your repository layout.
That last point is the one I would watch most closely, because it is the part that has to survive contact with people who review code for a living. A diff attached to a written intent is reviewable. A diff that arrives with no stated goal is a puzzle, and reviewers correctly resent being handed puzzles.
Trade-offs
Governance is the first problem, and it is not a small one. ACP would let your agent speak to an editor AWS did not write, but Kiro’s agent remains Kiro’s agent. Real vendor neutrality would mean a foundation setting the direction. As things stand, AWS sets the pace, and everyone else is choosing whether to follow it.
Personality is the second problem. A wire format standardizes plumbing, not experience. Conversation history, custom instructions, repository-scoped memory, and the behavior of applying a change to a file all differ across tools in ways that a message schema does not touch. The source expects a rough first year, which sounds about right for any protocol that has to encode taste.
Displacement is the third problem and the one I find most interesting. Lock-in does not disappear here, it relocates. An assistant that has accumulated knowledge of a repository and the habits of the people working in it becomes expensive to abandon, in exactly the way editors used to be. ACP has nothing to say about that, and the source is straightforward that this is the next frontier rather than a solved case.
None of those three cancel the idea. They do mean the honest pitch is narrower than the marketing will be: this fixes one specific coupling, and creates room for a different one.
Where I would start
Reading the specification is the cheapest possible first step. Twenty minutes with the message shapes on GitHub is enough to judge whether the model matches how you actually work, which is a better use of an evening than another opinion piece.
Trying Kiro on a side project is the second. Switching your primary editor is not the point and would be a bad idea anyway. The point is to feel what it is like when the agent and the editor are genuinely separate processes, because that is difficult to reason about in the abstract.
Checking your current tools is the third. Anyone on JetBrains or VS Code can find out whether their existing agent already speaks some version of this, and if it does, that is a meaningful signal about where that vendor thinks things are going.
Bottom line
The lesson from language servers took roughly three years to land. By the end of that stretch, writing a bespoke integration per editor had gone from normal practice to an obvious mistake, and nobody argued about it anymore. Agents are somewhere behind that curve, and the source puts the gap at about two years.
My read, offered as opinion rather than as reporting: this is worth tracking closely and not worth reorganizing your workflow around yet. A protocol with one vendor shipping it is a proposal. A protocol with three is a standard. The number to watch is not what AWS announces next, it is how many editors and how many agent vendors implement the thing without being asked to.
If I could send a message back to the version of me who last migrated editors, I would say three things.
- The editor was never the expensive part. Key bindings come back in a week. Accumulated context does not.
- Favor tools that treat the agent as a separate process. Anything welded into one application is a decision you will pay to reverse.
- Watch for the second lock-in before it arrives. Whatever holds your project knowledge is the thing that will be hard to leave, and right now almost nothing lets you take it with you.