Kiro Crew: My Agents' New Harness and Surface

August 21, 2026

By Gene Alpert · Philadelphia

I've been running Kiro Crew on a single EC2 instance for about a week now. It's an open-source autonomous agent platform — one agent with persistent memory, scheduled jobs, background subagents, and the ability to learn from corrections. This post is an introduction to what it is and what I've been building with it.

What Is Kiro Crew?

Kiro Crew is a self-hosted AI agent management layer. You install it on your own machine (or EC2, VPS, whatever), point it at an LLM provider, and you get a persistent agent that remembers context across sessions, runs scheduled tasks, orchestrates background work, and operates autonomously on your behalf.

The key ideas:

• One agent, many capabilities — rather than a fleet of specialized bots, you get a single agent that accumulates knowledge and skills over time
• Persistent memory — it remembers your preferences, project context, and corrections across every session
• Self-learning — when you correct it, those corrections persist permanently and change future behavior
• Background autonomy — cron jobs, monitoring loops, subagent orchestration for parallel work
• Your infrastructure — runs where you want, uses your API keys, your data stays on your machine

Why I Chose It

Simple Installation

The whole setup is a pip install and a CLI command. No Docker compose files, no Kubernetes manifests, no database clusters to provision. On my t4g.medium (2 vCPU, 8 GB RAM), the full platform runs alongside several other services without breaking a sweat.

pip install kirocrew
kiro-cli init
kiro-cli start

That's genuinely it. The gateway starts, the dashboard is available, and you're talking to your agent within minutes.

Control via kiro-cli

Everything is manageable from the command line. Status checks, workspace management, cron jobs, health diagnostics — it's all kiro-cli subcommands. No web admin panels to navigate, no config files scattered across the filesystem. When something feels off, kiro-cli doctor tells you what's wrong.

Open Source

The code is on GitHub at kirodotdev/KiroCrew. I can read the source when behavior surprises me, contribute fixes upstream, and know exactly what's running on my server. The codebase is clean and navigable — when something doesn't work as expected, I can trace it rather than guess.

What I've Built So Far

In about a week, working through the dashboard chat interface, here's what the agent has handled:

How It Works Day-to-Day

The interaction model is conversational. I open the dashboard (accessible via Cloudflare Tunnel from any device), describe what I need, and the agent does it. No prompt engineering, no tool configuration — it has access to the filesystem, shell, web, and the various APIs I've connected (Google, AWS, Cloudflare).

If you're familiar with agent runtimes like OpenClaw or Anthropic's tool-use patterns, Kiro Crew occupies a different niche. OpenClaw gives you a multi-agent framework where you define agent identities, bind them to communication channels (Zulip, Discord), and build workflows through inter-agent messaging. It's powerful for team-of-agents architectures but requires significant orchestration. Hermes and similar MCP-native runtimes focus on giving a single model access to tools through the Model Context Protocol.

Kiro Crew is opinionated about the full stack: one agent, one workspace, with persistent memory, self-learning, scheduled automation, and subagent orchestration built into a single coherent surface. You don't configure inter-agent communication because there's one agent that does everything. You don't manually wire up tool servers because the platform manages them. The tradeoff is clear: less architectural flexibility, more immediate productivity.

It's also worth noting that this is both a personal assistant and a business platform. Because it runs on my EC2 instance, the agent has direct access to the local filesystem, can spin up services, and can reach the broader AWS account — S3, CloudFront, Bedrock, whatever I've granted the instance role. Personal tasks (scheduling an inspector, emailing a friend) and infrastructure work (deploying a site, running AI vision analysis) happen in the same session, using the same tools. There's no separate "dev environment" vs. "assistant" — it's all one surface with access to real resources.

What makes it feel different from a chat assistant:

• It remembers. I told it my home address once (for the inspector email). It never asked again. Same for contact details, project preferences, API configurations. This isn't RAG retrieval — it's structured semantic memory that the agent reads at session start and updates as facts change.
• It learns from mistakes. I corrected a name once — it saved the correction and has never gotten it wrong since, even in new sessions. Learned corrections persist globally and override default behavior, which means the agent gets better the more you use it.
• It works in the background. Cron jobs check my email every 5 minutes. The video labeling ran autonomously across hours while I did other things. Monitoring loops watch for external events and act on them without me being online.
• It accumulates capability. Each project builds on the last. The Google OAuth setup enabled email which enabled calendar which enabled the inspector workflow. The Cloudflare Tunnel setup enabled the trading dashboard which enabled the video catalog site. Skills compound.

What's Next

This is the first in what will likely be a series. Upcoming posts will cover specific workflows in more detail — how the video catalog was built end-to-end, how the trading dashboard deployment works, and how I use scheduled jobs and monitoring loops for ongoing autonomous tasks.

If you're interested in running your own, the repo is here. Happy to answer questions — gene@wardcrew.org.