AWS Kiro bots launch as generally available persistent agents that keep their own memory, coordinate worker sessions and run recurring software-development tasks. Amazon Web Services introduced the feature inside Kiro Crew on November 5.

The release targets a weakness in session-based coding agents: parallel work still leaves a developer tracking stalled jobs, restoring context and reconciling results. Kiro gives each bot an ongoing responsibility rather than treating every assignment as a separate conversation.

The Kiro bots launch establishes four operating features:

• Separate memory, notes and workspaces for each bot.
• Worker sessions that report to one persistent conversation.
• Heartbeats and custom schedules for recurring work.
• Configurable models, tools and permission modes.

AWS Kiro Bots Replace Session Tracking With Persistent Ownership

A conventional coding agent usually starts with the context supplied to one session. A Kiro bot instead has a name, a goal and one continuing chat where a developer can change direction, review decisions and return for results without reconstructing the assignment.

According to AWS's launch announcement, every bot maintains its own notes and workspace. That separation is meant to prevent a deployment bot's operational lessons from mixing with the preferences accumulated by a research or issue-triage bot.

When a task becomes large, the bot can start several worker sessions, follow their progress, redirect work that drifts from the plan and combine the findings. A blocked worker can request a human decision while unrelated sessions continue.

The architecture separates ongoing ownership from execution. The bot preserves the goal and relationship with the developer, while workers handle individual investigations or changes. AWS suggests assignments such as deduplicating incoming issues, investigating failed builds, reviewing proposed code changes and checking release readiness.

Those examples are configurable workflows, not evidence that Kiro can independently perform every engineering role. Teams still define success, supply tool access and decide which findings or code changes require human approval.

Schedules and Workers Extend Kiro Beyond One Chat

Kiro's bot documentation describes three forms of proactive work: a heartbeat that reviews goals, custom schedules that run a defined prompt, and daily, weekly or monthly goal check-ins. Scheduled activity can continue after the chat is closed while the Kiro Crew gateway remains running.

Heartbeat intervals can be set to 30 minutes, one hour, two hours or four hours. A custom schedule can investigate a nightly build, while a weekly check-in can summarize completed work and milestones. Every model call, including worker and scheduled activity, consumes Kiro credits.

A bot and its workers share memory and a workspace, allowing a delegated session to use prior decisions and save new findings. Different bots remain isolated from one another, and users can inspect or remove the information stored in memory and notes.

That design could reduce repeated explanations in long-running projects, but it creates a new maintenance requirement. Saved context can become stale, and a recurring task can repeat a flawed assumption at scale. Teams will need review checkpoints for memory, schedules and worker output rather than treating persistence as automatic accuracy.

VentureBeat's independent report confirmed the general-availability launch and the division between coordinating bots and worker sessions. It also noted that the value will depend on how reliably bots follow instructions, escalate decisions and remain within assigned permissions.

Kiro Permission Modes and Pricing Define the Boundaries

Kiro offers Normal, Reads and Trust permission modes. Normal requests approval for actions outside specified built-in operations, Reads permits read access without approval but asks before other changes, and Trust acts without per-action approval while remaining subject to security policies and blocked-command rules.

New bots start in Trust unless they were imported by an app, according to the product documentation. A bot must present an approval card before changing its model, permissions, goals, milestones, check-in schedules or worker abilities through conversation.

Memory isolation is not a filesystem security boundary. File and tool access still depends on the bot's configured permissions and the surrounding policy. AWS's examples include a research bot that can search and read without editing, and a deployment bot that requests approval before changes.

The current Kiro plans include a free tier with 50 credits and a Pro tier at $20 per user per month with 1,000 credits. Paid customers can buy additional credits at $0.04 each, while model availability and pricing can vary by region.

Kiro Crew can run on a developer's machine or a remote host, but that does not mean every selected model runs locally. Teams evaluating the bots should separate the location of the Crew gateway and workspace from the infrastructure serving the underlying model.

The launch shifts the competitive question for coding agents from completing a single prompt to sustaining responsibility over time. The decisive evidence will be operational: fewer repeated instructions, faster recovery from failed work, accurate escalation and a permission record that makes autonomous actions reviewable.

Photo: the Amazon Web Services office at CityCentre Five in Houston, photographed by Tony Webster, via Wikimedia Commons. Licensed under CC BY 2.0. Cropped and resized to 16:9; the image does not show the Kiro interface or the November 5 launch.

More on This Story

• Meta Launches Muse AI Agent With Secure VM and Connected-App Actions
• CrowdStrike AI Kill Switch Launches in Falcon Guardian