AWS adds persistent AI bots for recurring development tasks

Bots for recurring tasks

Each bot has a name, a separate conversation, notes and a workspace. Developers can return to that conversation to change the task or review results without opening each worker session one by one.

According to AWS, a bot can start multiple sessions, monitor their progress, correct deviations and gather results. If one part of the work needs a person’s decision, the bot can ask for it and continue in parallel with other tasks that do not depend on that decision.

Schedules can be set in plain text: for example, a bot can be asked to investigate failures overnight or prepare a weekly report on changes. A log records recurring work, while the conversation shows results and questions that need attention.

AWS lists four possible tasks:

These are configurable workflows, not ready-made autonomous replacements for engineers. Developers define the task, provide access to the necessary systems and set completion criteria.

A bot can also maintain a configurable dashboard. In AWS’s example, a bot monitoring GitHub groups issues by topic and shows changes in the task queue. This lets teams review results without reading the full interaction log.

Memory, access and model selection

A bot’s memory is tied to its task. Deployment decisions can be stored separately from the context accumulated by a research bot. Users can review, edit and delete saved information.

AWS describes better performance through context, conversations and corrections. However, the company does not claim that bots retrain the models they use. The practical benefit of retaining information is that developers have to explain recurring requirements and preferences again less often.

Permissions can be configured separately for each bot. A research bot, for example, can view files but not edit them. A deployment bot can ask for permission before making changes. A code review bot can leave comments and request revisions, but cannot approve or merge changes. These limits can be changed.

According to AWS, connecting tools requires user approval. Developers decide how independently a bot can act; assigning it a task does not give it unlimited permissions.

A coordinating bot and its workers can use different models. For example, a more capable model can be selected for planning, and a less expensive one for repeated checks. Kiro’s catalog includes models from OpenAI and Anthropic, as well as open-weight models; availability and credit usage depend on the model selected.

Bots can run through Crew on a laptop, Mac Mini or Amazon EC2 instance. This lets teams choose where the Kiro environment runs, but running it on their own hardware does not mean that all the models it uses also run locally.

Comparing Kiro with Cursor, Anthropic and OpenAI

AWS is entering a market for tools that do work between user requests. Scheduling, retaining context and running tasks in the background are already available in competitors’ products. The comparison below covers recurring development tasks and related workflows, not every coding assistant at once.

The prices below, in US dollars, were checked on November 5, 2026. Unless stated otherwise, they are monthly prices. Prices and usage models provide access to services but do not guarantee the same volume of completed work.

Kiro. The free plan includes 50 credits. Pro costs $20 per month and includes 1,000 credits. Higher-tier individual plans cost $40, $100 and $200. Additional credits cost $0.04 each. Named bots manage parallel workers, schedules, notes and dashboards. Crew runs on a personal computer or in EC2. Different models from different providers can be selected for coordinating and carrying out tasks. Each bot has its own memory and permissions.

Cursor. Plans with advanced capabilities start at $30 per month and include Automations; usage limits apply. Third-party models are billed separately through prepaid credits calculated at API rates. Earlier plans retain different terms. Automations runs agents on a schedule or in response to supported events. They can retain notes, change and check code, and interact with a computer. Models from OpenAI, Anthropic and Google are available, and a model can be selected for automation. Workflows combine integrations, memory between runs and demos of changes created on a computer.

Anthropic. Claude Pro costs $20 per month; runs use the subscription’s included allowance. Pay-as-you-go credits are available for eligible accounts. Scheduled tasks, previously called routines, support schedules, API calls and GitHub events. They can run on Anthropic’s infrastructure or an organization’s infrastructure; the feature is still in research preview. Users can select an available Claude model and an effort level. Selecting models from different providers for this feature is not listed as an option. Configuration is built around a repository and connected services; one task can combine several trigger types.

OpenAI. Plus costs $20 per month, while Pro starts at $100; usage limits apply, and in eligible cases the limit can be raised with credits. Scheduled tasks work with local projects through the desktop app, or with web workflows and connected tools. Event-based runs depend on the plan and product. Users can select an OpenAI model, but the option to connect models from other providers for scheduled tasks is not listed. Local tasks are isolated in Git worktrees, while web tasks can continue in an existing conversation and use its context.

Cursor is especially close to Kiro in how its automations work. Its memory persists between runs and can be edited or deleted. Agents can create pull requests, work with external tools and show changes through screenshots or recordings. Persistent memory alone, then, does not distinguish Kiro from Cursor.

Anthropic’s scheduled tasks are built around configuring repositories, connected services and trigger events. When run on Anthropic’s infrastructure, they can continue without a laptop being on, though the feature is still in research preview. OpenAI distinguishes between tasks in the desktop app, which need an available local machine, and web tasks with loaded context and connected services.

Kiro’s distinguishing feature is that it combines a persistent conversation around a specific responsibility, memory and permissions for each bot, and the coordination and tracking of workers. This is a difference in product design, not proof that Kiro handles the same tasks better.

What recurring tasks cost

According to AWS’s pricing page, Kiro subscriptions include Crew, the development environment, the command-line interface and the web product. The launch announcement does not list a separate fee for each bot.

For teams of two or more, AWS offers a shared usage pool at $20 per seat per month, with each seat adding 500 credits. This differs from the individual Pro plan at $20, which includes 1,000 credits. Additional team credits also cost $0.04 each.

A credit is not the same as a completed task: usage depends on the task’s complexity and the model selected. So the subscription price alone cannot show in advance how much a bot running regularly on a schedule will cost.

Costs are also difficult to compare across services. Frequent checks, large repositories and retries all change the cost of background work. Using different models for planning and execution could help control costs in Kiro, but AWS provides no measurements of the savings from this approach in its announcement.

What teams still need to test

AWS has not published comparative benchmarks, quantitative estimates of the bots’ effect on productivity or error rates. The announcement describes capabilities and possible workflows, but teams will have to find out for themselves how much oversight their projects require.

Evaluation should account not only for the work completed, but also for the time spent checking and correcting results, unexpected actions and model usage. If a bot finds more build errors but too often asks for unnecessary intervention, the workload may simply shift to another part of the process.

AWS’s examples point to a cautious way to introduce bots: assign one a narrow recurring task, limit its permissions and expand them after checking the results. The first step is to find out whether a single bot can reliably handle a small part of the process. Additional bots will help if they reduce coordination costs rather than increase them.

Dataist's take: Kiro offers teams a way to delegate recurring tasks to bots while keeping memory and permissions separate for each role. But descriptions of its capabilities are not enough to assess reliability or actual time savings: AWS provides no such measurements. Costs also depend on run frequency, task complexity and the models selected.