Kiro Crew Confused Me: So I Rebuilt It With Claude Code

The hook: I read the announcement and got lost

On August 4th, 2026, AWS released Kiro Crew, an open-source "multi-agent orchestrator" — a single long-running process that keeps an AI coding agent alive across many turns, hands it memory, a scheduler, security guardrails, and lets you talk to it from a CLI, Slack, Telegram, or a web dashboard.

I read the README. I read the source. And I still couldn't quite picture, in my head, how all the pieces actually fit together at runtime.

So I did the thing I always do when reading isn't enough: I decided to build my own version of it, using the tool I actually reach for every day — the Claude Code CLI — as the execution engine instead of kiro-cli. Not to compete with Kiro Crew, not to replace it. Just to force myself to understand every piece by having to make it work.

This post is about what I built — claude-crew — what Kiro Crew's actual feature set looks like once you dig in, where my version deliberately falls short of the original, and a few decisions (local-only, Tailscale instead of the cloud, an OS-level sandbox, and — yes — a UI styled after Windows 1.0) that I'd make again.

The source is on GitHub, referencing Kiro Crew's own repository as the design reference throughout.

What Kiro Crew actually is, feature by feature

Stripped of marketing language, Kiro Crew is a persistent, multi-surface agent orchestrator. That's a mouthful, so here's what each word buys you:

• Persistent — the agent process doesn't die when your terminal closes. It keeps running, keeps its memory, and you can pick the conversation back up later, from a different device even.
• Multi-surface — the same running agent is reachable from more than one place at once: a CLI, Slack, Telegram, and a web/desktop dashboard all talk to the same underlying session.
• Orchestrator — it doesn't just answer one prompt and stop. It can schedule recurring work (cron-style), spawn sub-agents for parallel tasks, and keep a durable memory of what it learned across sessions.

Concretely, according to AWS's own announcement and repo, Kiro Crew ships with:

• A Gateway process that multiplexes every surface (CLI/Slack/Telegram/dashboard) onto one shared agent runtime, driven via kiro-cli over the Agent Client Protocol (ACP).
• Persistent memory across sessions.
• Scheduling for recurring, unattended work.
• Approval workflows — a human has to say yes before certain actions go through.
• Sandboxing and a signed audit log, so the agent's actions are contained and provable after the fact.
• Web and desktop dashboards for watching what the agent is doing.
• Developer-tool integrations — investigating incidents, monitoring pull requests, triaging tickets.

That's a genuinely large surface area. Reading it is one thing; understanding why each piece exists, and what breaks if you leave one out, is a different kind of understanding — the kind you only get by trying to build it.

What I actually built: claude-crew

I kept the shape of the architecture — one persistent process, multiple surfaces, a security layer that isn't optional — and swapped the execution engine.

Kiro Crew	claude-crew
kiro-cli over ACP	claude CLI in headless mode (-p --input-format stream-json)
Gateway multiplexing Slack/Telegram/CLI/dashboard	Gateway multiplexing CLI/dashboard (no chat integrations, see below)
Persistent memory	Preferences / project history / "lessons" file, injected into new sessions
Scheduling	cron / taskrunner / subagent / heartbeat
Approval workflows	A PreToolUse gate that blocks on a human allow/deny
Sandbox + signed audit log	macOS Seatbelt / Linux bubblewrap + an HMAC hash-chained audit log

The part that took the most work: security

This is the piece I underestimated going in. A long-running agent that can execute shell commands on your machine, unattended, is not something you want to trust on a "the rules said no" basis alone. So claude-crew has three layers, each one assuming the layer above it can fail:

1. A PreToolUse gate. Before any tool call (read a file, run a shell command, fetch a URL) actually executes, a hook script evaluates it against a rule set — is this tool allowed, does this file path fall inside a protected directory, does this shell command match a denylist pattern. This is a policy layer, and policy layers can be talked around by an obfuscated command.
2. An OS-level sandbox. Because rules on a string are defeatable, the actual claude process runs inside sandbox-exec (macOS Seatbelt) or bubblewrap (Linux). Even if a rule gets bypassed, the kernel itself refuses the write. I verified this by hand: echo x > ~/some-file under the sandbox returns "Operation not permitted," full stop.
3. A signed, tamper-evident audit log. Every decision the gate makes gets recorded. The tricky part: the gate runs inside the sandbox, so it cannot be trusted to sign its own log entries — a compromised gate could just rewrite history. So the gate only ever appends unsigned entries to a spool, and a separate process, running outside the sandbox with the actual signing key, drains that spool and signs it into a hash-chained log. I found and fixed a real bug here during development: a single malformed line in that spool could permanently wedge the whole audit trail, silently, forever. That's exactly the kind of thing you only discover by actually trying to break your own system.

On top of that sits an approval workflow — the feature Kiro Crew's own README lists, and the one I initially skipped. When I finally got around to it, I built it as literally: the gate, for certain tools, writes a pending request to disk and blocks, polling, until a human clicks allow or deny from a small dashboard (or the CLI) — or a timeout denies it. Headless mode has no interactive prompt to fall back on, so "wait for a human" has to be implemented as an actual wait.

The UI: yes, it's styled like Windows 1.0

The dashboard is a single dependency-free HTML page served over Server-Sent Events. At some point I realized nothing was stopping me from making it look like anything I wanted, so I gave it a diagonal-striped title bar, beveled buttons, and a monospace "MS-DOS Executive" aesthetic straight out of 1985. It's not load-bearing — it's just what happens when the UI layer is a few hundred lines of your own CSS and you decide to have some fun with it.

How I actually built it

In phases, each one narrow enough to verify by hand before moving to the next: session persistence and the warm process pool first, then memory, then scheduling, then the full security layer, then the daemon and dashboard, then the approval workflow. Every phase ended with two independent review passes — one agent looking for over-engineering and unnecessary complexity, another looking specifically for security holes — and every finding got reproduced on the actual machine before I trusted the fix. Several real vulnerabilities turned up this way, including a path-traversal bug in the approval workflow's own decision-recording function that would have let anyone holding the dashboard token overwrite arbitrary config files.

I did not take shortcuts on "verify it actually works." Sandbox containment was checked by literally trying to write outside the allowed paths and watching it fail. Process auto-restart was checked by kill -9-ing the daemon and timing how long it took to come back. The token-leak surface was checked by opening the dashboard from an unauthorized origin and confirming it got rejected. If I couldn't watch it happen, I didn't claim it worked.

Where claude-crew deliberately falls short of the original

A few things I chose not to build, on purpose:

• No Slack or Telegram integration. I don't have a use for chat-surface access to my own agent right now, and building it "just in case" felt like exactly the kind of speculative feature I'd tell someone else not to add. If that changes, the Gateway is already built to add a new surface without touching the session or security layers.
• No developer-tool integrations (PR review, incident investigation, ticket triage). Same reasoning — none of it is wired up yet, because none of it is something I currently need this for.
• No desktop app. Browser-based dashboard only, to keep the dependency count at zero.
• Kept everything local, not cloud-hosted — deliberately, for security reasons. I looked at Vercel and AWS as hosting options for the dashboard and backed away from both: this system spawns real subprocesses under an OS sandbox, holds a private signing key, and manages a live shell-executing agent. None of that belongs sitting on a public-facing server if it doesn't have to. Instead, the whole thing runs on my own machine, and I use Tailscale — a private mesh VPN — to reach the dashboard from my phone or another computer without ever exposing it to the open internet. tailscale serve even gets me a real HTTPS certificate for free, without a domain purchase or a cloud bill.

Architecture

See it in action

(A 21-second walkthrough: the retro dashboard, a live SSE connection, and a Bash tool call blocking on human approval before it's allowed to run.)

What I actually got out of this

Kiro Crew, as AWS describes it, is a genuinely well-scoped idea — long-running agents need somewhere to live, need memory, need guardrails, and need more than one door in. Trying to rebuild a version of it, from scratch, on a different execution engine, is what finally made all of that click for me in a way the README alone didn't. If you've read about something and still feel like you don't quite get it — that might be your answer too.

Source code: referenced Kiro Crew's own GitHub repository throughout as the design reference; claude-crew's code is available on GitHub (link in profile).

This is an independent, personal project. It is not affiliated with, endorsed by, or built by AWS.