Lo que Kiro anunció
V3 no es nuevo. La publicación del blog de Kiro dice: "Presentamos V3 como una experiencia opcional en junio", y que la empresa ahora se está "preparando para hacer de V3 el valor por defecto para todos". El aviso comenzó el 12 de octubre, "antes del lanzamiento de la CLI 3.0 a finales de octubre". La publicación añade que "esta implementación se aplica solo a Kiro CLI".
El aviso ofrece tres opciones:
- Switch to V3 and upgrade my configs: "Guarda V3 como tu entorno por defecto, habilita las actualizaciones automáticas de agentes y comienza a migrar tu espacio de trabajo y las configuraciones globales de agentes personalizados".
- Remind me later: la documentación dice que esto "Mantiene esta sesión en V2 y vuelve a mostrar la oferta en unos siete días".
- Don't ask again: el blog es explícito en que esta opción no te excluye. "No te mantendrá en V2 y tu configuración se actualizará a V3 cuando se lance la CLI 3.0 a finales de octubre".
Puedes volver a cambiar para un solo inicio con la bandera V2, pero "La bandera se aplica solo a ese inicio".
CLI 3.0 también retira algunas cosas. "Con la CLI 3.0, retiramos el autocompletado de shell en línea y la aplicación de escritorio de la CLI. También retiramos la experiencia Classic y enfocamos las nuevas capacidades en la interfaz de usuario de la terminal". La documentación enumera una diferencia más que vale la pena conocer: "La función experimental /checkpoint sigue siendo exclusiva de Classic; V3 proporciona /rewind para ramificaciones de conversación".
¿Qué pasa con tus sesiones de V2?
Kiro CLI guarda cada sesión automáticamente. La documentación de sus sesiones dice que "guarda automáticamente todas las sesiones de chat en cada turno de conversación", y las sesiones se almacenan por directorio, por lo que cada proyecto tiene su propio historial.
V3 guarda las sesiones en un lugar diferente. La guía de migración es directa: "V3 utiliza un almacenamiento de sesiones diferente al de V2. Las sesiones de V2 existentes no se convierten ni se eliminan cuando pruebas V3". Te indica cómo volver a ellas: ejecuta el comando de chat con la bandera V2 y el selector de reanudación "cuando necesites volver a una sesión de V2".
La otra dirección está cerrada. La descripción general de V3 dice: "V2 no puede abrir una sesión de V3 porque los formatos de sesión almacenados difieren; ese es un límite de migración entre versiones, no una falta de capacidad de reanudación en V3". Su tabla de cambios importantes marca el cambio de formato de sesión como de alto impacto.
Aquí es donde difieren las fuentes de Kiro. La publicación del blog de lanzamiento dice: "Puedes reanudar tus sesiones de V2 en V3, pero no puedes reanudar sesiones creadas en V3 en V2". La guía de migración describe las sesiones de V2 como no convertidas y te remite a la bandera V2 para volver a ellas. Ambas coinciden en que las sesiones de V3 no pueden volver a V2. Describen la dirección de V2 a V3 de manera diferente.
Esto no está necesariamente en conflicto. El panel de sesiones, que es exclusivo de V3, puede buscar trabajos antiguos: "Las consultas de tres o más caracteres también buscan contenido de sesiones indexadas de transcripciones locales de V2 y V3". Encontrar una sesión de V2 desde V3 y continuarla en V3 puede no ser lo mismo, y la documentación no dice a cuál se refería el blog. La lectura segura es la de la guía de migración: las sesiones de V2 se quedan donde están, legibles a través de V2, y no deberías contar con continuarlas en V3 hasta que lo hayas probado con una que sea importante.
Para conversaciones que no puedes permitirte perder, la guía de migración ofrece un consejo específico: "Si necesitas un registro externo de una conversación importante, ábrela con el entorno que la creó y ejecuta /chat save <ruta>. Trata el archivo exportado como un archivo de respaldo a menos que hayas verificado que el entorno de destino puede cargarlo".
Las palabras a tener en cuenta son "como un archivo de respaldo". Una sesión exportada conserva lo que se dijo. No vuelve a colocar ese contexto frente al agente por sí sola.
¿De qué aprende la nueva memoria?
V3 añade memoria a la CLI. La página de memoria de Kiro lo describe claramente: "La memoria permite a Kiro llevar un contexto útil de una sesión de chat a la siguiente". Puede recordar "comandos y convenciones del repositorio, correcciones, ideas de depuración, enfoques ya descartados y cómo prefieres trabajar".
Dos condiciones determinan de qué aprende.
Necesita V3. "La memoria en Kiro CLI requiere V3". La publicación de lanzamiento la describe como un aprendizaje "a partir de tu trabajo en sesiones locales de V3". Nada en la documentación describe que aprenda de las sesiones de V2, por lo que lo que le enseñaste a Kiro allí se queda en esas sesiones a menos que lo traigas tú mismo.
Necesita permiso. Eliges un nivel de acceso con el comando de memorias: lectura y escritura, solo lectura o desactivado. Solo la lectura y escritura permite a Kiro cambiar algo, y "Los cambios en el acceso a la memoria se aplican al iniciar una nueva sesión de Kiro CLI". También hay una opción para actualizaciones automáticas, cuyo texto de ayuda dice: "Crear y perfeccionar memorias automáticamente, incluso después de que finalice una sesión". La confianza del espacio de trabajo añade un límite: "Incluso con read & write, Kiro no puede añadir, cambiar ni eliminar memorias en un espacio de trabajo en el que no hayas confiado. Aún así puede leerlas".
Puedes revisar lo que contiene. La lista de memorias muestra el tipo, el alcance y la hora de actualización de cada memoria, pero "La lista es de solo lectura. Para corregir o eliminar una memoria, pregúntale a Kiro en el chat".
La memoria no está pensada para reemplazar tus reglas. La documentación dice: "La memoria añade contexto aprendido; no reemplaza tu conversación actual, Steering ni el material de referencia", y da una instrucción clara: "Si una regla debe aplicarse de manera consistente, escríbela en Steering".
Un límite más: la memoria es una función de CLI y Web por ahora. Para el IDE, la página de memoria de Kiro dice: "Soporte de memoria próximamente".
¿Qué más cambia en el contexto que carga Kiro?
Las sesiones y la memoria son los cambios visibles. Algunos cambios más silenciosos modifican lo que el agente ve al inicio de una sesión.
Los modos de inclusión de Steering ahora se aplican por completo. La página de steering de Kiro dice: "Kiro CLI V3 admite los cuatro modos de inclusión: always, fileMatch, manual y auto. En V1/V2, los archivos marcados como always se cargan automáticamente. Los archivos marcados como fileMatch o manual se excluyen de la carga automática". Después del cambio, un archivo de steering que hayas limitado a ciertas rutas comenzará a cargarse cuando trabajes en esas rutas, y los archivos marcados como auto se cargarán cuando tu solicitud coincida con su descripción. Las versiones anteriores de esta página describían los modos de inclusión de la CLI de manera diferente, y nuestra guía anterior sobre cómo dividir archivos de steering entre el IDE y la CLI se escribió basándose en esa versión. Comprueba el front matter de tu steering con respecto al comportamiento actual.
AGENTS.md llega más profundo. La publicación de lanzamiento señala que puedes "colocar archivos AGENTS.md en subdirectorios, no solo en la raíz del repositorio", y la página de steering confirma que se "descubren en subdirectorios en todo tu espacio de trabajo". Los archivos AGENTS.md no admiten modos de inclusión; siempre se incluyen.
Los agentes personalizados conservan sus campos de contexto. La documentación de actualización dice: "Todos los demás campos (name, description, model, prompt, resources, mcpServers, welcomeMessage) se transfieren sin cambios". Los documentos de steering de Kiro añaden un punto relacionado: "Al usar agentes personalizados, los archivos de steering no se incluyen automáticamente. Debes añadirlos explícitamente a la configuración de resources del agente para cargar el contexto de steering". Esa regla sigue aplicándose después de la actualización.
Algunos hooks no se transfieren. El blog dice: "Los hooks que no se puedan convertir se omiten de la configuración de V3 y se informan como advertencias". La página de migración de hooks dice que el convertidor "descarta un Hook que V3 no puede representar e informa una advertencia en lugar de escribir un perfil no válido". Si utilizaste un hook al inicio del agente para inyectar contexto del proyecto, comprueba que se haya transferido como un hook SessionStart. Un hook de contexto descartado no impide que Kiro funcione. Simplemente el contexto no está allí.
Las ediciones manuales se pueden sobrescribir. Esto es lo que más probablemente sorprenda a los usuarios cuidadosos. "Si editas a mano los campos generados de V3, Kiro deja de actualizarlos automáticamente". El agente aparece entonces como desincronizado, y "Al seleccionar ese grupo se reconstruye V3 a partir de la configuración de V2 y se sobrescriben tus ediciones manuales de V3". Kiro guarda una copia de seguridad cuando lo hace, pero vale la pena saberlo antes de empezar a realizar ajustes.
Lo que la gente asume erróneamente
Asumir que Don't ask again te mantiene en V2. Solo detiene el aviso. CLI 3.0 actualizará tu configuración de todos modos.
Asumir que V3 comienza donde lo dejó V2. Las nuevas sesiones comienzan a partir de tu steering, archivos AGENTS.md y cualquier memoria que V3 haya aprendido, la cual comienza con tu trabajo en V3.
Asumir que una sesión exportada restaura el contexto. Kiro lo llama un archivo de respaldo a menos que hayas verificado que el destino puede cargarlo.
Asumir que la memoria reemplaza a steering. Kiro dice que las reglas que deben aplicarse de manera consistente pertenecen a steering.
Asumir que la actualización transfiere todos los hooks. Los hooks que no se pueden convertir se omiten con una advertencia.
La solución: guarda lo que importa de V2, actualiza teniendo en cuenta las advertencias y luego decide qué debe aprender la memoria
Paso 1: Cierra las sesiones de V2 de las que aún dependas
Enumera tus sesiones recientes de V2 por proyecto y elige aquellas con trabajo inacabado o decisiones que te costaría reconstruir. Termínalas en V2 si puedes. Para el resto, guarda una copia externa con el comando chat save de V2, como sugiere la guía de migración, y conserva una copia de tu directorio de inicio de Kiro antes de cambiar. La página de permisos de Kiro indica ~/.kiro/sessions/ como el almacenamiento de sesiones por defecto y ~/.kiro/memories/ como la base de datos de memoria.
Luego, extrae las conclusiones de esas sesiones: las decisiones, los enfoques que descartaste, las convenciones que acordaste. Esa es la parte que la documentación de Kiro no describe que la memoria de V3 recupere de V2.
Paso 2: Actualiza tus agentes con una simulación y luego lee cada advertencia
Si tu equipo guarda los agentes en un repositorio, primero obtén una vista previa de la actualización del directorio. La publicación de Kiro dice que lo ejecutes con la opción dry-run, y la página de actualización dice que una simulación "informa lo que cambiaría e incluye advertencias de conversión". Luego ejecuta la actualización, que realiza una copia de seguridad de cada archivo, y abre los diagnósticos.
Busca específicamente hooks que se hayan descartado y entradas de resources que apunten a archivos de steering o de conocimiento. Comprueba los modos de inclusión de tus archivos de steering, ya que los archivos fileMatch y auto comienzan a comportarse de manera diferente en V3. Evita editar a mano los campos generados hasta que comprendas la reconstrucción por desincronización. Para obtener una visión más amplia de qué archivos leen los agentes de programación al inicio, consulta nuestra guía sobre lo que realmente leen los agentes de programación.
Paso 3: Activa la memoria deliberadamente y mantén las reglas en steering
Elige tú mismo un nivel de acceso a la memoria en lugar de aceptar el que esté configurado. Lectura y escritura permite que Kiro aprenda; solo lectura te permite usar lo que hay allí sin cambios. Confía en los espacios de trabajo donde deseas que crezca la memoria.
Luego, mueve cualquier cosa que deba aplicarse siempre a steering o AGENTS.md. La memoria es para lo que Kiro aprende; steering es para lo que tú decides. Si se han ignorado reglas anteriormente, nuestra guía sobre por qué los agentes ignoran los archivos de instrucciones cubre las causas comunes.
Configuración en MemoryLake
Un cambio de versión es un buen momento para notar cuánto del contexto de tu proyecto vivía en el almacenamiento de sesiones de una sola herramienta. MemoryLake es una capa de memoria para mantener las decisiones detrás de tu trabajo en una sola lista que tú mantienes, disponible para Kiro y los demás asistentes que utilices.
Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de tus sesiones de Kiro, de la base de datos de memoria de Kiro, de los archivos de steering ni del almacenamiento de ningún proveedor. Si trabajas con código de la empresa, consulta la política de tu organización antes de copiar los detalles del proyecto en otro lugar.
Paso 1: Crea una clave API
Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake y es independiente de tu cuenta de Kiro o AWS.

Paso 2: Sube tus primeras memorias
Comienza con lo que extrajiste de tus sesiones de V2 en el Paso 1: decisiones, enfoques descartados y convenciones. Un elemento por entrada, con fecha y el motivo.

Paso 3: Conecta tu IA y agentes
Conecta Kiro y los demás asistentes que utilices. Las mismas decisiones estarán disponibles en V3 desde tu primera sesión, y en cualquier otra herramienta, sin esperar a que la memoria de V3 vuelva a aprenderlas.

Qué cambia esto en la práctica
La primera diferencia es que el cambio deja de ser una apuesta. Sabes a qué sesiones puedes volver, cómo, y cuáles ya has resumido.
La segunda es una primera semana más limpia en V3. Steering, AGENTS.md y tus propias notas ofrecen a las sesiones de V3 un punto de partida mientras se construye su memoria. Otras herramientas han tenido cambios de contexto silenciosos similares en las actualizaciones de versión; nuestro análisis de las correcciones silenciosas de contexto de Cline es un ejemplo.
La tercera es que habrá menos sorpresas con la actualización en sí. Los hooks descartados y los modos de inclusión modificados se detectan durante la simulación en lugar de durante el trabajo real.
La cuarta es la portabilidad. Si más adelante trasladas parte del trabajo a otro agente, como se explica en nuestra guía para migrar de Kiro a Claude Code, tus decisiones no dependerán del formato de sesión de ninguna de las dos herramientas.
Buenas prácticas antes de la CLI 3.0
No confíes en Don't ask again. La actualización se realizará en la CLI 3.0 de todos modos.
Haz una copia de seguridad de tu directorio de inicio de Kiro primero. Las sesiones y las memorias viven allí.
Termina las sesiones importantes de V2 en V2. Luego resúmelas.
Realiza una simulación de las actualizaciones de agentes. Lee cada advertencia antes de confirmar.
Vuelve a comprobar el front matter de steering. Los modos de inclusión se aplican por completo en V3.
Configura el acceso a la memoria a propósito. Y confía solo en los espacios de trabajo que desees.
Mantén las reglas en steering. Para saber cómo steering y las funciones dividen el contexto, consulta nuestra guía sobre cómo enrutar el contexto entre las funciones de Kiro y steering.
Conclusión
Kiro CLI V3 se convierte en el valor por defecto con la CLI 3.0 a finales de octubre de 2026, y elegir Don't ask again no te mantendrá en V2. V3 utiliza un nuevo almacenamiento de sesiones. Las sesiones de V3 no se pueden abrir en V2. El blog de Kiro dice que las sesiones de V2 se pueden reanudar en V3, mientras que su guía de migración dice que no se convierten y te remite a V2 para abrirlas, así que haz una prueba con una sesión importante antes de confiar en cualquiera de las dos lecturas.
V3 también trae memoria a la CLI. Kiro la describe como un aprendizaje a partir de sesiones locales de V3, con un acceso que tú controlas, y su documentación no describe que aprenda de V2.
Antes de la fecha límite, cierra las sesiones de V2 de las que dependas, actualiza tus agentes teniendo en cuenta las advertencias y escribe las decisiones que quieras conservar en un lugar donde ningún cambio de versión pueda dejarlas aisladas.