Kiro Crew Runs on Your Hardware. It Still Runs on kiro-cli.

AWS open-sourced its internal multi-agent orchestrator on August 4 under Apache 2.0. Reading the config schema tells you more about what self-hosting buys you than the launch post does.

Deep in the Kiro Crew README, past the install instructions and the capability table, there is a one-line note about the config file that does more explaining than the entire announcement blog:

agent.provider is fixed to acp. Kiro Crew drives kiro-cli over the Agent Client Protocol.

The banner at the top of the same README says "Runs on your hardware." Both statements are true, and holding them together is the whole exercise. AWS open-sourced Kiro Crew on August 4, Apache 2.0, no separate fee, governance in the open with a steering committee listed in MAINTAINERS.md. You can run the entire thing on a Linux box in your closet. Your conversation history, your memory, and your knowledge indexes never leave that box.

The model calls still go through your Kiro account.

Why this distinction is the whole story

Every agent orchestrator shipping right now claims some version of "open" and "yours." The word does different work depending on which layer you are talking about, and most launch coverage does not separate them.

Kiro Crew separates four things that usually get bundled: the orchestrator, the state, the agent runtime, and the inference. It genuinely hands you the first two. The GitHub repo had 340 stars, 22 forks and 1,427 commits when I scanned it the morning after launch, which is a real codebase and not a README with a coming-soon note. The third and fourth are Kiro's, at least at launch.

That is a defensible design. It is also not what "you can build support for other ACP-compatible agents" implies when you read it in a press summary, because that is future community work, not a config toggle you flip today. Knowing which layer you are actually taking ownership of is the difference between a sound architecture decision and a surprise in six months.

The mechanism: one Gateway, many surfaces, one CLI underneath

The architecture is three tiers and it is easy to hold in your head.

Surfaces sit at the top: desktop app, web dashboard, CLI, Slack, Telegram, WeCom, Discord. In the middle is the Gateway, the long-running process that owns access control, sessions, memory, schedules, approvals and Apps. Below that are agent sessions, each one an ACP runtime driving kiro-cli with MCP tools attached.

The Gateway is the piece that matters. It separates where the agent runs from where you work with it, so a Slack thread and a dashboard conversation map to the same managed session under the same memory, tool, approval and policy services. A session is a logical isolation boundary, not necessarily one OS process, since Kiro Crew supports both a dedicated kiro-cli ACP process per session and a shared runtime multiplexing several session handles.

State persistence is where the self-hosting claim earns its keep. Sessions, memory, schedules and task checkpoints survive Gateway restarts. Corrections become durable lessons scoped to a workspace, so telling it "always run the frontend checks before calling a change done" changes behavior in later sessions rather than evaporating when the chat closes. Repeated patterns get synthesized into skills you can inspect, edit, or delete. Semantic memory needs no setup at all: embeddings run in-process, and the Gateway downloads its embedding model in the background on first start, falling back to keyword search until it lands. KIROCREW_EMBED_MODEL_URL points it at a mirror for airgapped installs, which is a small detail that tells you who they were building for.

The security posture is more specific than most launch posts bother to be. 137 bundled deny patterns block destructive commands and common exfiltration paths even when a session has broad approval. On Linux and macOS, kiro-cli can run inside namespace or Seatbelt isolation with standard, strict and off modes making the tradeoff explicit. Sensitive paths are blocked, sensitive environment variables are stripped, credential patterns are redacted from output before it reaches a chat surface. The dashboard binds to loopback unless you deliberately configure a network URL, and remote dashboards require token auth.

The piece I would actually use is the governance ceiling. Policy and profile files compose with a tightest-wins model, so a running app or agent can narrow the allowed scope but cannot loosen an enterprise ceiling. kirocrew policy show, validate and explain let you inspect what is in force. For anyone who has tried to reason about what an agent is permitted to do across five overlapping config files, a documented precedence rule and an explain subcommand are worth more than another capability.

Telemetry is opt-out and unusually specific about it: one anonymous heartbeat per day carrying exactly five fields, a random instance UUID, the release number with build stamps stripped, the Python minor version, the install channel, and a first-run flag. kirocrew telemetry status prints exactly what would be sent. kirocrew telemetry disable or KIROCREW_TELEMETRY_DISABLED=1 turns it off. Publishing the field list is a small act of respect and I wish more projects did it.

Put this into practice

The lowest-friction path is Docker, and it takes about ten minutes if kiro-cli sign-in goes smoothly.

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

Note the 127.0.0.1: prefix on the port binding. That is not decoration. It keeps the dashboard off every interface on the host, and it is the single thing most likely to get skipped by someone copying a docker command in a hurry. Mount the directory selected by KIROCREW_HOME so sessions, config, memory and credentials survive container replacement.

Then open http://localhost:5476. First launch installs kiro-cli on the Gateway host if it is missing and walks you through device-code sign-in before chat opens. Budget for that step, because it is the moment the "self-hosted" mental model meets an account requirement.

Four things to do before you give it anything real:

1. Run kirocrew doctor. It catches the common breakage, which is kiro-cli not on PATH or not logged in. If you hit an ACP timeout, that is almost always the cause, and the first MCP startup needs extra time.
2. Set agent.sandbox to strict rather than auto while you are evaluating. The modes exist to make the tradeoff explicit, so make the explicit choice.
3. Run kirocrew policy show and read it before you connect a repo you care about. Then narrow it.
4. Give it a credential set of its own. This is the same advice that applies to every coding agent, and it applies harder to one designed to run scheduled jobs at three in the morning.

Start with work that already spans sessions. A recurring PR review, a checkpointed migration, a morning digest of what needs your attention. Those are the jobs the persistence layer was built for, and they are the ones where you will find out fast whether the memory and lessons machinery is doing anything useful for your workflow or just accumulating.

If you already use Kiro, your .kiro configuration comes along. Steering files, skills and custom agents carry over with no extra setup.

Honest limitations

The kiro-cli dependency is not a footnote. Every install path runs it underneath. agent.provider is fixed. Model requests are handled by kiro-cli and follow the account and model configuration you use there. If your reason for wanting a self-hosted orchestrator is avoiding a vendor account, this does not do that today. What it does is keep your history, memory and knowledge indexes on hardware you control while inference goes out through Kiro. That is a real and useful property. It is a different property from the one "fully open source" tends to suggest.

Windows is a second-class target. No desktop build yet, so you run the Gateway from a source install and open the dashboard in a browser. More importantly, the OS-level sandbox layer does not exist there. Namespace and Seatbelt isolation are Linux and macOS only. A Windows install is running with one fewer containment layer than the docs otherwise promise, and the README says so plainly, which I appreciate and you should still weigh.

The one-line installer is curl | sh. The wheel's SHA-256 is verified against a published manifest, and you can pin an exact wheel with an inline hash so pip verifies it and never consults a package index. That is better than most. It is still a pipe from a CDN to a shell on first run, and if your org has a policy about that, use the pinned-wheel path.

The adoption numbers are Amazon's own. More than 39,000 internal builders in under six months, nearly 500 contributors, 597 updates, 143 weekly commits on average. All self-reported in the launch post and unverifiable from outside. They are plausible for an internal tool at Amazon's scale, and they are marketing until someone outside can check them. Public traction as of the morning after launch was 340 stars, which tells you approximately nothing yet either way.

The Apps story is early. DevFleets, Task Runner and Issue Radar at launch, plus an App SDK. The catalog will grow or it will not, and building your workflow around a three-app store on day two is a bet.

And the timing is uncomfortable. This shipped the same week the UK's AI Security Institute published an incident report concluding that the margin between failure and success in their cyber-range evaluation rested on human vigilance rather than a technical barrier. Kiro Crew's core value proposition is work that happens when no human is watching. The security layer here is better than most, and I would still scope its credentials as though the deny list will eventually miss something, because that is what deny lists do.

The question worth arguing about

The genuinely interesting bet inside Kiro Crew is not autonomy. It is that a persistent, inspectable state layer, memory plus lessons plus synthesized skills, all editable by you, is what actually makes long-running agent work usable. Everything else in the project is plumbing around that claim.

If that is right, the orchestrator matters more than the agent, and being locked to kiro-cli is a fair trade for state you own. If it is wrong, if lessons and skills accumulate into noise the way most agent-memory systems have so far, then you have self-hosted a very well-engineered scheduler.

I do not know which yet, and neither does anyone else two days in. What I would go look at is whether the memory stays useful past week three. If you stand one up and the lessons file turns into a junk drawer, that is the finding, and I would rather hear it from someone running it than read another architecture diagram.

Sources: Kiro blog, "Introducing Kiro Crew" (Aug 4, 2026); kirodotdev/KiroCrew on GitHub; Agent Client Protocol; AI Security Institute incident report.