AWS makes Kiro Crew bots generally available with memory and schedules
Kiro Crew bots are now generally available, AWS's Kiro team announced on November 5, 2026. A bot is a named, long-running agent that a developer defines for one narrow part of the job, such as triaging new issues, watching CI or checking release readiness. Each bot keeps its own memory, runs its own sessions, works on a schedule if asked to, and reports back through a single ongoing chat instead of leaving the developer to track every agent run by hand.
The feature lives inside Kiro Crew, the agent workspace that Kiro released as open source on August 4, 2026 after it began as an internal Amazon project called MeshClaw. According to that launch post, Crew had been adopted by more than 39,000 Amazon builders in under six months and had nearly 500 contributors. Bots move Crew from a tool that runs sessions on request toward something closer to a set of standing roles, each with its own scope, tools, model choice and permissions.
Bots run wherever Crew runs: on a laptop, on an always-on Mac Mini or on an Amazon EC2 instance, in the examples Kiro gives. Kiro paid plans start at $20 a month for 1,000 credits, extra credits cost $0.04 each, and the announcement states that every bot result shows the model and the credits it used.
··········
WHAT KIRO CREW BOTS ARE AND HOW THEY DIFFER FROM CREW SESSIONS.
Before bots, a Kiro Crew user worked mostly in sessions: a conversation with an agent that could plan a task, spawn parallel subagents, call tools and run scheduled jobs or heartbeats that watch pull requests and deployments. Those capabilities were already present in the first open-source release and in the versions that followed through Crew 0.9.0 on October 16, 2026. What a session lacked was a persistent identity tied to one responsibility.
A Kiro bot supplies that identity. Each bot has a name, an avatar and one continuous chat where the developer gives direction and receives results. It keeps its own notes for tracking work and gets a workspace in Kiro Crew with a dashboard that the developer customizes together with the bot. Kiro describes the bot as an owner of a slice of the work: it decides which sessions to start, follows them, redirects them and brings the results back into its chat.
The Kiro team frames the change around learning. Kiro Crew already learns from how a person works, turning corrections into lessons and repeated workflows into skills, and bots carry that learning into a specific role. Because memory is kept per bot, what an intake bot learns about labeling issues does not leak into a code review bot that applies a different set of past decisions.
··········
HOW KIRO BOTS RUN PARALLEL SESSIONS, SCHEDULES AND MEMORY.
The core mechanism is delegation. A bot can start several sessions at once, monitor them and step in to change direction, then summarize what came back. When a task reaches a point that needs a human decision, the bot asks the question in its chat and keeps working on the parts that do not depend on the answer, so a pending question does not stall the whole job.
Schedules are set in plain language inside the bot's chat. Kiro's examples are investigating overnight build failures and preparing release notes every Friday. Scheduled activity is written to a work log, and only findings or decisions that need the developer are pushed back into the chat. The settings screens published with the announcement show a Schedules tab with a heartbeat option, configured in the example to run every four hours and at most six times a day.
Model selection is split in two. The developer picks the model and reasoning effort for the bot itself and, separately, a worker model and worker reasoning effort for the agents the bot dispatches. Kiro's suggested pattern is a stronger model for planning and a faster, cheaper model for routine checks, which directly affects credit consumption because Kiro prices models differently. On its pricing page, Kiro gives the example that a task costing a given number of credits in Auto mode costs 1.3 times as much with Claude Sonnet 4.6.
Memory is visible and editable. A developer can open a bot's notes and memory, change what it has recorded or delete entries, and the dashboard the bot maintains shows the current state of its work, with links to the sessions behind each item. In the demonstration bot Kiro calls GitHub Issuer, the dashboard tracks a weekly trending report, the number of days since the last scan and filtering of bot-filed issues out of trend counts, and shows figures such as 1,468 open issues filed by people, 316 opened in the last seven days, and 367 bugs against 695 feature requests.
··········
KIRO BOT PERMISSIONS, APPROVALS AND SECURITY CONTROLS.
Every bot receives only the tools and permissions its role requires, and permissions are configured bot by bot. Kiro's own examples make the boundary concrete: a research bot can search the web and read files but cannot modify them, while a deployment bot can run deployment scripts and must ask for approval before each change. A bot can request additional tools, and nothing changes until the developer approves the request.
A feature called dynamic capabilities, labeled as a preview, lets a bot ask for tools that one of its worker agents needs through a card in the chat. Each of those requests still requires explicit approval. The settings panel also exposes a permissions level (shown as "Trust" in the screenshot), a toggle to lock the dashboard layout, and the model and worker controls described above.
These controls sit on top of the security model Kiro Crew already had. The August launch post lists an OS-level sandbox, commands denied by default, blocking of suspicious patterns and sensitive paths, credential redaction, a signed audit log of agent actions and a dashboard that binds to the local machine by default. The Crew documentation adds that agent command execution is disabled if the inner sandbox fails, unless an operator deliberately sets an override that Kiro describes as less safe.
··········
FOUR EXAMPLE KIRO BOTS AWS DESCRIBES FOR SOFTWARE TEAMS.
The announcement describes four bots built around common engineering chores. Each example pairs a narrow job with a clear limit on what the bot may do, which is the pattern Kiro recommends for a first bot.
........
Example bot | What it does | Boundary set by Kiro |
Intake bot | Reads new issues, labels them, flags likely duplicates, drafts reproduction steps | Can comment but cannot close tickets |
Build-health bot | Checks CI every 30 minutes, separates new failures from known flaky tests | Reports only what needs attention |
Code review bot | Checks new pull requests against past decisions, comments, requests changes | Cannot approve or merge |
Release-readiness bot | Checks merged changes for tests and release notes | Needs the developer's sign-off to ship |
........
The build-health example is the most demanding on usage, since a check every 30 minutes adds up to 48 runs a day. The release-readiness bot shows the opposite pattern, where the bot does the checking and the human keeps the final decision. GitHub has moved in a similar direction with scheduled, trigger-based agent work, covered in our report on GitHub Copilot Automations, shared team workflows and AI credit limits.
··········
KIRO CREW BOTS AVAILABILITY, PLANS AND CREDIT PRICING.
Bots are generally available now in Kiro Crew, which is downloaded from the Kiro website or built from its public GitHub repository. Kiro's pricing page states that Kiro subscriptions cover the IDE, the CLI, Kiro Web, Crew, ACP-compatible editors and CI/CD automation, and the bots announcement does not introduce any separate fee per bot. What a bot costs therefore depends on the credits its sessions consume, which vary with task complexity and the models chosen.
........
Kiro plan | Monthly price | Included credits | Extra credits |
Free | $0 | 50 | Not listed |
Pro | $20 per user | 1,000 | $0.04 per credit |
Pro+ | $40 per user | 2,000 | $0.04 per credit |
Pro Max | $100 per user | 5,000 | $0.04 per credit |
Power | $200 per user | 10,000 | $0.04 per credit |
Teams and Enterprise | $20 per seat, 2 seats minimum | 500 per seat, pooled | $0.04 per credit |
........
Prices as listed on the official Kiro pricing page on November 8, 2026. Every paid individual plan works out to $0.02 per included credit, so credits bought beyond the allowance cost twice as much as credits inside a plan. Kiro meters usage to a hundredth of a credit and says simple prompts can use less than one credit, while complex tasks such as spec execution use more. Included credits reset each month; add-on credits expire 12 months after purchase.
For scheduled bots, the useful figure is how many credits a plan leaves for each run. The table below divides each plan's monthly allowance by the two schedules Kiro itself shows: a CI check every 30 minutes (1,440 runs in a 30-day month) and a heartbeat every four hours capped at six runs a day (180 runs). The result is the average credit budget per run if the bot were the only thing using the plan, which it rarely is.
........
Kiro plan | Credits per run, check every 30 min | Credits per run, heartbeat every 4 h |
Free | 0.03 | 0.28 |
Pro | 0.69 | 5.56 |
Pro+ | 1.39 | 11.11 |
Pro Max | 3.47 | 27.78 |
Power | 6.94 | 55.56 |
........
The arithmetic shows why Kiro recommends a cheaper worker model for routine checks. On the Pro plan, a build-health bot that consumed one full credit per check would need 1,440 credits a month, 440 more than the plan includes, which at $0.04 each adds $17.60 before any interactive coding. The same bot on a four-hour heartbeat fits comfortably inside Pro. Kiro does not publish typical credit figures for bot runs, so these numbers set the budget a bot has to stay within; they do not predict what a given bot will actually spend.
Teams have a separate mechanism. Credit pooling, announced by Kiro on November 4, 2026 for Enterprise customers, puts 500 included credits per $20 seat into one shared pool, lets admins set limits per user, group or profile, and sends alerts at 80% and 100% of usage by default. A five-seat team pays $100 a month for a pool of 2,500 credits, and pooling does not allow overages beyond purchased credits. Kiro has not said how bot activity is broken out in pooled usage reports.
··········
WHERE KIRO CREW BOTS CAN RUN AND HOW TO SET ONE UP.
A bot runs on whatever machine hosts the Kiro Crew gateway. Kiro's announcement names a laptop, a Mac Mini and an EC2 instance, and the Crew documentation for always-on operation describes a system service on Linux or macOS, a tmux session, a Docker image published for amd64 and arm64, or a remote Linux host. For a remote host, the documentation lists a modern Linux distribution such as Ubuntu 22.04, Debian 12 or Amazon Linux 2023, about 10 GB of RAM as a minimum with 16 GB described as comfortable, and a couple of vCPUs for a single user.
The Docker route uses a single command from the documentation:
docker run -d --name kirocrew -p 127.0.0.1:5476:5476 -v kirocrew-home:/home/kirocrew ghcr.io/kirodotdev/kirocrew:stablePublishing the port only to 127.0.0.1 keeps the dashboard local to the host, and the documentation recommends reaching it remotely through an SSH tunnel or a tunnel provider with its own authentication. Dashboard tokens last one hour by default and up to 20 hours.
Creating a bot follows four steps that Kiro lists in the announcement. The developer opens the bots workspace in the Kiro Crew sidebar, adds a bot and chooses either the default agent or a custom agent as its base, with the custom agent supplying the prompt, model, tools and skills. The next step is to give the bot one narrow, repeatable responsibility with a defined scope, refine it through the chat, and only then add a schedule. Existing chats are not affected when a bot is created from a custom agent.
Kiro's guidance to begin with a single narrow role also fits the cost picture above, since a bot with a short job description, a cheap worker model and an infrequent heartbeat consumes far fewer credits than a broad assistant checking several systems every half hour. AWS has been building agent infrastructure at several layers, including the open-source runtime described in our article on AWS Infinity, a Rust agent runtime for about 75,000 idle AI agents, and Cursor recently pushed its cloud agents into app hosting, as we reported in Cursor now builds and hosts live web apps with Postgres and sign-in.
··········
KIRO CREW BOTS: CONFIRMED FACTS AND OPEN QUESTIONS.
Kiro's own pages establish the main points. Bots are generally available in Kiro Crew as of November 5, 2026; each has a name, a single chat, separate memory, notes and a dashboard; bots can run several sessions in parallel, work on schedules and heartbeats, and use different models for planning and for worker agents. Permissions are set per bot, any request for new tools waits for approval, and dynamic capabilities remain in preview. Kiro subscriptions cover Crew, paid plans start at $20 a month for 1,000 credits, and extra credits cost $0.04.
Several points are not documented. Kiro does not publish how many credits a typical bot run consumes, so the cost of a bot that checks CI every half hour can only be estimated after it has run for a while, using the per-result credit display. The announcement does not say how bot usage appears in Enterprise pooled reporting, and it lists Slack and other intake channels only as possible future additions for bots. The Crew documentation available on November 8 does not state the license of the open-source project, and Kiro has published no independent measurements of how reliably bots handle long unattended schedules.
For developers already using Kiro, the immediate effect is a way to turn recurring chores into named, limited agents without a new subscription. The deciding factor for most teams will be credit consumption, because the gap between $0.02 per included credit and $0.04 per extra credit makes the choice of worker model and schedule frequency the main lever on what a bot costs each month.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
