AWS launches agentic AI Kiro bots with memory and support for recurring development jobs

Amazon Web Services introduced Kiro bots on Thursday, adding persistent agents to its Kiro Crew development workspace that can oversee recurring responsibilities, coordinate other agents and remember the decisions developers make along the way.

The feature, now generally available, targets a problem that emerges when developers delegate several jobs to AI at once: Someone still has to check which agents have stalled, reconcile their results and explain the same requirements again when work resumes.

AWS proposes assigning that coordination to bots with distinct responsibilities. A developer could give one bot the job of monitoring failed builds, another responsibility for reviewing proposed code changes and a third the task of checking whether a release is ready. Each retains its own context and can direct multiple worker sessions.

For enterprise engineering leaders, the pitch extends beyond generating code faster. AWS wants bots to carry parts of the development process forward between human interventions. Whether that actually reduces management overhead will depend on how reliably they follow instructions, escalate decisions and keep their work within the permissions teams assign.

From individual prompts to ongoing responsibilities

Each Kiro bot has a name, a continuing conversation, its own notes and a dedicated workspace. Developers can return to that conversation to change direction or review findings without reopening every worker session individually.

According to AWS, a bot can launch several sessions, track their progress, correct deviations and consolidate the output. When one branch of work needs a human decision, it can request that decision while continuing other tasks that do not depend on the answer.

Developers can also describe schedules conversationally. A bot could investigate failures overnight or assemble a weekly summary of changes. Its activity log records routine work, while the conversation surfaces findings and questions that need attention.

AWS illustrates the feature with four possible assignments: categorizing incoming issues and identifying duplicates; checking build pipelines for new failures; reviewing proposed changes against earlier engineering decisions; and verifying tests and documentation before a release.

Those are examples of configurable workflows, rather than evidence that AWS has supplied four autonomous replacements for those engineering functions. Developers still define the job, provide access to the relevant systems and determine what completion means.

The bot can also maintain a customized dashboard. In an example accompanying the announcement, a GitHub monitoring bot groups issues by topic and displays changes in the backlog, giving developers a way to inspect the work without reading every underlying exchange.

Separate memory, permissions and models

AWS ties each bot’s memory to its particular assignment. Decisions about deployments can remain separate from the context a research bot accumulates, and users can inspect, revise or remove remembered information.

The announcement describes improvement through saved context, conversations and corrections. It does not establish that bots retrain their underlying models. The practical claim is that a developer should have to explain a recurring preference or constraint fewer times.

Permissions also vary by bot. AWS describes a research configuration that can inspect files without editing them and a deployment configuration that requests approval before making changes. Its example review bot can comment and request revisions but cannot approve or merge code. Users can subsequently adjust those boundaries.

That distinction matters: A bot’s assigned responsibility does not automatically confer unrestricted authority. AWS says adding tools requires user approval, and the developer decides how much initiative each bot can take.

Model selection introduces another control. The coordinating bot and its workers can use different models, allowing a team to reserve a more capable model for planning while assigning repetitive checks to a cheaper option. Kiro’s model catalog includes offerings from OpenAI and Anthropic, alongside open-weight alternatives; availability and credit charges vary by model.

Bots can run through Crew on a laptop, a Mac Mini or an Amazon EC2 instance, according to the announcement. That gives users flexibility over where the workspace operates, although running the software on their own hardware should not be confused with running every underlying model locally.

How Kiro compares with recurring agents from Cursor, Anthropic and OpenAI

AWS enters an established competition to automate work between user prompts. Scheduling, retained context and background execution already appear in rival products. The following comparison focuses on recurring development work and adjacent workflows, rather than treating every coding assistant as an equivalent offering.

Publicly listed U.S. dollar prices checked November 5, 2026. Monthly billing unless otherwise indicated. These are access prices and usage structures, not equivalent quantities of completed work.

Cursor provides an especially close comparison. Its automation memory survives individual runs and can be edited or deleted. Agents can create pull requests, interact with external tools and demonstrate their changes using screenshots or recordings. Persistent memory therefore does not, by itself, distinguish Kiro.

Anthropic’s scheduled tasks emphasize configuring repositories, connectors and triggers. They continue running without an open laptop when using hosted execution, although Anthropic still labels the capability a research preview. OpenAI distinguishes between desktop tasks that need an available local machine and web tasks that use uploaded context and connected services.

Kiro’s proposed advantage is the combination: a continuing conversation around a specific responsibility, its own memory and authority, and a coordinator that supervises workers and maintains a view of their progress. That is a product-design distinction, not evidence that it outperforms competitors at equivalent work.

The real cost depends on what the bots do

AWS’s pricing page says Kiro subscriptions cover Crew as well as the IDE, CLI and web product. The launch post does not announce a separate per-bot fee.

For teams of at least two, AWS lists pooled usage at $20 per seat per month, with each seat contributing 500 credits. That differs from the individual $20 Pro plan’s 1,000-credit allowance. Extra team credits cost $0.04 each.

A credit is not a completed task: consumption depends on complexity and model selection. Teams therefore cannot infer the monthly cost of a continuously scheduled bot from the subscription price alone.

The same comparison problem applies across vendors. More frequent checks, larger repositories and repeated attempts can change the economics of unattended work. Separating the coordinating model from worker models gives Kiro users a possible cost-control mechanism, but AWS does not provide a measured savings figure for that arrangement in the announcement.

What enterprise teams still need to establish

The launch post does not provide comparative benchmarks, quantified productivity results or a measured rate of mistakes for the new bots. It describes capabilities and suggested workflows, leaving prospective users to establish how much oversight their own deployments require.

A useful evaluation would measure time spent reviewing and correcting the bot alongside work completed, unexpected actions and model consumption. A system that catches more build failures but produces too many unnecessary escalations may simply move the workload elsewhere.

AWS’s own examples suggest a practical starting point: Assign a narrow recurring responsibility, constrain its authority and expand it only after reviewing the results. The immediate enterprise question is whether one bot can reliably own a small piece of the process. A larger crew becomes valuable only if adding bots reduces the coordination burden rather than multiplying it.