It's Friday afternoon. You're wrapping up. A teammate pings about a latency spike and needs your help investigating. You know the drill: pull up CloudWatch, cross-reference three repos, check the last time this happened, run diagnostic queries. None of it is hard. All of it requires you to be the glue between six different tools.
What if you could message your AI agents, say "find what we did last time, write it up, send it to the team," and head out?
That's Kiro Crew. And it launched on August 4, 2026.
Table of Contents
- What Kiro Crew actually is
- The problem it solves (and why I care)
- Core capabilities
- How it fits in the Kiro ecosystem
- Where I would have used this last month
- Real use cases worth trying first
- Getting started
- Pricing reality check
- What to watch out for
- The bigger picture
What Kiro Crew actually is
Kiro Crew is an open-source (Apache 2.0), persistent development workspace. An orchestration layer that coordinates multiple AI agents, preserves context across sessions, schedules recurring work, and keeps running while you're offline.
The origin story matters. Three engineers inside Amazon built a side project called MeshClaw. They wanted something simple: kick off a task, walk away, come back to something reviewable. Run several tasks at once instead of babysitting one prompt at a time.
Then other Amazon builders picked it up. Not because someone mandated it. Because engineers kept hitting gaps in their workflows, fixing them, and pushing the fix upstream. In less than six months, 39,000+ Amazon builders adopted it. Nearly 500 contributors shipped 597 updates at an average pace of 143 weekly commits.
That organic adoption is the strongest signal. The fact that thousands of engineers chose to use it and hundreds chose to improve it tells you more than any feature list.
The problem it solves (and why I care)
After 10+ years of building cloud infrastructure across client engagements, I've accepted a frustrating truth: I spend more time being the "glue" between tools than doing actual engineering work.
The Kiro Crew blog post nails this. Developers are the integration layer between their own tools.
I feel this every single day. I have Kiro CLI open, CloudWatch in one tab, GitHub in another, a Slack thread I need to follow up on, three PRs waiting for review, and a deployment that broke overnight. The moment I step away, everything stalls. Nobody reconnects the context. Nobody pushes the migration forward. Nobody notices the flaky test reappeared.
I've been using Kiro CLI for months now. It's good inside a single session. You prompt, it responds, it does solid work. But close the tab? Next time you open it, the context is gone. You spend the first ten minutes re-explaining what you're working on. Your steering files carry over, but the working memory of "where were we?" doesn't.
Kiro Crew breaks that pattern by making the workspace persistent. Memory carries forward. Corrections become lasting lessons. Repeated patterns become reusable skills. And work continues on a schedule even when you're not at your keyboard.
As an AWS Community Builder who's been writing about Kiro since its IDE launch, I've watched this product evolve from a spec-driven coding tool into something approaching a genuine engineering platform. Crew is the piece that makes the others click together.
Core capabilities
Self-learning memory
This isn't just "remembers your last conversation." Crew maintains:
- Memory: preferences, active projects, relevant history across sessions
-
Lessons: corrections you make become persistent rules. Tell it once to stop using
var, and it never does again. Workspace-scoped, so project A's rules don't bleed into project B. - Skills: repeated patterns get synthesized into named, inspectable Markdown files.
- Knowledge graph: architectural decisions, coding preferences, project context stored with vector embeddings and full-text search.
Everything's visible. Edit it, delete it, scope it. No magic black box learning you can't audit.
If you've been using Kiro CLI with .kiro steering files and custom skills, you already know the value of persistent instructions. Crew takes that same principle and applies it to the agent's own working memory between sessions.
Scheduled and unattended work
This is where Crew separates from every other AI coding tool I've used:
- Cron jobs: timezone-aware, per-job timeouts, jitter to avoid thundering herds, skip dates for maintenance windows.
- Webhooks: authenticated endpoints trigger agent work when external events arrive.
- Heartbeats: watches state changes in PRs, deployments, pipelines. Triggers work when conditions are met.
- Checkpoints and retries: long-running tasks save progress and resume after failures.
The key detail: jobs that don't require model reasoning run as plain scripts. No inference call, no credit consumption. A health check script costs nothing. Only reasoning costs credits.
Multi-agent orchestration
Crew can run several conversations concurrently, each with isolated context. It delegates independent research and implementation to sub-agents, then returns results to a parent conversation that stays focused on the goal.
You give it a migration task. It spawns one agent to analyze the source code, another to write the target code, another to handle tests. The parent coordinates. I've been waiting for this pattern since I started using Kiro's sub-agent feature in the CLI, which works but forces you to stay in the loop for every handoff.
Apps (purpose-built interfaces)
Some work doesn't belong in a chat window. Apps wrap agents, skills, schedules, and integrations into custom UIs:
- DevFleets: work tree management
- Task Runner: long-running task execution
- Issue Radar: PR and issue triage with readiness labels
- Code Review Sage: reviews by blast radius, stages draft GitHub reviews
- Research Lab: fans out sub-questions to parallel agents, streams findings
Build your own with the App SDK (TypeScript or Python). Combine React UI with the agent runtime and event bus.
7 layers of security
Giving an agent real access to your code and CI demands real security. This matters especially if you're working with enterprise clients where compliance isn't optional. Crew ships with:
- OS-level process sandbox
- Tool approval gates (you decide what runs)
- Sensitive path blocking
- Write-protected paths
- Denied command patterns and suspicious bash blocking
- MCP input validation and output redaction
- Credential redaction and signed audit logs (SEL)
Because it's open source, you can verify every layer. Read the code, trace the execution path, confirm the sandbox actually sandboxes. For my consulting clients, the "show me the source" conversation just got a lot easier.
How it fits in the Kiro ecosystem
Kiro now has four surfaces: IDE, CLI, Web, and Crew. Here's how they relate:
| Kiro IDE | Kiro CLI | Kiro Web | Kiro Crew | |
|---|---|---|---|---|
| Sessions | Interactive | Interactive | Interactive | Persistent, autonomous |
| Scheduling | No | No | No | Cron, webhooks, heartbeats |
| Multi-agent | No | Sub-agents | No | Full parallel orchestration |
| Memory | Session only | Session only | Session only | Cross-session persistent |
| Works unattended | No | No | No | Yes |
| Open source | No | No | No | Yes (Apache 2.0) |
Crew runs on the Kiro CLI and reads your existing .kiro configuration. Steering files, skills, custom agents all carry over. No migration. No reconfiguration. If you already use Kiro, Crew is additive.
It also uses Agent Client Protocol (ACP) for orchestration, meaning every step is observable live. You watch how it plans, spawns sub-agents, selects tools, gates actions for approval, and synthesizes results.
Where I would have used this last month
Let me give you three real scenarios from my past few weeks where Crew would have saved me hours.
The CDK migration that stalled every evening. I was migrating a client's CloudFormation stacks to CDK. Each stack took 20-40 minutes of agent time in Kiro CLI: analyzing the template, generating CDK constructs, running cdk synth to validate. I could do maybe 3-4 stacks per session before context started degrading and I needed to re-explain the project conventions. With Crew's checkpoints and persistent memory? I could have queued all 12 stacks, let it chew through them overnight, and come back to a PR with all the synthesized outputs validated.
The Monday morning "what happened over the weekend" scramble. Every Monday I open Slack to 40+ messages, check three repos for new PRs, look at whether the weekend deploy held, and scan CloudWatch for anomalies. This takes me 45 minutes before I write a single line of code. A Crew morning digest cron job does this in 5 minutes and hands me a summary before my first coffee. Zero credits for the Slack scan and CloudWatch check (plain scripts), minimal credits for summarizing findings.
The recurring dependency update nobody does. I have a personal project with 15 npm dependencies I should update monthly. I never do. A weekly Crew heartbeat could check for security advisories, test the updates, and open a PR only when tests pass. Cost: nearly zero because most runs would be "nothing to update" (plain script check) with the occasional reasoning call when something actually needs upgrading.
These aren't hypothetical AI demos. These are the exact gaps in my current Kiro CLI workflow that made me sit up when Crew launched.
Real use cases worth trying first
Don't start with something complex. Start with work that already extends beyond one session.
Morning PR digest
Schedule a daily cron job that checks open PRs, summarizes status, and flags what needs your attention. You get a briefing before your first coffee. The plain "list open PRs" part is a script (zero credits). The "summarize what changed and whether it's ready for review" part takes one reasoning call (2-3 credits). Compare that to the 45 minutes you currently spend manually scanning GitHub every morning.
Flaky test hunter
Set a heartbeat on your CI pipeline. When a test fails twice in a row, Crew investigates the logs, identifies the pattern, and opens a fix PR. This one is personal. I have a test suite where test_concurrent_writes fails every third run due to a timing issue I've been "meaning to fix" for two months. A heartbeat that catches and fixes it without me ever opening the file? That's worth the credits.
Incident investigation across repos
Point it at an alert. It pulls logs from multiple repos, correlates timestamps, identifies the likely root cause. You stay focused on the fix while Crew handles the forensics. For anyone who's ever spent an hour jumping between CloudWatch, ECS task logs, and application traces during an incident, having a dedicated investigation agent running in parallel changes the speed of resolution.
Dependency drift detection
Weekly cron that checks for outdated packages, stale branches, docs that no longer match the code, and failing test suites nobody noticed. Most weeks it finds nothing (zero credits, plain script). When it does find something, it opens an issue with the exact versions, breaking changes, and a suggested upgrade path.
Long-running migration with checkpoints
Start a multi-hour migration. It proceeds through checkpoints, validates each step, retries failures, and you come back to progress rather than a stalled process. The CDK migration scenario I described earlier is a perfect example. Each stack is a checkpoint. If stack 7 fails validation, Crew retries with a different approach. You don't restart from stack 1.
Getting started
Prerequisites
- Kiro account (free tier works for testing, Pro+ recommended for real use)
- Kiro CLI installed and authenticated
- macOS, Linux, or Windows
- Familiarity with
.kiroconfiguration (steering files, skills)
Installation
# Clone the repo
git clone https://github.com/kirodotdev/KiroCrew
# Or download from releases (macOS, Linux, Windows)
# https://github.com/kirodotdev/KiroCrew/releases
# Core commands
kirocrew chat # Start a session
kirocrew run # Execute a task
kirocrew cron # Manage scheduled jobs
kirocrew spawn # Spawn parallel agents
Your existing .kiro config carries over automatically. Steering files, skills, custom agents, all of it. If you've invested time in your Kiro setup, that investment transfers directly.
The desktop app (Electron) needs no Python or npm installation. Download and run. The web dashboard gives you multi-session chat, memory explorer, cron manager, and an app store across 14 color themes. You can also connect Slack, Telegram, Discord, or WeCom to interact with your crew from any surface.
Pricing reality check
Kiro Crew itself costs nothing. It's Apache 2.0. But agents need inference, and inference needs a Kiro plan.
| Plan | Monthly Cost | Credits Included |
|---|---|---|
| Free | $0 | 50 credits |
| Pro | $20 | 1,000 credits |
| Pro+ | $40 | 2,000 credits |
| Pro Max | $100 | 5,000 credits |
| Power | $200 | 10,000 credits |
Add-on credits: $0.04 each. Scheduled jobs that run plain scripts (health checks, simple git operations) consume zero credits. Only reasoning calls cost you.
How does this compare to alternatives? Devin's Teams plan starts at $500/month (with the Core plan at $20/month for lighter usage). OpenAI Codex requires API spend that scales unpredictably. Crew's advantage: you know exactly what you're spending, and most scheduled maintenance jobs cost nothing.
The real cost question is: how many credits does a typical cron job burn? Based on my Kiro CLI usage patterns, a simple "check PRs and summarize" task runs about 2-3 credits. A complex "investigate failing tests and propose a fix" might run 8-12 credits. On the Pro plan ($20/month, 1,000 credits), you could run a morning digest every workday and still have 900+ credits for interactive work.
What to watch out for
I want to be honest about the limitations. Because every "introducing" article pretends there aren't any.
The Kiro plan dependency is real. Crew is open source, but the CLI it runs on requires a Kiro account and credits. Until someone builds and validates a connector for a different agent runtime, you're locked to Kiro's inference. Michael Leone from Moor Strategy put it directly: "Until someone runs a different agent under Crew and shows it working, the open part stops at the orchestration layer."
If you're already using Claude Code, Codex, or Devin, you can't plug them into Crew today. The ACP protocol is open, but integrations need to be built and tested. This is day one. The connectors will come, but they don't exist yet.
Parallel agents multiply costs. Three sub-agents working simultaneously burn three times the credits. I've learned this the hard way with Kiro CLI's sub-agent feature: what feels like one task can spawn four reasoning calls. Architect your workflows to use sequential execution where order matters, and parallel only for genuinely independent work.
Stephanie Walter from HyperFRAME Research raises a point I agree with from my enterprise consulting experience: before you let persistent agents operate across your repos and CI/CD pipelines, you need policies for least-privilege access, human approvals, memory retention, and auditability. The security layers exist in Crew, but your organization needs to decide how to configure them.
And the most important caveat: Crew won't architect your system. It won't make design decisions. It won't tell you whether to pick ECS over Lambda for your specific workload. It coordinates and executes. You still need to be the engineer who decides what to build and why.
The bigger picture
The trajectory is clear: AI assistants, then AI agents, now AI teams. We've been living in the "agents" phase for the past year. Kiro Crew pushes toward teams.
Not teams that replace developers. Teams that handle the integration work, the monitoring, the routine maintenance, the context reconnection between sessions. So you can spend your time on system design, architecture decisions, and the complex problems that actually need a human brain.
I think about this from an enterprise architecture perspective. Every organization I've worked with in the past three years has developers using AI coding tools in some form. But it's almost entirely shadow IT. Individual engineers wiring up their own agents, using personal credentials, nobody tracking what ran or what it touched. Michael Leone from Moor Strategy sees the same thing: "Agent use inside most companies right now is shadow IT. A shared workspace with approval gates and logging gives you one place to see what ran, what it touched, and who authorized it."
That's the real value proposition for platform engineering teams considering Crew. It's not "make developers faster." It's "make AI agent usage visible, auditable, and governable." The security layers, the signed audit logs, the approval gates, those aren't just developer niceties. They're the answer to "how do we let engineers use AI agents without losing control?"
The open-source angle matters here. A workspace with access to your code, CI, and credentials should not be a black box. You should read the source, trace the execution, verify the security layers. Kiro Crew ships that transparency on day one. For anyone who's been burned by opaque AI tools that silently send your code to third-party servers, this matters.
Whether you adopt it today or wait for the ecosystem to mature, this pattern is the direction. Persistent, self-learning, multi-agent workspaces that work alongside you across sessions. The question isn't whether this becomes standard. It's who builds theirs first.
kirodotdev
/
KiroCrew
A persistent workspace for development work that self-improves and continues beyond one session.
Kiro Crew
A persistent workspace for development work that self-improves and continues beyond one session.
Kiro Crew is an open source development workspace that runs locally or remotely on your hardware. It is persistent, self-learning, and self-evolving. Work with it from the desktop app, web dashboard, and CLI, or continue the same work through connection tools like Slack and Discord Your multi-step tasks can run unattended, recurring jobs run on your schedule and heartbeats monitor systems until something needs attention. Kiro Crew Apps tailor that experience to a specific job, combining a purpose-built interface with agents, skills, schedules, integrations, and backend services.
Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs
Quick start
You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…
Links:
- Product page: kiro.dev/crew
- Docs: kiro.dev/docs/crew
- Discord: discord.gg/kirodotdev
What are you going to try first with Kiro Crew? I'm starting with the morning PR digest and the CDK migration runner. Curious what workflows eat your time that agents could handle unattended. Drop your ideas below.
Follow me for more on AWS architecture, DevOps, and AI tooling:
sarvarnadaf.com | LinkedIn | Dev.to | YouTube | Email
Top comments (2)
I've been using Kiro CLI daily for months, so Crew feels like the natural next step. The selflearning memory is what excites me most. Every AI tool ive used forgets context between sessions. You spend 10 minutes re-explaining your project every time you open a new chat.
What workflows would you automate if your agents could run unattended? I'm thinking morning PR digest, flaky test hunting, and dependency drift alerts. Would love to hear what's eating your time that Crew could handle.
The orchestrator layer is where agent projects start becoming real systems. I would look hardest at handoffs, state, retries, permissions, and observability. Those are usually the difference between a demo and something teams can operate.