Cómo decidir qué sobrevive a la compactación de Kiro (Guía 2026)

El propio resumen de Kiro sobre el mecanismo es sencillo. La compactación "mantiene productivas las sesiones largas al resumir automáticamente el historial de conversación más antiguo a medida que crece tu sesión", y el enfoque es que "tus objetivos, decisiones y progreso técnico se preservan; solo se comprime la parte intermedia redundante".

La secuencia consta de tres partes: "Kiro crea un resumen estructurado que captura tus objetivos, decisiones, progreso y siguientes pasos", luego "el historial de conversación más antiguo se reemplaza por el resumen, mientras que tus mensajes más recientes se mantienen textualmente", y después la sesión continúa "desde donde la dejaste sin interrupciones".

Ese diseño es sensato, y las categorías que elige son las correctas para continuar el trabajo. Un resumen que sabe qué archivos cambiaron, qué pruebas pasan, qué queda y cuáles son tus restricciones puede seguir adelante sin problemas. El ejemplo práctico de Kiro lo demuestra bien: después de cuarenta y cinco minutos de refactorización, el resumen conserva qué archivos se modificaron, qué pruebas pasan, los dos archivos restantes y la restricción de que "todos los cambios deben ser compatibles con versiones anteriores".

La brecha es una diferencia de categoría, no un error. Un resumen preserva las conclusiones de manera eficiente y los argumentos de manera deficiente. "Todos los cambios deben ser compatibles con versiones anteriores" sobrevive como una restricción. Los veinte minutos en los que estableciste por qué la compatibilidad con versiones anteriores no era negociable aquí —el llamador que nadie puede actualizar, el cliente en una versión antigua, la migración que falló el año pasado— es exactamente lo que la tabla clasifica bajo discusión exploratoria y pasos de razonamiento intermedio.

Dos entradas más en la columna de lo comprimible merecen atención. "Detalles de errores de problemas resueltos" significa que los fallos que ya solucionaste se comprimen, y un fallo que ya solucionaste suele ser la evidencia más sólida para el enfoque que decidiste adoptar. "Fragmentos de código en mensajes anteriores" significa que la implementación rechazada desaparece mientras que la aceptada permanece, lo que elimina la comparación que justificaba la elección.

El remedio de Kiro para un detalle faltante es honesto y revelador: "Si el agente parece haber perdido un detalle específico de un momento anterior de la sesión, vuelve a indicarlo. El agente lo incorporará de inmediato". Eso funciona. También significa que el mecanismo de retención para cualquier cosa que no esté en la columna de lo preservado eres tú, recordando decirlo de nuevo, el bucle que describimos en cómo dejar de volver a explicar el contexto a tu IA.

Este no es un diseño exclusivo de Kiro. Amazon Q Developer documenta el mismo comportamiento bajo un nombre diferente: después de la compactación, "Amazon Q utiliza el resumen compactado (not the full history) para generar respuestas", y aunque la conversación completa sigue visible en el panel de la sesión, "el historial de chat detallado se restablecerá cuando reinicies tu IDE". Dos proveedores, dos implementaciones independientes, la misma conclusión: la conversación es memoria de trabajo, no almacenamiento.

Desactivar la compactación. No está disponible en la mayoría de las interfaces. La documentación de Kiro indica que la compactación "es automática en el IDE. No hay un activador manual", y repite lo mismo para la Web y el móvil. Solo la CLI expone /compact, y eso es un activador manual, no un interruptor. La alternativa a la compactación es quedarse sin contexto.

Ajustar la configuración de retención. La CLI expone dos: compaction.excludeMessages, descrito como el "número mínimo de pares de mensajes recientes que se deben conservar textualmente", y compaction.excludeContextWindowPercent, el "porcentaje mínimo de la ventana de contexto que se debe mantener como mensajes recientes". Ambos tienen un valor predeterminado de 2, y "ambas configuraciones se evalúan, y gana el valor más conservador (el mayor)".

Aumentarlos mantiene una mayor parte de la cola reciente de forma textual, lo que realmente ayuda con la continuidad. No hace nada por el razonamiento que ocurrió hace una hora, porque la cola se define por la novedad, no por la importancia. Este es el límite general que expusimos en por qué una ventana de contexto larga no es memoria.

Exportar la sesión. Kiro recomienda esto por una buena razón: "Si necesitas preservar el historial completo, exporta tu sesión antes de que ocurra la compactación". Una exportación es una salvaguarda real contra la pérdida total. No es un mecanismo de recuperación: una transcripción es cronológica, no está indexada y describe lo que se dijo en lugar de lo que es actualmente cierto. Esa distinción es todo el tema de lo que recuerdan los registros de sesión indexados y lo que no.

Iniciar una sesión nueva para cada fase. Una higiene razonable, y la guía de la CLI de Kiro sugiere /compact "antes de comenzar una nueva fase de trabajo dentro de la misma sesión". Pero una nueva sesión comienza con archivos de configuración (steering files) y sin conversación, por lo que cualquier cosa que hayas establecido en la sesión anterior y no hayas anotado desaparece por definición en lugar de por resumen.

Poner todo en steering (archivos de configuración). La sobrecorrección. Los archivos de configuración de Kiro bajo .kiro/steering/ están siempre activos por defecto, y un archivo AGENTS.md en la ubicación de steering no se puede limitar en absoluto; las notas de la documentación indican que "los archivos AGENTS.md no admiten modos de inclusión y siempre se incluyen". Si trasladas todo tu historial de razonamiento allí, habrás convertido un problema de compactación en un problema de presupuesto de contexto, que es el equilibrio examinado en cuánta memoria deberías darle a un agente de IA.

La tabla es la herramienta. Utilízala como una regla de enrutamiento en el momento en que aparece un dato, no como un análisis post-mortem.

Paso 1: Lee las dos columnas como una especificación de enrutamiento

Toma la tabla de Kiro literalmente y aplícala mientras trabajas. Cuando se establezca algo importante en una sesión, pregunta en qué columna encaja.

Si es el estado de la tarea, una ruta modificada, un siguiente paso o un requisito declarado, déjalo en la conversación. Kiro los preserva, y duplicarlos en otro lugar crea dos registros que no coincidirán.

Si es un argumento, una opción rechazada, un error resuelto que te enseñó algo o un fragmento de código con el que estás comparando, está en la lista de lo comprimible. Esa es tu señal para escribirlo en otro lugar, ahora, mientras todavía esté textual.

El caso límite son las "decisiones y restricciones clave", que se encuentran en la columna de lo preservado. La decisión sobrevive; su justificación no. Por lo tanto, la regla de enrutamiento para una decisión es: deja la decisión en la conversación y escribe la justificación fuera de ella. Una restricción sin un motivo registrado es eliminada por la siguiente persona que la encuentre inconveniente.

Paso 2: Promueve la mitad reutilizable a steering y mantén el steering acotado

Parte de lo que escribas pertenece a la propia configuración de Kiro, porque también será cierto en la próxima sesión.

Los archivos de configuración (steering files) viven en .kiro/steering/ para el ámbito del espacio de trabajo y en ~/.kiro/steering/ para el ámbito global, y admiten un modo de inclusión en el front matter, con una restricción documentada que vale la pena tener en cuenta: "La configuración de inclusión debe ser el primer contenido del archivo; sin líneas en blanco ni contenido antes de ella". Los tres modos son always (el predeterminado), fileMatch con un fileMatchPattern y manual.

Utilízalos según su vida útil. Una convención que se aplica a todo el repositorio va en un archivo always. Una convención que se aplica a un área específica obtiene inclusion: fileMatch y un patrón, por lo que no cuesta nada cuando estás en otro lugar. Un procedimiento largo que invocas ocasionalmente obtiene manual.

Lo que no pertenece a steering es el historial continuo de las decisiones de un proyecto. Steering se carga en cada sesión para cada tarea; un registro de decisiones crece sin límites. Kiro también documenta que el steering global es un directorio por máquina; en la Web, "Global steering" se refiere a tu directorio local ~/.kiro/steering/, "que el sandbox de la nube no puede leer", y reutilizarlo en sesiones de nube requiere cargarlo a través de Configuration Sync. Un archivo que vive en una sola computadora portátil no es un registro de equipo.

Paso 3: Dale a los motivos un hogar donde no se ejecute ningún resumen

El resto —los enfoques rechazados, los motivos detrás de las restricciones, los datos que una persona proporcionó cuando el agente estaba atascado— tiene tres propiedades que descartan los dos destinos anteriores. Crece continuamente, por lo que no puede estar siempre activo. Se consulta rara vez y de manera específica, por lo que no debería estar en cada prompt. Y debe ser legible por la próxima sesión, la próxima persona y la próxima herramienta, por lo que no puede vivir en una transcripción en una sola máquina.

Eso es un almacén (store), no un archivo ni una conversación. Se le añaden datos cuando se toma una decisión y se lee cuando se cuestiona una decisión, y nada en él está sujeto a un paso de resumen.

MemoryLake es ese almacén: una capa compartida que contiene el razonamiento que tu sesión comprime y que tus archivos de configuración (steering files) no deberían llevar. Kiro conserva el estado; steering conserva las convenciones vigentes; la capa conserva los argumentos. Comienza aquí.

Paso 1: Crea una clave API

Crea un espacio de trabajo para el proyecto y genera una clave API. Un espacio de trabajo por proyecto, no por sesión; el objetivo es que abarque las sesiones que la compactación restablece.

Paso 2: Sube tus primeras memorias

No empieces de cero. Exporta una sesión que ya se haya compactado y analízala en busca de la columna comprimible: los enfoques que probaste y abandonaste, los errores que cambiaron tu diseño, las restricciones que alguien declaró verbalmente. Añade los motivos detrás de cada archivo de configuración (steering file) que ya tengas, ya que esos archivos establecen reglas sin explicar el porqué.

Paso 3: Conecta tu IA y agentes

Conecta Kiro a través de las interfaces que realmente utilizas: el IDE y la CLI se comportan de manera diferente al compactar, y ambos deberían leer el mismo conjunto. Si ejecutas Kiro Crew para flujos de trabajo en equipo, conecta también esos agentes, de modo que un agente programado no trabaje con un registro más limitado que la persona que lo configuró.

Las sesiones largas dejan de perder información de forma invisible. La compactación se sigue ejecutando, bajo su propio calendario, y el resumen sigue conservando el estado. Pero el argumento detrás de cada restricción está en un lugar que no se resume, por lo que una sesión compactada es un contexto más pequeño en lugar de una memoria más corta.

El bucle de volver a indicar información se reduce. El consejo de Kiro de volver a indicar un detalle perdido está bien una vez. Es costoso cuando los mismos tres datos se vuelven a indicar en cada sesión durante un mes, y no es confiable, porque la persona que los vuelve a indicar tiene que recordar que el dato se llegó a establecer.

Los enfoques rechazados dejan de reaparecer. "Detalles de errores de problemas resueltos" está en la lista de lo comprimible, lo que significa que el registro de lo que no funcionó es lo primero en desaparecer. Escribe eso y el agente dejará de proponer lo que descartaste el martes.

Los archivos de configuración (steering files) se mantienen lo suficientemente pequeños como para ser efectivos. Cuando el registro de decisiones tiene su propio hogar, steering puede ser un conjunto corto de convenciones vigentes en lugar de un documento en constante crecimiento que consume contexto en cada solicitud. El argumento general para mantener ligera la capa siempre activa se encuentra en cómo la memoria del agente se volvió más precisa al conservar menos.

Escribe el motivo en el momento en que se mencione, no al final de la sesión. Para el final, es posible que la conversación ya se haya compactado, y se aplica la propia advertencia de Kiro: el historial antes del punto de compactación "no se puede recuperar dentro de la sesión".

Exporta antes de ejecuciones autónomas largas. Es de bajo costo, Kiro lo recomienda y es lo único que se interpone entre tú y un resumen que no puedes auditar.

Aumenta la configuración de retención de la CLI para la continuidad, no para la retención. Incrementar compaction.excludeMessages ayuda al agente a mantener la coherencia a través de un límite. No es almacenamiento, porque la ventana que protege se define por la novedad.

Utiliza el steering fileMatch más que el steering always. Cada archivo always compite por el mismo contexto en cada solicitud, y los que podrían haberse acotado son pura sobrecarga. Ten en cuenta también que un archivo AGENTS.md en la ubicación de steering no tiene ningún modo de inclusión disponible.

Distingue la decisión de la restricción en lo que escribas. "No usar el ayudante de reintentos compartido en pagos" es una restricción y sobrevive a la compactación. "Porque realiza reintentos en una ruta de fallo que duplica los cargos" es el motivo, no sobrevive, y es lo único que evitará que la restricción se elimine en seis meses.

Si mantienes un registro de sesión para tu propia referencia, mantenlo separado del almacén. Un registro es cronológico y describe lo que se dijo. Un almacén describe lo que es actualmente cierto. Mezclarlos significa que la contradicción más reciente se encuentra junto a la afirmación más antigua sin nada que las distinga; y si más adelante cambias de herramienta, es el almacén el que se transfiere limpiamente, como descubrimos en la migración de Kiro a Codex.

La tabla de compactación de Kiro es más útil que la mayoría de la documentación de los proveedores porque te dice exactamente en torno a qué planificar. El estado, las rutas, las decisiones, los siguientes pasos y la intención sobreviven. Los detalles de las llamadas a herramientas, las discusiones exploratorias, los pasos de razonamiento intermedio, los detalles de errores resueltos y los fragmentos de código anteriores pueden no hacerlo, y la operación es unidireccional.

La respuesta práctica no es luchar contra la compactación. Es dejar de usar la conversación como el lugar de almacenamiento para la segunda columna. Decide en el momento a qué columna pertenece un dato, promueve las convenciones vigentes a archivos de configuración (steering files) acotados y dale al razonamiento un hogar que ningún paso de resumen toque. Entonces, una sesión compactada es exactamente lo que Kiro dice que es: un contexto más pequeño, y nada perdido.