- AWS made Kiro bots generally available in Kiro Crew. Each bot supervises parallel coding agents and keeps its own persistent notes.
- Analysts quoted by InfoWorld name three costs: a 'coordination tax' on compute, harder-to-trace decisions, and permission creep.
- Leaders should pilot one bounded process, measure review time and running cost, and govern each bot like a contractor.
When the developer becomes a dispatcher
Running several AI agents at once sounds like extra capacity. In practice, someone has to watch them. HyperFrame Research's Stephanie Walter, who leads its AI stack practice, says the developer can become a "dispatcher." That person checks progress, restores lost context and decides what comes next.
AWS is now offering a way to automate that job. It released Kiro bots to the public last Thursday, InfoWorld reported. They run inside Kiro Crew, AWS's open-source environment for working with several coding agents.
AWS says the bots address a "growing coordination burden" for developers who run many agents at once. Analysts told InfoWorld the bots could reduce that burden. The idea is to put software in the dispatcher's chair. If it works, the dispatcher can stop being the bottleneck. It is too early to say whether it does.
What a Kiro bot does
AWS says a developer creates a bot from the Customize section of Kiro Crew. The bot starts from a default or custom agent. The developer then gives it one job and a name, instructions, tools and permissions.
AWS's examples of a job are sorting new issues, watching builds or checking that a release is ready.
A bot can start several worker-agent sessions at once. It tracks their progress, steers back any that stray from the plan, and gathers their results. When a task needs a human decision, the bot asks for approval. Meanwhile it carries on with tasks that do not depend on the answer.
The notebook is the real change
Each bot also keeps persistent memory, which AWS calls Notes. Notes hold what the bot has picked up about a project. That includes developer preferences, past decisions, requirements and constraints. AWS says this spares developers from repeating their expectations.
Memory also lets a bot own recurring work. A developer can ask a bot to look into overnight build failures every weekday morning. Or the bot can draft release notes on a chosen day. AWS says developers can inspect, edit or delete the Notes.
Think of a new hire who keeps a notebook that shapes how they work. The manager can open it, but has to choose to.
This is where behaviour becomes path-dependent. A single agent session starts fresh each time. A bot with Notes does not. What it does today depends on the corrections and decisions its Notes have accumulated. Two bots given the same instructions can drift apart, because they took different paths. That is the author's reading of the design, and it matches the traceability concern Chaturvedi raises below.
Three costs analysts put on the table
InfoWorld's analysts did not simply praise the product. Dave McCarthy is a group vice president at IDC. He calls the first cost a "coordination tax." Background retries and tool calls by parallel workers can quickly compound token use and compute spend, he said.
That cost comes from the supervision itself. Each retry and tool call consumes tokens and compute. A supervising bot that runs many workers multiplies them.
The second cost is traceability. Ashish Chaturvedi of HFS Research said it could get harder to explain a bot's decision as its behaviour changes over weeks of feedback. Developers can still open the Notes and review work logs, he noted, so the record exists. The difficulty is reading it. He also said different developers could end up with bots that act differently, based on the corrections each has given.
The third is permission creep. Chaturvedi warned that bots may keep asking for more tool access. Developers could grow used to saying yes without rechecking how much authority the agent now holds.
Read together, these risks look less like bugs than side effects of the design: a worker that learns, asks and accumulates. That is WebPulse's reading, not the analysts' claim. It is also why the questions below centre on who owns the record.
What leaders should ask
Walter advises starting with one bounded process and measuring the full result. She lists three measures: correct work, time spent on developer review, and running cost. "More activity in the background is not, by itself, higher productivity," she said.
She also suggests asking whether each recurring task needs an agent at all. Agents help most when a task needs investigation or interpretation. Ordinary automation may be "simpler, cheaper, and easier to verify" elsewhere.
McCarthy says to govern bots as human contractors. That means strict identity scopes, budget guardrails and central telemetry.
Because a bot's behaviour depends on its history, the questions below are about that history. Put them to the team before a pilot:
Who reviews each bot's Notes, and how often? When two bots behave differently, can we tell which corrections explain it? Which tools can a bot request, and who signs off on each addition? What is the spending cap per bot? Can we reconstruct why a bot acted, three weeks later?
WebPulse's argument is simple. A bot that remembers may be more useful, but it leaves a record someone must own.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: InfoWorld.
