Developers were promised that AI agents would take work off their plates, but for many, running a handful of agents in parallel has become its own job: checking which sessions finished, which stalled, and which quietly went off course. Amazon Web Services thinks the answer is to give each agent a specialty. Bots, a new feature now generally available in Kiro Crew, let developers create long-running agents that each own one part of their work, remember what they’ve learned, and manage their own sessions so the developer doesn’t have to.
“Each bot is a kind of tuned agent with the right set of skills, tools, and memory, so that it can do the job the best versus a generalized agent that has to sort through the assortment of tools to figure out what tools to use and what needs to be done,” said Kathy Kam, AWS’ director of engineering for agentic AI, in an interview with The AI Economy.
Bots are AWS’ latest push to further automate software development, building on Kiro Crew, the autonomous agentic orchestrator that launched in August. That initiative started as an internal side project called MeshClaw, created by three Amazon engineers who wanted developers to be able to “kick off a task, walk away, come back to something worth reviewing,” and run several tasks simultaneously without babysitting each one. Sound familiar?
Within six months, Kam noted, the internal tool that became Kiro Crew had drawn 39,000 Amazon builders and nearly 500 contributors. Bots grew out of how those builders were already using the tool. “I like to say developers are very lazy,” Kam explained. “We want to do the least work to get our job done.” Once engineers settled on Kiro Crew as the shortest path to getting work done, they looked for the shortest path inside it, and specialized agents kept coming out on top. Kam saw her role as recognizing the pattern and turning it into a product. “The developers have spoken,” she said. “This is the way.”
But where Kiro Crew handles whatever tasks developers hand it, each bot owns a single responsibility the developer defines. Developers build their own to fit how they work, assigning each one a name, an avatar, and a set of instructions. When the bot runs, it keeps notes on its decisions and open items, and everything it owns lives in a workspace inside Kiro Crew.
What goes into making an ideal bot? “A bot is a clear job to be done, work you can dive into, and you want the agent to grow in its learning because it has its own memory,” Kam replied. “It has its own git tree. It’s a self-contained worker for you that can learn and grow, and as you coach it to do better, it grows with your project.”
AWS provides developers with more concrete instructions in a blog post: Start by breaking workflows into recurring responsibilities and picking a single process they can clearly describe and judge. A bot makes sense in places where work changes purpose or calls for different tools, permissions, or oversight. From there, developers decide how tasks reach the bot, the sources it draws on, what a finished handoff should look like, and when it should stop and ask for input. AWS suggests starting with tight limits and loosening them as the bot proves itself.
To kickstart development, AWS detailed examples of four possible bots, all with different tool access, permissions, and definitions of when work is complete. Each exists in its own universe, so a change to one bot shouldn’t affect the others.
- An intake bot scans new issues in a ticket queue, labels them, and flags likely duplicates. When it spots a bug, it’ll draft steps to reproduce the problem. The bot can comment on tickets, but cannot close them.
- A build-health bot checks the CI pipeline, the automated system that tests every code change, every 30 minutes. It separates new failures from the flaky tests a team already knows about, surfacing only what needs a developer’s attention.
- A code review bot checks new pull requests against decisions a developer has already made, such as a preferred error-handling pattern or a dependency they ruled out. It can leave comments and request changes, but cannot approve or merge code.
- A release-readiness bot handles the pre-release checklist. It confirms merged changes have tests and release notes before asking the developer to sign off.
Bots also help AWS make the case for Kiro as what Kam calls an “anti-slop tool.” Developers have no shortage of AI-powered coding options, from agents like GitHub Copilot, Claude Code, Codex, and Devin to app builders like v0, Lovable, and Google AI Studio. Kiro’s pitch is that developers should slow down before they build. It starts with a specification and turns it into features, tests, documentation, and workflows, rather than going straight from a prompt to code. Bots apply the same discipline to the agents themselves. Before a bot does any work, the developer has to define its job, what it can touch, and when it must stop and ask for approval.
Kam sees bots as a teaching tool for students, too, an audience AWS has aggressively courted this year, giving free Kiro access to students at 132 universities worldwide. Putting bots in front of students, she argued, is “in many ways training them on what best practices they might not know today.” A student might see one agent generate code while another reviews it, the same division of labor professionals use to build systems that scale. “We want to build production software,” Kam explained, “and we want to train the next kind of cohort of developers [on] best practices.”
Notably, AWS went back and forth on what to call the feature, toying with “crewmates” and “jams” before landing on bots. An AWS spokesperson said the name “better describes the long-running and durable benefits of the tool.”
Branding challenges aside, when asked what she wants developers to take away, Kam said it comes down to a feeling. “I want to use the word relieved,” she explained, describing the confidence that an agent will get the job done because it has “the right tools, not more, the right context, and the right memory.” It’s a candid acknowledgment that developers still don’t fully trust their agents. AWS is betting that the way to earn that trust is to give each agent less to do and make its work easy to check.
Developers can start by opening the bots workspace in the Kiro Crew sidebar and adding a bot built on either the default agent or a custom one. A custom agent brings its own prompt, model, tools, and skills, so developers can build on a setup they already use without disrupting existing chats.
Discover more from Ken Yeung
Subscribe to get the latest posts sent to your email.
