Kiro Crew: An Open Source Always-On Workspace That Keeps Agent Work Going Across Sessions

Kiro Crew is an open source development workspace from kirodotdev, released under the Apache 2.0 license. Its pitch is a persistent, self-learning, self-evolving workspace that runs on your own machine or a remote host, so that development work continues after a single session ends. Most agent sessions die when the chat window closes. Kiro Crew takes the opposite approach. A long-running Gateway process sits at the centre and keeps sessions, memory, schedules and task checkpoints, so work goes on between conversations. The public description suggests four layers. The first is the Gateway, a resident service that listens on port 5476 by default. The official Docker example binds it to 127.0.0.1, which shows the default stance is local-only access. The second layer is the set of entry points: a desktop app, a web dashboard and a CLI, plus connection tools such as Slack and Discord. The same piece of work can be picked up from any of them. The third layer is the agent backend. The default agent runs on kiro-cli through an ACP backend, and the project says other verified ACP harnesses exist. The fourth layer is Kiro Crew Apps, which bundle a purpose-built interface with agents, skills, schedules, integrations and backend services for one specific job.

Three mechanisms carry the design. The first is persistence. Sessions, memory, schedules and task checkpoints survive a Gateway restart. The checkpoint matters most: when a multi-step task is interrupted, it can resume from the last saved point instead of starting over. The second is unattended execution. Multi-step tasks can run with nobody watching the terminal, recurring jobs fire on your schedule, and heartbeats monitor systems until something needs attention. The third is self-learning. The project says that corrections and task failures become durable lessons. The README excerpt we reviewed is cut off at this point, so the details of how lessons are stored and reused must come from the official documentation.

The install and distribution choices show some engineering priorities. One command, curl -fsSL https://download.crew.kiro.dev/cli.sh | sh, installs the signed Stable wheel without cloning the repository or building the frontend. The --version flag pins a release, but the lowest pinnable version is 0.1.2. Versions 0.1.0 and 0.1.1 predate manifest signing, so no signed manifest exists to verify them. That is a clear sign that the team treats supply chain integrity as a visible feature. There are three release channels: Stable is the default, Insider follows release candidates, and Nightly follows the main branch. For containers, the Gateway ships as a public multi-architecture image on GHCR, aimed at always-on servers. A source build needs Python 3.12 or newer and Node.js 22.12 or newer. The flow is make build, then kirocrew setup, kirocrew doctor and kirocrew gateway. The doctor command checks the environment before the first start.

On performance, one point needs to be plain: the public material we have contains no benchmark data. There are no latency, throughput or task success figures, so this article does not invent any. What we can do is describe the cost structure. Kiro Crew itself is a scheduling and persistence layer. The real inference cost comes from the agent backend it connects to, which by default means model calls behind kiro-cli. Resident schedules and heartbeats mean steady background calls. Teams should budget for them and set sensible heartbeat intervals. The payoff is human time: you stop re-explaining the same background in every session.

The impact on developers and enterprises falls into three areas. First, the working model shifts from a one-off chat to a long-lived teammate, because memory and checkpoints keep context from vanishing with the session. Second, self-hosting under Apache 2.0 keeps code and data on hardware you control, which matters to teams with compliance duties. Third, the ACP-compatible, multi-harness design reduces lock-in to a single agent. The Slack and Discord connections let it enter communication flows that teams already use. The Trendshift badge on the repository also suggests that developers noticed the project early. The limits are just as clear. First, the default backend needs kiro-cli, which you install and sign in to separately. The first launch checks for it and links to the official setup guide if it is missing. Second, unattended operation magnifies permission risk. An agent that can act on its own for long periods needs sandboxing, least privilege and audit trails. The project ships a security policy and sandbox setup guidance, and operators should read them closely. Third, self-learning cuts both ways. A wrong lesson that becomes durable can bend later tasks, so someone must be able to review and prune what the system has learned. Fourth, the project is young. The docs use 0.6.0 as the example pinned version, so interfaces and behaviour may still change. Finally, the README has an anonymous usage telemetry section. Enterprise users should confirm its scope and how to switch it off before deployment.

In short, the interest in Kiro Crew does not come from one headline metric. It comes from treating a long-running agent as a first-class design goal: durable state, resumable tasks, schedules and heartbeats, multiple entry points, and signed distribution. Whether it keeps that promise depends on the quality of its self-learning and the safety boundaries around unattended work. Both deserve close attention in later releases.