Every agent I run has the same ceiling. It works while I watch it. The moment I close the session, the context sits in memory and nothing moves until I come back and reconnect it. I have tried scheduled scripts and webhook triggers to get around this, but the work still waits on me somewhere in the chain. That is the problem AWS went after on August 4 with Kiro Crew, an open source orchestrator that keeps coding agents running across sessions, schedules, and tools while you are not there.
The announcement on kiro.dev and the code on GitHub accompanied the release on August 4. Kiro Crew is Apache 2.0 licensed, written in Python, and described in the repo as "a persistent workspace for development work that self-improves and continues beyond one session." It is not another coding agent. It is the layer above the agents: it starts work, coordinates it, keeps the context, and finishes it while you handle something else.
Where it came from
Kiro Crew began as MeshClaw, a side project by three Amazon developers who wanted a simple way to kick off a task, walk away, and come back to something worth reviewing instead of babysitting one prompt at a time. They built it on top of Kiro, AWS's coding agent and CLI, because it was the tool the team already used every day. The blog credits the momentum of OpenClaw and self-learning agent tools as inspiration, but says the team needed something that met Amazon's security requirements for internal development work.
The project spread through Amazon quickly. In less than six months, more than 39,000 Amazon builders adopted it, with nearly 500 contributors shipping 597 updates at an average pace of 143 weekly commits, according to the announcement. The people using it were extending it for their own workflows, and those additions stayed for everyone else. The team says that compounding of small contributions is why they released it publicly: a tool grows when people can bend it to their own work.
What the crew actually does
The feature descriptions below come from the launch announcement and the README, not from my own testing.
Engineering work was never one task in one session. It spans repos, tools, reviews, and days, and until now the developer was the integration layer holding it together. Kiro Crew replaces that manual stitching with four pieces of machinery.
Memory that survives sessions. Agents keep preferences, project context, and relevant history across sessions. Corrections you make become durable lessons, and repeated patterns become skills you can inspect, edit, or remove. The memory stays visible, so you decide what the crew carries forward instead of hoping it guesses right.
Unattended execution. Recurring jobs run on schedules you define. A morning digest can collect what needs attention, a heartbeat can watch a PR or deployment until its state changes, and an authenticated webhook can start work when an external event arrives. Jobs that do not need reasoning run as plain scripts or commands without a model call.
Multi-agent coordination. For work that benefits from more than one agent, Kiro Crew runs several conversations concurrently with isolated context, and it can delegate research or implementation to subagents that report back to the parent conversation.
Purpose-built Apps. Some work does not belong in a chat window. Apps combine a custom interface with agents, skills, schedules, and backend services. Launch apps include DevFleets for worktree management, Task Runner for long-running tasks, and Issue Radar for triaging issues and pull requests. There is also a LaunchDarkly app that brings feature flag management into the workspace over LaunchDarkly's MCP server, so an agent can find flag references in code, implement a change behind a flag, and hand you the controls for rollout.
Everything runs behind Agent Client Protocol (ACP), and every step is observable. The Activity view shows each agent's reasoning, tool calls, and results as they happen, with approval gates where you want them.
How it runs
Pick a run mode. Kiro Crew is built on the Kiro CLI and reads your existing .kiro configuration out of the box, so steering files, skills, and custom agents carry over with no extra setup if you already use Kiro. The README lists four ways to run it: the desktop app with automatic updates, a one-line install on a machine or remote host, a Docker image for always-on servers, and a build from source. macOS and Linux get desktop builds; Windows runs through a source install with the browser dashboard.
Pick a surface. There is a desktop app, a web dashboard, a TUI, and chat interfaces like Slack, Telegram, and Discord, so you can start a task in the dashboard and adjust it later from a phone. The dashboard binds locally by default.
Control stays local. It runs entirely inside your environment, on laptops, containers, or VMs, with no AWS account and no AWS-managed control plane, per InfoWorld. And the software itself is free: Darko Mesaros, AWS's distinguished developer advocate, told InfoWorld that you pay only for the AI coding agents and tools you choose to connect to Crew.
Security and governance
An orchestrator with this much access needs to be boring about security, and the announcement lists the boring parts: an OS-level sandbox, denied-by-default commands, suspicious-pattern blocking, input validation, sensitive-path blocking, credential redaction, and a signed audit log of every action. Tool requests can require approval. Because the whole thing is open, you can verify those layers against the source.
The governance model is open in the same spirit. The project runs under a steering committee listed publicly in MAINTAINERS.md, proposals are filed as pull requests and debated in the repository, and decisions are documented there. AWS and Kiro engineers maintain the project initially, with trusted community contributors expected to join over time.
Why this matters
The analysts who commented on the launch mostly agree on the upside.
The governance case. Michael Leone of Moor Strategy and Insights points out that agent use inside most companies is shadow IT right now, with individual developers wiring up their own agents against their own credentials. A shared workspace gives one place to see what ran, what it touched, and who authorized it. Ashish Chaturvedi of HFS Research adds the security angle: open source and self-hostable means a CIO can run it on their own infrastructure and keep code and credentials inside the perimeter instead of sending them to a black-box agent. Dave McCarthy of IDC frames the developer benefit as cutting context-switching and prompt babysitting, so teams return to completed progress rather than a stalled process.
The trade-offs. Stephanie Walter of HyperFRAME Research notes this is another orchestration layer to manage and secure, and most enterprises are not operationally ready for swarms of autonomous agents: parallel agents multiply model calls, compute, CI activity, API usage, tool access, and human review on top of token consumption. The bigger caveat comes from Leone: Kiro Crew runs on the Kiro CLI at launch, and that CLI is proprietary and metered by credits. Until someone runs a different agent under Crew and shows it working, the open part stops at the orchestration layer.
What I would check before adopting it
I have not run Kiro Crew yet. This section is based on the announcement, the repository, and the analyst coverage, not on hands-on use. If I were evaluating it for my own setup, these are the things I would check first:
The Kiro CLI dependency. Every run path goes through kiro-cli underneath, with a device-code sign-in. Confirm what the metering means for your usage before building workflows on it.
Agent support beyond Kiro. The launch story is built around Kiro agents. If your team standardizes on another agent, wait for proof it runs under Crew, or plan for connector work.
What the memory actually persists. The pitch is that lessons and skills carry across sessions. That only helps if you can see and prune them, so check whether the review loop fits your team.
Cost behavior of parallel agents. Subagents multiply model calls and tool usage. The framework being free does not mean the runs are free.
Approval gates. Confirm which actions can require human approval and whether the signed audit log satisfies your compliance requirements.
That list is a starting point, not a verdict. The project is young, the community is new, and the GitHub repo had 301 stars, 16 forks, and 214 open issues when I last checked, with stars climbing through the day. The real evaluation happens over the next few months as people actually run it.
The bigger picture
For me, the most interesting part is not the feature list. It is that the largest cloud provider just open-sourced its internal agent orchestration layer, including its governance, and made it self-hostable. That is the opposite direction from managed agent platforms that keep the harness, the memory, and the audit trail on their side of the API. Whether Kiro Crew becomes a default orchestrator or a footnote depends on one question: do teams want their agents to work while they sleep, and are they ready to own the infrastructure that makes that possible?
I write about Java, Spring Boot, and AI every week. Subscribe, it is free.
Have you tried Kiro Crew yet, or another orchestrator like it? What did you hit first, the setup or the trust problem?