En julio de 2025, AWS presentó Kiro, un entorno para el desarrollo de agentes de inteligencia artificial basado en especificaciones. Pocos meses después, en agosto de este año, lanzó Kiro Crew, un espacio de trabajo open source capaz de memorizar el contexto de las sesiones para continuar tareas sin perder información previa. Ahora, para facilitar la gestión de trabajos complejos ejecutados en paralelo, AWS ha presentado Kiro bots, que incorporan memoria persistente en cada agente y la capacidad de delegar la gestión de flujos de trabajo.
Estos bots son descritos como agentes identificados y personalizables, diseñados para encargarse de una parte concreta del trabajo, como por ejemplo, revisar nuevas incidencias en una cola de tickets. Cada bot conserva su propia memoria y dispone únicamente de las herramientas que se le proporcionan al ser creado, lo que limita su campo de acción a responsabilidades específicas y bien definidas.
Además, cada bot puede iniciar y supervisar sesiones de trabajo paralelas, aliviando a los ingenieros de software de la necesidad de seguir manualmente cada proceso o combinarlos. Según AWS, la llegada de Kiro bots marca una transición importante: se pasa de delegar tareas a delegar procesos completos. 
De cuidar a los agentes a construir bots que trabajan de forma autónoma
Kathy Kam, directora de ingeniería de AI Agentic en AWS, explica que la utilidad real de los agentes se da cuando los desarrolladores pueden confiar en que estos actúen independientemente. Sin embargo, el fin de una sesión a menudo dejaba el trabajo sin propietario, obligando a los desarrolladores a trasladar el contexto de un momento a otro, lo que designa una labor tediosa que AWS busca eliminar con esta innovación.
“Los desarrolladores ahora pueden dedicar el tiempo a decidir qué merece la pena construir en lugar de estar pendientes constantemente de las sesiones”, señala Kam. La ausencia de una memoria duradera generaba el problema conocido como «degradación de contexto», que obliga a los agentes a repetir instrucciones y provoca inconsistencias cuando se ejecutan tareas paralelas de forma simultánea.
Para combatirlo, cada Kiro bot cuenta con una memoria propia y durable, estructurada en un archivo de notas editable directamente por el desarrollador. Así, si se corrige un error, la solución permanece fija y no reaparece en el resto de tareas en curso.
El diseño restringe además las capacidades de cada bot para que actúe solo según las herramientas y permisos asignados desde el principio. Por ejemplo, un bot de investigación puede buscar en la web o consultar documentos, pero no modificar archivos; mientras que un bot de despliegue tiene permiso para ejecutar scripts y solicita aprobación humana para cada cambio. Los bots pueden pedir la ampliación de sus permisos, pero nada cambia hasta que un desarrollador lo valide.
La confianza se construye con resultados y límites claros
Lejos de una jerarquía entre bots basada en inteligencia o personalidad, Kam aclara que el nivel de confianza se otorga en función de lo que cada agente está autorizado a hacer y de su historial de ejecución. Cada bot tiene nombre, avatar, memoria propia y un canal de chat mediante el cual el desarrollador establece sus directrices y consulta avances.
Esta interfaz permite a los bots lanzar y administrar sesiones paralelas, reorientar aquellas que se desvían de los objetivos y consolidar los resultados. Ante decisiones que requieren intervención humana, el bot puede solicitar aprobación mientras continúa con tareas independientes.
Así, por ejemplo, un bot puede investigar fallos en la compilación durante la noche, para que el equipo de desarrollo encuentre los problemas ya detectados al comenzar su jornada.
El papel insustituible del desarrollador ante la autonomía de los bots
Surgen preguntas sobre qué ocurre si un bot necesita esperar una decisión humana, pero cuenta con suficiente contexto para actuar. Kam responde que, aunque los bots pueden acumular más conocimiento colectivo que individuos aislados, el control y la responsabilidad final siempre recaen en los desarrolladores. Estos definen los permisos que cada bot tiene y las fronteras de su autonomía.
“Un bot puede solicitar más autoridad, pero nunca tomarla sin autorización. Mientras espera respuesta, continúa ejecutando tareas que no requieren supervisión”, añade Kam.
Especialización y límites claros para cada Kiro bot
Según el blog oficial de lanzamiento, la interacción con cada bot es dinámica y visible, permitiendo revisiones y ajustes constantes mediante diálogo. Kiro Crew almacena el aprendizaje dentro de cada bot, facilitando que puedan asumir responsabilidades continuas y no tareas aisladas.
Cada bot comprende su objetivo, las razones detrás de decisiones, las limitaciones aplicables y las elecciones previas. Así, un bot puede gestionar la recepción de incidencias, mientras otro se encarga de la preparación para lanzamientos, siguiendo las reglas específicas asignadas para esa labor.
AWS señala que la «tripulación de bots» creada por un desarrollador es una extensión de su estilo y necesidades particulares, sin forzar un flujo de trabajo estándar único.
Un aspecto clave es que los bots no pueden delegar tareas entre sí, una medida intencionada para evitar la pérdida de contexto y preservar la independencia de cada agente. Las divisiones internas de trabajo se manejan dentro de cada bot, cuyos límites y conexiones son siempre definidos por el usuario.
Con el tiempo, este sistema refleja eficazmente el modo real de desarrollo del programador, ya que cada agente mantiene de forma autónoma los requisitos y restricciones de su labor. El ingeniero es quien mantiene el control sobre la evolución de los procesos y dónde se exige juicio humano.
Primeros pasos con Kiro bots
Para iniciarse, AWS anima a los desarrolladores a acceder al espacio de bots en la barra lateral de Kiro Crew, seleccionar añadir un bot y elegir un agente por defecto o uno personalizado como base. El agente personalizado permite configurar el prompt, modelo, herramientas y habilidades, facilitando ampliar configuraciones previas sin alterar interacciones en curso.
En definitiva, AWS no busca que los desarrolladores abandonen el control, sino que gestionen la conducción desde una posición menos centrada en la supervisión directa y más en la toma estratégica de decisiones mientras la IA avanza con autonomía en la ejecución.
