Kiro, an agentic development tool that ships as an IDE, a CLI and a web app, used to run three separate agents behind those three clients. The IDE’s agent ran on TypeScript because that is what the Code OSS extension model expects, the CLI’s agent ran on Rust for raw speed, and the web client’s agent ran on Python to stay close to current agent research. Each team built its own orchestration layer, and the three drifted apart.
The drift showed up first in permissions. The CLI used regex-based allow and deny lists for commands. The IDE used prefix matching on trusted commands and a separate substring-based denylist. A rule written for one client did nothing in the other, and a single intent like blocking reads of a .env file had to be configured tool by tool, client by client. Spec-driven development worked only in the IDE. Plan mode worked only in the CLI. Kiro’s engineering team, writing on the company’s own blog, said each capability shipped had to be coded and patched three separate times, and users saw different behavior depending on which client they opened.
The fix was to pull the agent out of the clients entirely. Kiro now runs a single agent harness, the piece of software that runs the reasoning loop, executes tools, hands off to sub-agents and tracks session state, as its own standalone server process rather than a library each client compiles into itself. The IDE, CLI, web app and a new iOS client all talk to that one process instead of embedding agent logic of their own.
This is the part that generalizes well past Kiro. When agent logic lives inside each client, three teams end up shipping three interpretations of the same behavior, and small choices, like how a long context window gets summarized, quietly diverge. A bug found in one client has to be found and fixed again in the other two, and a feature built for one has no path to the others without a second implementation. Putting the agent behind a protocol boundary removes that duplication by construction: there is one reasoning loop, one set of tool calls, one permission check, and every client becomes a renderer of what that single process reports back.
Kiro picked the Agent Client Protocol, an open specification for agent-client communication that hit version 1.0 in June 2026 and already has support in Zed, JetBrains IDEs, Xcode, Obsidian, Emacs and Neovim. Kiro extended the base spec into what it calls Kiro-ACP, with custom methods namespaced under a _kiro/ prefix so its own clients get extra features without forking the protocol everyone else relies on. By the company’s count, the extension layers on more than 20 methods the agent can call, roughly 15 the client can call, and about 20 notification types layered onto whatever base ACP already covers: starting and ending a session, streaming messages and reporting on tool calls.
What actually crosses the wire is narrow: requests to run a tool, streamed output, permission prompts and status notifications. What stays on the server is everything that decides what the agent does next. Local clients connect over stdio, running the harness as a child process. For the web and iOS clients, Kiro built a custom WebSocket transport so they can reach a harness that starts up inside a cloud sandbox instead of on a laptop. The IDE shows the results in side panels, the CLI prints them to a terminal, and the web client renders them in a browser with multi-user review, all sourced from identical agent output. Clients can still swap in native tools. The IDE uses Code OSS’s file APIs instead of the harness’s default file tools, and the harness simply calls out to whatever the client advertises.
The payoff Kiro points to is that a harness-only change, such as the live custom agent reload feature it shipped recently, reaches every client without a line of client code touched. That is the actual claim worth testing: an agent that can be rewritten, retuned or rehosted without renegotiating three separate codebases. This is Kiro’s own account of its own system, and a clean protocol diagram is not proof that the Cedar-backed permission engine or the WebSocket transport hold up once real teams lean on them at scale.
Today’s issue also carries a piece on eval frameworks arguing that the harness running an agent is itself part of what gets measured, an argument that gets harder to wave off once the harness is a swappable server process instead of code baked into whichever client happens to be running the test.
Kiro users on any of its four surfaces should watch harness release notes, not client changelogs, for the signal on what actually changed under them.
Kiro’s engineering team described the unified agent harness and its Agent Client Protocol architecture in a post on the company’s own blog.
