Kiro Crew took me a while to get. I read the announcement, poked around the app, and kept asking myself, “OK, but what is this for?” It isn’t an editor. It isn’t a new model. It isn’t exactly a chat app, either. It wasn’t until I gave it a real, typical, recurring job that it began to make sense.
So, before we build anything, let’s dig into what problems Kiro Crew aims to fix.
#
Think about how you use an AI coding agent today. You open a session, explain the project, ask it to do something, review the result, and close the window. For instance, you may ask it to run some tests, review open PRs or examine why the build failed. There’s definitely a lot of coordination and iteration in the “ask it to do something” section that I’m leaving out, but generally that’s the gist.
Tomorrow you may have a similar sequence of tasks, so you open a new session and do it all over again. Run the tests. Check the open PRs. Look into why that build failed. As the Kiro team described in their post introducing Crew, “You end up being the integration layer between your own tools, and the moment you step away, everything stalls and waits for you to come back.”
Kiro Crew aims to make the agent take on more of that integration work itself: it remembers context between sessions, it can start work on a schedule or based on an event, and it gives you details about what it did when you come back.
#
You’ve likely heard about OpenClaw, the open-source personal AI assistant that lives in your chat apps and does things for you, sometimes on its own schedule. It’s a useful reference point for understanding Crew, as the Kiro team says OpenClaw was part of their inspiration. A rough way to think about Crew is OpenClaw-style automation, aimed at development work, with some added guardrails.
Instead of clearing your inbox, a Crew agent might check your open PRs every morning, keep an eye on a deployment, triage new issues, or, in the case of our demo below, rerun a smoke test and dig into the logs when it fails.
Crew is an open-source workspace that wraps an agent (by default, Crew’s built-in Kiro Agent engine) with stuff a one-off chat session doesn’t have:
- It remembers things. Memory, lessons, and skills carry context into later sessions. You can look at these and edit or delete them.
- It can start work without you. Schedules, webhooks, and monitor loops (which keep checking something until it changes) can kick off a task without you typing the same request again.
- It can package a workflow as an app. A Crew app bundles an agent, its instructions, a schedule, a small backend, and a UI. You install it once and get a dashboard instead of a long chat transcript.
Crew talks to agents through the Agent Client Protocol (ACP), but you don’t need to know anything about that to use it. Crew coordinates, but the agent does the work. The project README covers the architecture if you’re curious.
If you read my earlier look at the Kiro IDE, Kiro specs were about adding structure to a single piece of AI-assisted work. Crew is about orchestrating the recurring pieces of AI-assisted work.
#
Crew is genuinely interesting, but it’s worth going in with realistic expectations:
- This costs credits. Sometimes a lot of them. Crew is free and open source (Apache 2.0), but every agent request still counts against yourKiro plan . An agent that runs every 15 minutes and does real investigation each time can chew through credits fast, especially if you forget it’s running. Start with manual runs or monitor schedules closely, and turn off jobs you’re not using. If a step doesn’t need reasoning, Crew can run it as a plain script without a model call, so use that where you can.
- It’s young. At the time of writing, Crew is pre-1.0. Some of what you see may look a little different from my screenshots.
- “Automated” doesn’t mean “unattended.” By default, the agent asks for approval before running tools. That’s a good thing, but it means a scheduled job can sit waiting for you to click approve. You can loosen this, but that’s a deliberate decision you should make after you understand what the agent is doing.
- Local means your machine has to be on. If you run Crew locally, as we will here, scheduled jobs only run while your computer is awake and Crew is open.
- The agent can be wrong. It’s still an LLM. Its diagnosis of a failure is a starting point, not a verdict. Check its evidence.
- Not every recurring task needs an agent. If all you need is “run this test every hour,” a cron job or CI pipeline is cheaper and more predictable. Crew makes running the task easy, but figuring out what the resultmeans takes some investigation.
That last point is what the rest of this post is about. We’ll give an agent a small, repeatable job: deploy a tiny app, test it, and, when it breaks, figure out why and leave a note.
#
As of writing, the latest stable release is v0.11.2. This is still a pre-1.0 project, and the interface is changing quickly. For this walkthrough, we’ll use the desktop application on macOS.
Download the stable macOS installer from the Kiro Crew downloads, install it, and open the app. Since v0.11.0, the desktop app ships with Crew’s built-in agent engine, called Kiro Agent, so you don’t need to install the Kiro CLI separately. Just follow the first-run sign-in instructions rather than building Crew or installing a separate Python environment. The installation guide covers other platforms and installation methods.
Use the local setup. If you encounter an option to run Crew on AWS, you can skip it for this example. That option hosts Crew itself on a remote machine.
#
Our example is called “LocalStack Ops.” It runs tests against a small event-driven AWS application:
- Upload a file to S3;
- The upload triggers a Lambda function;
- The Lambda writes a record to DynamoDB.
The agent’s job is to deploy the infrastructure, run the checks, investigate a failure (if there is one), and record the outcome in a Crew app. I’ve kept the application small because the interesting part here is how we give Crew a repeatable workflow, not how many services we’re running.
The demo repository contains the code for the small AWS application that we’ll run, the tests that Crew will use and the Crew app that will display the results.
It’s worth noting that while you may often run Kiro Crew locally, you can also use Crew in a cloud-oriented workflow by hosting Crew on AWS using EC2 and having an agent deploy to, test, or inspect resources in an AWS account. But whether you are running locally or in the cloud, if you are working with real AWS resources, it means the agent’s approved commands can impact real environments and create billable usage.
In this walkthrough, we’ll have both Crew and the application’s AWS environment run on our computer. LocalStack for AWS emulates the AWS services, and Terraform points at LocalStack with test credentials instead of a real AWS account. The agent can deploy the sample, run its smoke test, and investigate an intentionally introduced failure without waiting on or paying for AWS resources. We also don’t need an EC2 instance or a deployed cloud application.
That makes this a useful place to iterate on development, particularly when an agent is involved in writing the code, before touching real cloud infrastructure. There’s no need to hand the keys to the real cloud to a coding agent or a testing agent (even when running in Crew) in order to develop and test the application. However, this doesn’t mean an emulator replaces every test on AWS, or that a local agent can’t damage local files on your laptop, so be sure to review its access and actions as Crew runs.
Also, for clarity, when I say that this runs “locally,” I’m only referring to the application infrastructure, not a local LLM. Model requests still go to the configured provider, so it’s best to use synthetic data and keep secrets out of prompts. Lastly, your computer does need to be awake, with Crew running, for the local scheduled work to execute.
Besides Kiro Crew Desktop and a signed-in Kiro account, install:
- [Docker](https://docs.docker.com/get-docker/) , with the engine running.
- [Terraform](https://developer.hashicorp.com/terraform/install) and[AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) .
- Node.js , which runs the LocalStack MCP server, and Python 3 available as
python3, which records each result. - LocalStack’s
lstkCLI and a LocalStack account. The permission-failure exercise also needs access toIAM policy enforcement , currently included in Base and Ultimate.
Clone the demo repository:
Authenticate lstk once, completing the browser sign-in:
LocalStack’s MCP server gives the agent tools to inspect LocalStack and investigate failures. This is also used by the LocalStack Kiro Power. The demo’s app agent declares its own MCP connection, so installing a Power in the Kiro IDE isn’t a prerequisite for this app, but if you’re a Kiro user, it may be useful.
The MCP server also needs your LocalStack auth token, and it can’t use the credentials lstk just stored. Normally you’d hand an MCP server its token through its configuration, and Crew has a secrets vault for exactly this kind of credential. However, at the time of writing, an app’s MCP server can’t read from that vault. The Crew team hasn’t yet decided how apps should receive secrets (kirodotdev/KiroCrew#10641). Anything put directly in an app’s MCP configuration is passed through as plain text, and secrets don’t belong in a file you’d commit.
So the demo takes a simple workaround: it reads the token from a file in Crew’s data folder, outside the repository. Copy your token from the Auth Tokens page, then save it from your clipboard. The umask makes the file readable only by your user account:
When the agent starts, the app launches the MCP server through a short script, crew-app/mcp/localstack-mcp.sh, which reads that file and passes the token along. It’s worth a quick look before you enable the app. Keep in mind the file isn’t encrypted the way a vault entry would be, so the agent can read it like any other file in your home directory.
If you skip this step, the agent won’t have any LocalStack MCP tools and will record runs as failed, with “LocalStack MCP server unavailable” and a pointer back to this step.
#
Let’s install the app, get a passing baseline, and then give the agent something to investigate.
In Crew’s sidebar, open Apps → Discover. Select Manage App Sources, which is a cylinder control in the Discover header, and go to the option to Install from Path. Paste the path to the crew-app folder inside the cloned demo (not the demo root folder) into the text box. That’s the folder where the app’s app.json manifest lives. Click Install.
At this point, the local app is installed, but it’s not enabled and finding it can be a little tricky, as disabled apps may be hidden (they were for me by default). To enable the app, go to Library. Click the link right below where it says “Manage installed apps” at the top that reads Show n disabled apps. Find LocalStack Ops, click the three dots below the icon, and choose Enable.
Finally, when the warning dialog opens, click the button to Trust this app and enable.
Enabling the app registers its agent, workflow instructions, backend, dashboard, and scheduled job. You should now have a LocalStack Ops sidebar entry and a job named localstack-ops-check under Schedule. The job’s recurring schedule is disabled by default, so it won’t begin running automatically.
This packaging is an important part of Crew’s model. We’re installing a reusable workflow, not pasting a large prompt each time we want to check the application.
Open Schedule, find localstack-ops-check. The app should be d by default. Before we can run it, we’ll need to resume it by clicking the three dots to the right of the “Delete” button and choosing Resume.
Once the app has been resumed, you can choose the three dots again and click Run now. You should see the status change to Running. The whole process should take a few minutes to run. Be sure to keep an eye on Crew’s Notifications panel during the run, though. Tool approval requests appear there, and they can be easy to miss. Listen for the audio cue and then click the little bell in the upper-right-hand corner to open Notifications. Review the requests and approve.
An unanswered approval can expire, preventing the workflow from finishing.
Here’s what’s happening when the app is running:
- The agent checks that LocalStack is running, and, if it isn’t, starts it up;
- It then runs
scripts/deploy-and-smoke.sh. This script: - Applies Terraform to create the S3 bucket, Lambda function and DynamoDB resources as well as their required IAM permissions
- Uploads an object to S3 with a fresh run ID, and waits for the corresponding DynamoDB record.
- The agent then invokes a recorder that saves a summary and any diagnostic evidence for the app.
There are a couple of places where Crew will record the results of the run. First, it will always show up under Sessions in the sidebar, which will give you the details of the run in text form.
However, since we installed this as an app, we’ve created a custom output with the necessary details in an easy-to-read format. Open LocalStack Ops on the left-hand navigation. A completed, successful run should show Passed, along with a Recorded runs count and a timestamped summary. The panel refreshes its history every 15 seconds.
The distinction between the views matters: Schedule tracks the agent’s execution, while LocalStack Ops displays results the workflow explicitly recorded. Pending with No runs recorded doesn’t prove the infrastructure is broken—or that a check is still running. It means the app has no recorded result yet. Check the Notifications panel and the Schedule execution details first.
If you run into issues, the repository README has a detailed troubleshooting guide.
A passing check is useful, but the point of the exercise is to use local emulation and AI-driven automation to verify that a change doesn’t introduce any potential issues, so let’s introduce a small permissions bug and see what the agent can add.
A typical local development workflow would involve doing development using the default IAM enforcement disabled in LocalStack. This enables you to quickly develop, deploy and test things locally without letting permissions issues become a blocker. However, before you push your changes to the pipeline, it’s recommended that you enable IAM policy enforcement and retest to ensure that you haven’t accidentally introduced any permissions issues.
That’s exactly what this automated test is designed to do. It starts LocalStack with IAM enforcement enabled using ENFORCE_IAM=1 when starting it. Let’s see this in action by introducing a permissions issue.
Open infra/main.tf from the cloned repository. Inside aws_iam_role_policy.processor, remove this statement from the Statement list:
Go to Schedule and click Run now on the localstack-ops-check again. You’ll still need to review and approve the tool usage. Terraform applies the changed policy. The Lambda function should now be denied permission to write its result, and the smoke test should time out waiting for the record.
The agent is instructed to use LocalStack MCP’s log-analysis and IAM-policy-analyzer tools to investigate the failure. The IAM policy analyzer searches LocalStack’s logs for permission denials, so it needs the same IAM enforcement access as the rest of this exercise. The agent will record a Failed result with the evidence it found, both in Sessions:
…and in the LocalStack Ops dashboard:
Feel free to restore the statement and run the job again if you’d like to leave the sample in the passed state. Since we resumed the job in step 2, it will also keep running on its schedule, so go back to Schedule and it when you’re done. Cancelling a single run doesn’t stop future ones.
Everything Crew installed came from the crew-app folder, and most of what makes it a Crew app is declarative:
The manifest, app.json, ties these pieces together. The part that defines when the work happens is the crons entry:
Let’s look at what it’s doing:
cron_expris a standard five-field cron expression, here stating that the job will run every 15 minutes.agentandmessagesay which agent runs and what it’s asked to do.enabled: falseis why the job was d by default; it only sets the initial state, so you decide when it starts running.
A few changes you might make to adapt it:
- Run it less often. A check like this makes more sense at the end of the workday than every 15 minutes. Use
"cron_expr": "0 18 * * 1-5"and add atimezonesuch as"America/New_York". Without one, Crew evaluates the schedule in UTC unless you’ve set a default. - Skip the model when you don’t need it. Replacing
agentandmessagewith acommandruns the script directly, with no model call and no credits. You lose the investigation, which is the part an agent adds. - Start fresh each run. By default, a job reuses one agent session, so context carries from run to run. Setting
persistent_sessiontofalsegives each run a clean slate. - Trigger it from an event instead. Crew’sinbound webhooks let something outside Crew start an agent turn, such as a Git hook, a script, or a CI job, by POSTing to Crew’s local API. Crew only listens on localhost by default, so a remote caller like a CI runner needs an SSH tunnel or a reverse proxy to reach it. You configure webhooks on Crew’s Webhooks page, which is currently a feature that you enable in Settings, not in the manifest. Each webhook source is mapped to an installed agent, such as this app’s
localstack-ops-agent.
The agent file lists the tools the agent may use and declares its own LocalStack MCP server, because an app’s agent doesn’t inherit the MCP connections you’ve set up elsewhere in Crew.
To change an installed app, edit the files and select Sync on the app in Library. If you changed the agent, you’ll need to quit and reopen Crew afterward, since a job’s existing session keeps the agent it started with. Crew’s manifest reference covers every field, and the scheduling guide covers jobs in more depth.
#
If all you need is to run a deterministic test on a timer, a script or CI job is probably enough. The interesting part of Crew is being able to attach investigation, context, and a useful interface to work that would otherwise send you back to a terminal and a pile of logs. Our example uses an existing script for the repeatable check and an agent for coordination and diagnosis. LocalStack gives that agent a local environment to operate on, but the pattern could also apply to failed builds, dependency checks, or other recurring development work. Start with a task whose result you can independently verify, then decide where agent assistance is actually useful.
To explore further, start with the Kiro Crew project, its installation guide, and the App Kit guide if you want to package your own workflow. If you’d like to integrate LocalStack, the LocalStack MCP server provides the tools your agent will need for local development and testing.