Free agents: How AWS Kiro could untie agents from editors

AWS spent the past few months quietly rebuilding Kiro's guts, and the headline fix sounds mundane: it merged three separate agent harnesses — a TypeScript one powering the IDE, a Rust one running the CLI, and a Python one behind the web client — into a single standalone process. But the real story isn't the cleanup. It's that AWS chose to wire that unified agent to its own clients using the Agent Client Protocol, a spec born at Zed and now co-developed with JetBrains, rather than build something proprietary.

That choice matters because it turns the client-agent boundary into an actual interface instead of an internal implementation detail. Kiro's engineers had already tried shared libraries and watched the seams leak — clients kept reaching into internal APIs until the separation was fiction. Running the agent as its own process forced discipline. Now the client only ever talks ACP, whether the agent is executing on a laptop or in a cloud sandbox. AWS did extend the protocol heavily — more than 20 agent-callable methods, 15 client-callable methods, and 20 notification types, all tucked under a _kiro/ namespace, plus a WebSocket transport for web and iOS on top of ACP's usual stdio pipe — but it extended rather than forked, which is the harder and more useful discipline.

AWS isn't the only one landing here. Microsoft shipped Intelligent Terminal 0.1 at Build in June as an ACP client that can find whatever agent CLI happens to be installed, defaulting to GitHub Copilot CLI but not requiring it. JetBrains plugged Junie into ReSharper 2026.2 via ACP in July, calling it an early step rather than a finished product. Three vendors, three different maturity levels, same conclusion: separate the developer experience from the agent implementation, the way the Language Server Protocol separated editors from language intelligence decades ago. Instead of every editor building bespoke glue for every agent — an N-times-M problem — you get roughly N plus M.

Standardizing the wire format doesn't kill differentiation, it just relocates it. Kiro's real competitive edge now sits in governance, not transport. The old CLI used regex-based allow and deny lists; the IDE used prefix matching; neither talked to the other. Kiro replaced both with a single capability model built on Cedar, AWS's formally verified authorization language, governing broad functional buckets like fs_read, fs_write, shell, web_fetch, mcp, and subagent, evaluated across scopes from MDM policy down to individual sessions, with deny always winning. ACP itself only offers bare-bones tool approval, so this policy layer is entirely AWS's own construction — and it's the piece enterprises will actually care about once agent compatibility stops being the interesting question.

The one glaring absence is Visual Studio Code, still the default home for millions of developers, which as of this writing hasn't adopted ACP as its native client-agent boundary — Microsoft's implementation lives in the separate Intelligent Terminal instead. That ACP keeps gaining ground anyway suggests the protocol is winning on architecture, not on some platform forcing adoption. If that holds, picking a coding agent stops being a decision about which editor you're locked into, and starts looking a lot more like picking a language server.