AWS Opened Kiro Crew. It Kept the Harness.

Is Kiro Crew open source? Yes, genuinely, and more of it than I expected. Is the thing that makes it useful open source? That is a different question, and the answer is where the interesting part of this launch lives.

On 4 August, AWS released Kiro Crew, a persistent agentic workspace that keeps coding agents running across sessions, schedules and messaging surfaces, under the Apache 2.0 licence. It started life inside Amazon as a side project called MeshClaw, spread to more than 39,000 internal builders in under six months, and now lives in a public repo with an open governance model. I have read the announcement, the repo and the licence, and I spent time mapping what is actually in the repository against what the product still needs from AWS to function. The boundary is deliberate, and it is worth understanding before you build on either side of it.

Key Takeaways - Kiro Crew is a persistent agentic workspace from AWS, open-sourced under Apache 2.0 on 4 August 2026. It began as an internal Amazon side project (MeshClaw) used by 39,000+ builders before release. - What is open: the Gateway (sessions, memory, scheduling, approvals, security policy), the dashboard, the CLI, the desktop app, Apps and the App SDK, skills, and the full security stack. You can read, fork and self-host all of it. - What stays closed: the Kiro CLI, the agent engine Crew drives over the Agent Client Protocol, plus Kiro's sign-in, model routing and credit billing. Crew's agent provider is fixed to ACP and kiro-cli, so every model call still flows through AWS's commercial product. - This is a partially open vendor harness, not an open agent runtime. Compare TrueForge, which open-sourced the harness itself under MIT and treats any model as just another endpoint. - The design is still useful. Self-hosted state, visible memory and a serious security model are real. Just be clear-eyed about which layer you are committing to.

What happened

On 4 August 2026, AWS published the Kiro Crew announcement and opened the kirodotdev/KiroCrew repository under Apache 2.0. Coverage landed the same week in SiliconANGLE and DevOps.com, and the repo sat at roughly 3,400 stars and 400 forks when I checked it. The key facts:

• Kiro Crew is a persistent workspace for development agents: multi-step tasks that run unattended, recurring jobs on a schedule, heartbeats that watch a PR or deployment until something needs attention, and subagents that fan out and report back.

• It runs where you put it: a desktop app, a one-line install, a Docker image on GHCR, or a remote Linux host you control. State (sessions, memory, checkpoints) lives on your hardware under ~/.kiro/crew, not in an AWS control plane.

• Work reaches it through a web dashboard, a CLI, a desktop app, or messaging surfaces: Slack, Discord, Telegram, Teams, Webex, WeCom, WeChat and WhatsApp.

• It grew out of MeshClaw, an internal Amazon side project inspired by OpenClaw, which the announcement says reached 39,000+ internal builders with nearly 500 contributors shipping close to 600 updates before the public release.

• Governance is public: a steering committee listed in MAINTAINERS.md, proposals filed and debated as pull requests. For now the maintainers are Kiro and AWS engineers, with the stated intent to add outside maintainers as trusted contributors emerge.

Kiro Crew is an open-source (Apache 2.0) persistent agentic workspace released by AWS on 4 August 2026. It runs unattended multi-step tasks, scheduled jobs, heartbeats and subagents, self-hosted on the user's hardware, per AWS's announcement and the project repository.

Which layers are open, and which are not

This is the part the coverage mostly skipped, so I went through the repo myself. The architecture has three tiers: the surfaces you talk to (dashboard, desktop, CLI, messaging), the Gateway that holds the state (sessions, memory, schedules, approvals, security policy), and the agent sessions that actually run the model loop. Here is where the licence boundary falls:

The load-bearing line is in the configuration docs: agent.provider is fixed to acp, and Kiro Crew drives kiro-cli over the Agent Client Protocol. Every model request is handled by kiro-cli under your Kiro account and its model configuration. The workspace, the memory, the schedules, the security posture: all yours, all forkable, all verifiable. The engine that reasons and the billing that meters it: AWS's.

Kiro Crew's Gateway, surfaces, Apps and security layers are Apache 2.0 open source in the KiroCrew repository, but the agent engine underneath, kiro-cli, remains a closed AWS product. Crew's agent provider is fixed to ACP over kiro-cli, so model access, sign-in and credit billing stay AWS-controlled.

Why the boundary sits exactly there

The lazy reading is that AWS open-sourced Crew as a goodwill gesture, or as a trap. The more useful reading is that the boundary traces the money, and it does so honestly.

Give away the workspace, keep the engine and the meter. That is the same bargain as a lot of sensible open-source infrastructure, and AWS is plain about it: the announcement says Crew runs on the Kiro CLI and reads your existing .kiro configuration out of the box. If you already live in Kiro, Crew is a gift. Your steering files, skills and custom agents carry over, and your agents get persistence, scheduling and a dozen messaging surfaces for free. The 39,000 internal users are evidence this shape works at scale, not a marketing line.

But notice what the openness buys AWS. Every Crew install is a Kiro install, because first launch sets up kiro-cli and device-code sign-in. Every agent turn is metered through Kiro credits on whatever models Kiro routes to, and Kiro's routing runs across Claude and the Chinese open models (Qwen, DeepSeek, GLM, MiniMax) on Bedrock. One early user burned through 5,000 credits in a week of personal projects, which tells you what an always-on agent workspace does to a metered model plan. The open layer grows the funnel for the closed layer, and the closed layer is where the revenue is. None of this is hidden, and none of it is sinister. It is just worth seeing clearly, because the same week brought a fully open alternative that drew the line in a different place.

There is one more thing inside the open layer that deserves credit. The security model is enforced at the runtime boundary rather than in prompts: OS-level sandboxing on Linux and macOS, denied-by-default commands, credential redaction, and a fail-closed posture on Windows where agent subprocesses are refused rather than run unconfined unless you explicitly opt in. Because it is all in the repo, you can verify every layer instead of trusting a vendor page. That is the strongest argument for the open part being real and not theatre.

Kiro Crew's open workspace funnels users into the closed, metered Kiro engine: every install sets up kiro-cli and Kiro sign-in, and every agent turn bills against Kiro credits. The security stack (OS sandbox, deny-by-default commands, credential redaction, audit logs) is genuinely open and auditable in the repository.

The TrueForge contrast

Two weeks after Kiro Crew, TrueFoundry released TrueForge under MIT, and the pair makes a clean natural experiment in how much of an agent stack a vendor is willing to give away.

TrueForge open-sourced the harness itself: the loop around the model, the sessions, the sandboxing, the approvals, the context management. Any OpenAI-compatible endpoint plugs in, so the cheapest model that finishes the task can win the workload, and the commercial layer sits underneath as an optional gateway you can decline. Kiro Crew open-sourced everything around the harness: the persistence, the scheduling, the surfaces, the security policy. The harness itself, kiro-cli, stays closed, and the model plane behind it is the product.

Neither is dishonest, but they are different commitments and they fail differently. Fork TrueForge and you keep a working agent runtime; you lose TrueFoundry's gateway and support. Fork Kiro Crew and you keep an excellent workspace with no engine inside it; the moment kiro-cli changes its protocol, its pricing or its retirement schedule, your fork inherits the problem. If you are weighing build versus buy for your own agent stack, that is the question to ask of any partially open product: which layer stops working when the vendor's roadmap moves? I made the same point about agentic architecture generally: the interesting question is rarely which model, it is what wraps it, and who owns the wrapper.

The Hangzhou footnote I can't help adding: Kiro's routing already treats Qwen, DeepSeek, GLM and MiniMax as first-class citizens on Bedrock, and Crew ships WeCom and WeChat connectors out of the box. Chinese models and Chinese messaging surfaces as ordinary parts of an American vendor's stack. Noted, with some satisfaction, from the city where half those models are made.

What to do now

If you are evaluating Kiro Crew, three steps, in order.

1. Today: read the repo before installing anything. Start with the README's architecture section, GOVERNANCE.md and MAINTAINERS.md, then the security docs. The whole point of the open layer is that you can verify it, so verify it. The install itself is a one-liner, and the dashboard binds to localhost by default.

2. This week: run it on one bounded, low-risk workload: a scheduled PR watch, a morning digest, a recurring review. Watch what it does through the Activity view and the audit log, and watch your credit consumption. Persistent agents spend money while you sleep; that is the product working as designed, and it is also a budget conversation.

3. This month: decide which layer you are committing to. If you are already a Kiro shop, Crew is an easy yes. If you are choosing a stack from scratch, compare the boundary against a fully open harness like TrueForge, and think through the self-hosting trade-offs before your team's workflows harden around either. If you go ahead, Crew's MCP support means your existing tools come along; my shortlist of MCP servers worth wiring in is a reasonable starting set.

FAQ

Is Kiro Crew open source?

The workspace is: the Gateway, dashboard, desktop app, CLI, Apps, skills and the entire security stack are Apache 2.0 in the kirodotdev/KiroCrew repository, and you can self-host all of it on your own hardware with no AWS control plane. The agent engine underneath, kiro-cli, is not open source, and Crew cannot run without it. So "open source" is accurate for the repository and incomplete as a description of the product.

Does Kiro Crew need an AWS account?

It needs a Kiro sign-in, which handles model access and credit billing through kiro-cli. You do not need to deploy anything into an AWS account for local use; the workspace and its state stay on your machine. If you want an always-on remote instance, kirocrew cloud launch can provision one on EC2 in your own AWS account, but a plain Linux server or home lab works too.

How is Kiro Crew different from Kiro's autonomous mode?

Scope. Autonomous mode handles one task in one session while you watch. Crew persists across sessions and restarts, runs scheduled and reactive work whether you are online or not, orchestrates subagents in parallel, and carries memory, lessons and skills forward between runs. It is a new surface on the same Kiro engine, reading the same .kiro configuration.

Can I use Kiro Crew with a different agent engine or model provider?

Not today. The agent provider is fixed to ACP over kiro-cli, so models come from whatever your Kiro account routes to, which currently includes Claude and open models like Qwen, DeepSeek, GLM and MiniMax on Bedrock. The governance model is public and the maintainers say outside contributions are welcome, so a pluggable engine is conceivable, but it is not the shipped design, and I would not plan around it.

The bottom line

Kiro Crew is a good open-source project wrapped around a closed commercial engine, and AWS has been more straightforward about that arrangement than most vendors bother to be. The open layer is real: self-hosted state, visible memory, an auditable security model, public governance. The closed layer is also real: the harness proper, the sign-in, the meter. If you go in knowing exactly which side of that line your commitment sits on, Crew is worth your time. If you need the line somewhere else, the same month gave you an MIT-licensed harness that puts it there.

If you are trying to work out where the open boundary should sit in your own agent stack, that is a conversation I have with clients regularly. Get in touch.

Sources

• Kiro (AWS), "Introducing Kiro Crew": https://kiro.dev/blog/introducing-kiro-crew/ (published 2026-08-04, retrieved 2026-08-29)

• kirodotdev, KiroCrew repository (README, LICENSE, GOVERNANCE.md, security docs): https://github.com/kirodotdev/KiroCrew (retrieved 2026-08-29)

• Kiro, Kiro Crew product page (licence and capability FAQ): https://kiro.dev/crew/ (retrieved 2026-08-29)

• SiliconANGLE, "AWS launches Kiro Crew, an autonomous agentic orchestrator for 24/7 code development": https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/ (published 2026-08-04, retrieved 2026-08-29)

• DevOps.com, "AWS Adds Agentic Workspace to Kiro AI Coding Tool": https://devops.com/aws-adds-agentic-workspace-to-kiro-ai-coding-tool/ (published 2026-08-05, retrieved 2026-08-29)

• Playing AWS, "Kiro Crew after one week (and more than 5000 credits)": https://www.playingaws.com/posts/what-is-kirocrew/ (published 2026-08-08, retrieved 2026-08-29)