AWS Kiro, the cloud giant's AI-oriented integrated development environment, isn't the most popular code editor. That honor goes to Microsoft's Visual Studio Code, at least as measured by Stack Overflow's 2026 Developer Survey. Kiro might rank 27th among the listed IDEs, but then it's not really an IDE anymore. Having shrugged off reports that it played a role in outages last year, Kiro now styles itself "an agentic development environment" after a brief stint as "an agentic IDE." It's also the inheritor of Amazon Q Developer coding assistant users, who have been directed to migrate to Kiro. It's also "an AI-powered development environment that helps you build software from prototype to production." It's "available as a desktop IDE, a command-line interface, a web app, a mobile app, and a personal AI agent (Crew)." Except that Kiro Crew is also "the persistent, open source development workspace." It's more agent infrastructure – an environment – that supports Kiro Web, IDE, and CLI. To help get Kiro through its identity crisis and perhaps make it more beloved, AWS is expanding Kiro's remit still further. The cloud giant is launching Kiro Crew bots, recalling similar efforts like OpenAI dots and Grok Bot, as well as Claude Duet and Meta Muse. Bots in Kiro Crew are software agents that attempt to carry out long-running tasks. "A bot is a new way to structure and drive agentic work," a Kiro blog post explains. "Instead of working in isolated sessions, each bot is a named, long-running agent that you define and customize for a specific part of your work. It has its own memory and runs its own sessions so you stop tracking them one by one. Kiro Crew already learns from how you work. Bots change where that learning lives." There's some appealing anthropomorphism to giving each agent a name and its own tools, permissions, and memories. You're suddenly surrounded by friends. The possible downside is how that gets billed – there's potential for a lot of duplicated context if your many agents process overlapping data without some form of shared cache. Given Amazon's concerns about internal token usage and developer complaints about runaway costs in Kiro, it seems other organizations might be curious about the potential expense of keeping bot memory isolated. In response to our inquiry about the cost of keeping memory separate, an AWS spokesperson said, “All of the Kiro bots bill together through a developer’s existing Kiro plan. Each bot in Kiro Crew has its own memory and sessions, and their learned context is intentionally kept separate so that what one bot learns doesn’t bleed into another’s work. However, all bots operate within the same Kiro Crew workspace, use the same harness, and have access to the same codebase, project files, MCP, skills, and tools—so they don’t need to independently rediscover your project structure.” In any event, figuring out how Kiro Crew agents are spending tokens looks likely to require analytics of some sort, because AWS Kiro subscriptions are sold as "credits" that get converted to tokens at different rates, depending on the underlying model. As a thought experiment, AWS suggests a developer might deploy an intake bot for reading trouble or job tickets, labeling them, flagging duplicates, and drafting reproduction steps for bugs. Then there might be the build-health bot for checking the CI pipeline periodically and surfacing test failures that require the attention made scarce by having to deal with a bunch of AI agents. A code review bot might also be warranted for reviewing pull requests and other delegated responsibilities. And top that off with a release-readiness bot, for confirming that merged changes have tests and for seeking release sign-off. For those smitten by the idea of a single surface through which multiple agents can be configured, routed, and governed, Kiro Crew has your backend. ®