AI coding tools can help you write code, run tests, and investigate errors, but there’s still a fair amount of work involved in telling them what to do. You remember to run the check. You point the agent at the relevant project. You ask it to look at the failure. Tomorrow, you may find yourself doing much of that again. Kiro Crew aims to take on more of that ongoing work.
Of course, recurring tasks aren’t a new problem. We have scripts, cron jobs, and CI pipelines for exactly this reason. Where things get more interesting is when running the task is straightforward but deciding what to do with the result requires some investigation. A test fails. Was it the application, a missing permission, or the local environment? The script can tell you that something broke, but you still have to figure out why.
That’s the use case I want to explore here: giving an agent a small, repeatable job, enough tools to investigate problems, and a place to leave the results. Let’s look at what Kiro Crew brings to this workflow and try it with a deliberately simple example.
What Is Kiro Crew?
If you read my earlier look at the Kiro IDE, you may remember its focus on adding structure to AI-assisted development through specs. Kiro Crew addresses a different part of the workflow: keeping work and context available beyond a single conversation.
Crew is an open source development workspace, not another code editor or a new model. Its default agent backend is the Kiro CLI. Crew adds the machinery around that agent: persistent sessions, memory, scheduled jobs, and interfaces for working with the results. It communicates with agent backends through the Agent Client Protocol, or ACP. You don’t need to know the protocol to use it; the useful distinction is that Crew coordinates the work while the agent carries it out. The project README covers that architecture in more detail.
There are a few capabilities worth separating:
- Context across sessions. Memory, lessons, and skills can carry information into later work. These are things you can inspect and manage, not just a promise that the agent will remember everything.
- Work triggered outside chat. Schedules, webhooks, and monitoring can start work without you typing the same request again.
- Apps for specific workflows. A Crew app can bundle an agent, instructions, a schedule, a backend, and a UI. The result doesn’t have to be another long chat transcript.
Our demo will focus on the last two. It isn’t a test of every feature in Crew, and it doesn’t require a team of agents to do something one agent can handle.
Installing Kiro Crew
As of October 13, 2026, the latest stable release is v0.8.0. 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. Version 0.8.0 bundles the agent CLI, so follow the first-run sign-in instructions rather than starting by 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, skip it for this example. That option hosts Crew itself on a remote machine; it isn’t required to work with an application that uses AWS APIs.
Crew is open source under Apache 2.0, but agent requests still count toward your Kiro plan. Scheduling a request doesn’t make the model usage free.
Screenshot to add: Kiro Crew Desktop after sign-in, with the main workspace and navigation visible. Suggested alt text: “Kiro Crew Desktop with navigation for sessions, schedules, and apps.”
A Small Job for Our Agent
The example is called LocalStack Ops. It checks a small event-driven application: uploading a file to S3 invokes a Lambda function, which writes a record to DynamoDB. In other words, an object arrives, some code processes it, and we check that the result was stored.
The agent’s job is to deploy the infrastructure, run that check, 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 can fit into a demo.
Demo repository: [REPOSITORY URL TO ADD]. Clone or download it before continuing, and keep the folder in place: the installed Crew app uses the scripts and infrastructure in that source directory.
Why Run This Against an Emulator?
An always-on agent might bring to mind a server running in the cloud. That’s one way to host Crew, but where the agent runs and what it operates on are separate decisions.
Here, both Crew and the application’s AWS environment run on our computer. LocalStack emulates the AWS services, so we can introduce a mistake and let the agent investigate without giving it access to a real AWS account. Terraform uses local endpoints and test credentials. We don’t need an EC2 instance or a deployed cloud application to explore the workflow.
That makes this a useful place to learn what the agent does, which actions need approval, and whether its diagnosis is supported by the logs. It doesn’t mean an emulator replaces every test on AWS, or that a local agent can’t damage local files. We still need to review its access and actions.
Also, “local” describes the application infrastructure, not an offline LLM. Model requests still go to the configured provider. Use synthetic data, and keep secrets out of prompts and screenshots. Your computer also needs to be awake, with Crew running, for local scheduled work to execute.
What You’ll Need
Besides Kiro Crew Desktop and a signed-in Kiro account, install:
- Docker, with the engine running.
- Terraform and AWS CLI v2. The scripts use both through wrappers; they still need to be installed.
- Node.js with
npx, which runs the LocalStack MCP server, and Python 3 available aspython3, which records each result. - LocalStack’s
lstkCLI and a LocalStack account. The permission-failure exercise also needs access to IAM policy enforcement, currently included in Base and Ultimate.
Authenticate lstk once, completing the browser sign-in:
lstk loginThe demo uses lstk terraform and lstk aws, not the legacy localstack CLI. You don’t need real AWS credentials. You also don’t need to build the dashboard; its compiled UI is included in the repository.
MCP, or Model Context Protocol, gives the agent tools to inspect LocalStack and investigate failures. This is the same server 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. A connection available to your normal Crew conversations doesn’t automatically mean an app’s agent has that connection too.
Running the Demo in Kiro Crew
Let’s install the app, get a passing baseline, and then give the agent something to investigate.
1. Install and Enable LocalStack Ops
In Crew’s sidebar, open Apps → Discover. Select Sources, the gear control in the Discover header, and choose the option to install from a local directory. Select the crew-app folder inside the demo, not the repository root. That’s where the app’s app.json manifest lives.
Review the app and install it. Then go to Library. One slightly confusing detail: newly installed apps are disabled, and disabled apps may be hidden. Select Show n disabled apps if you don’t see LocalStack Ops. Open it, choose Enable, and review the third-party-app consent before approving this app.
Screenshot to add: Library with “Show n disabled apps” exposed and LocalStack Ops selected. Suggested alt text: “LocalStack Ops in Kiro Crew’s Library, with the option to enable the installed app.”
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 starts disabled so it won’t begin running every 15 minutes while you’re still setting up.
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.
2. Run the Check and Watch for Approvals
Open Schedule, find localstack-ops-check, and use its immediate-run action. Leave the recurring schedule disabled for now.
Keep Crew’s alerts panel open during this first run. Tool approval requests appear there, not necessarily in the Schedule execution view. Review requests to inspect or start LocalStack, run the deployment and test script, and record the result. A notification sound may be the only obvious indication that the agent needs you.
Screenshot to add: Schedule with
localstack-ops-checkand its immediate-run control, followed by the alerts panel showing a tool approval. Suggested alt text: “Running the LocalStack Ops check and reviewing its requested command in Kiro Crew.”
Don’t walk away yet. An unanswered approval can expire, preventing the workflow from finishing. A scheduled agent is still subject to permissions; “scheduled” and “allowed to do everything unattended” are not the same thing.
The agent checks LocalStack through MCP, starts it if needed, and runs scripts/deploy-and-smoke.sh. That script applies Terraform, uploads an object 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.
If MCP can’t start the container because it lacks an authentication token, the workflow falls back to lstk, using your earlier sign-in. That doesn’t remove MCP’s role in inspecting the running environment.
3. Check the Actual Result
Open LocalStack Ops. A completed, successful run should show Passed, a nonzero Recorded runs count, and a timestamped summary. The panel refreshes its history every 15 seconds.
Screenshot to add: A real passing run in LocalStack Ops. Suggested alt text: “LocalStack Ops showing a passed check and its timestamped run summary.”
The distinction between the two 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 alerts panel and the Schedule execution details first.
If you’re updating an earlier copy of the demo, use Sync in Library rather than reinstalling it. Fully quit and reopen Crew after agent changes; use View → Force Reload for a stale dashboard. The repository README has the longer troubleshooting guide.
4. Give It a Failure to Investigate
A passing check is useful, but we could also get one from a shell script. Let’s introduce a small permissions bug and see what the agent can add.
For this exercise, LocalStack must start with IAM enforcement enabled. The demo requests ENFORCE_IAM=1 when starting it, but it can’t change the startup settings of an already-running container. If you’re using a disposable demo instance that was started without enforcement, stop it with lstk stop before rerunning the job. Don’t stop an instance that other work depends on.
After recording a passing baseline, open infra/main.tf. Inside aws_iam_role_policy.processor, remove this statement from the Statement list:
{ Effect = "Allow" Action = ["dynamodb:PutItem"] Resource = aws_dynamodb_table.runs.arn},Run localstack-ops-check again and review its approvals. 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 MCP’s log-analysis and IAM-analysis tools to investigate, then record a Failed result with the evidence it found. Look for the denied dynamodb:PutItem action and the affected function or role, not just a generic suggestion to “check permissions.” The exact wording can vary because the explanation comes from an agent.
Restore the statement and run the job again. Confirm that the new result is Passed and that the failure remains visible in the history. We make the code change ourselves here; this demo asks the agent to diagnose the problem, not silently broaden permissions to make the test pass.
Screenshot to add: The passing, failed, and recovered runs, with actual IAM diagnostic evidence visible. Suggested alt text: “LocalStack Ops run history showing a permission failure between two passing checks.”
5. Make It Recurring—When You’re Ready
Once the manual runs work, enable the job in Schedule to use its 15-minute recurrence. With the default approval behavior, expect to review tool requests on subsequent runs too.
Crew supports unattended execution, but that needs a deliberate permission decision. For example, the cron auto-approval setting described in the demo README applies across scheduled jobs, not only this app. I wouldn’t make that a prerequisite for a first experiment. Start by understanding the workflow and its access.
Disable the schedule when you’re done. Cancelling one execution doesn’t disable future runs, and repeated agent work consumes model usage even though our AWS environment is local.
Where Does This Fit?
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. The LocalStack MCP server provides the tools used in this example.
My suggestion is to pick one repetitive task you already understand. Give Crew the instructions and tools for that task, watch a few runs, and check the evidence it leaves behind. That’s a more useful first test than asking an agent to take over an entire project.
