Por qué Kiro tiene ahora dos formas de cargar contexto bajo demanda
Comencemos con el problema para el que se crearon los powers. La documentación de Kiro lo expone en dos frases: "Sin el contexto del framework, los agentes adivinan" y "Con demasiado contexto, los agentes se ralentizan". Conectar varios servidores MCP significa cargar cada definición de herramienta por adelantado, antes de que comience cualquier trabajo.
Los Powers responden a esto con la activación. "En lugar de cargar todas las herramientas MCP a la vez, los powers se activan dinámicamente en función de las palabras clave de tu conversación". Cuando comienza una tarea, Kiro "Lee la descripción de la tarea", "Evalúa los powers instalados frente a la tarea" y "Carga solo los powers relevantes en el contexto". Y se vuelven a desactivar: el propio ejemplo de Kiro es que cuando pasas de pagos a trabajo de base de datos, "el power de Supabase se activa y el de Stripe se desactiva".
Un power es un paquete. Sigue la especificación de Agent Plugins, con un manifiesto plugin.json obligatorio y carpetas opcionales skills/, mcp.json y una carpeta dev.kiro/ para "extensiones específicas de Kiro como archivos de steering". El campo keywords del manifiesto es el activador: una "Matriz de cadenas que activan la activación. Utiliza términos que coincidan con la forma en que los desarrolladores hablan de tu herramienta".
Steering funciona de manera diferente. Kiro lo describe como dar al agente "conocimiento persistente sobre tu proyecto a través de archivos markdown", y ahora admite cuatro modos de inclusión. "Siempre incluido" es el predeterminado, para "estándares principales que deberían influir en toda la generación de código". La inclusión condicional carga un archivo "solo cuando se trabaja con archivos que coinciden con el patrón especificado". La inclusión manual lo carga cuando lo referencias en el chat. Y la auto inclusión lo carga "cuando tu solicitud coincide con la descripción", lo cual Kiro señala que "funciona de manera similar a las skills".
Así que ambos tienen una forma de cargarse solo cuando son relevantes. La documentación de Kiro detalla la división prevista en una sección titulada "Cómo difieren los powers de las skills y el steering":
"Los powers son plugins que agrupan herramientas MCP, skills y conocimiento en un único paquete instalable. Se activan dinámicamente según el contexto. Úsalos para integraciones donde necesites tanto herramientas como guía".
"Steering es contexto específico de Kiro que da forma al comportamiento del agente. Admite los modos always, auto, fileMatch y manual. Úsalo para estándares y convenciones del proyecto".
Hay una diferencia más que la comparación no detalla pero que las páginas de instalación dejan clara: dónde vive cada uno. Steering vive en el repositorio: "El agente busca automáticamente archivos de steering en la carpeta .kiro/steering/ en la raíz de tu repositorio". Los Powers se instalan a través del panel de powers, desde el registro, una URL de GitHub o una carpeta local. Un power de formato heredado registra sus servidores MCP "en tu archivo de configuración ~/.kiro/settings/mcp.json", y los servidores de un power de Agent Plugins "son gestionados internamente por Kiro". De cualquier manera, un power es parte de tu configuración, no del repositorio.
Lo que la gente intenta en su lugar
Poner todo en steering siempre activo. Funciona, pero cada tarea paga el precio. Un bloque largo de notas sobre una API de pagos se carga mientras corriges una errata en el README. El propio consejo de Kiro para material con mucho contexto es usar un modo más restringido.
Convertir las convenciones del equipo en un power. Un power se instala por persona. Si las reglas de manejo de errores de tu equipo viven en un power que tú instalaste, un colega que no lo haya instalado trabajará sin ellas, y el repositorio no dará ninguna señal de que falta algo.
Depender de palabras clave para hechos del proyecto. Las palabras clave se adaptan bien a las integraciones, porque la gente dice de forma natural "Stripe" o "base de datos" al trabajar con ellas. Las convenciones del proyecto rara vez vienen con una palabra que aparezca de manera confiable en la solicitud.
Tratar el auto steering y los powers como si fueran lo mismo. Ambos se activan por relevancia. Solo uno trae herramientas MCP consigo y solo uno viaja con el repositorio.
Asumir que los modos de inclusión se comportan de manera idéntica en cada superficie. La página de steering de Kiro dice actualmente dos cosas diferentes aquí. Su tabla de capacidades marca "Modos de inclusión (always, fileMatch, manual)" como compatibles con el IDE, CLI, Web y Móvil. La misma página también incluye una nota: "En Kiro CLI, los modos de inclusión no son compatibles actualmente. Todos los archivos de steering en el directorio .kiro/steering/ se cargan automáticamente". Hasta que ambos coincidan, verifica el comportamiento en la CLI por ti mismo en lugar de asumir cualquiera de las dos afirmaciones. Una guía anterior sobre cómo dividir el steering de Kiro para el IDE y la CLI se escribió en torno a la segunda afirmación.
La solución: Enrutar cada fragmento de contexto según quién lo necesite y cuándo se aplique
El enrutamiento se reduce a dos preguntas para cada fragmento de contexto: ¿lo necesita todo el mundo que trabaja en este repositorio y qué debería activarlo?
Paso 1: Clasificar cada fragmento de contexto por audiencia y activador
Haz una lista de lo que tu agente sabe actualmente, a partir de los archivos de steering y de cualquier cosa que repitas en los prompts. Para cada elemento, anota dos cosas.
Audiencia: ¿es esto aplicable para todos los que trabajan en el repositorio, o se trata de una herramienta que solo usan algunas personas? Las convenciones de manejo de errores, el diseño de directorios y los comandos de prueba son hechos del equipo. Cómo llamar a la API de un proveedor específico con el patrón de idempotencia correcto es experiencia en herramientas.
Activador: ¿cuándo debería cargarse? ¿Siempre, cuando ciertos archivos están abiertos, cuando una solicitud coincide con una descripción, o solo cuando alguien lo solicita?
Esto produce una cuadrícula simple. Los hechos del equipo con cualquier activador van a steering. La experiencia en herramientas que viene con herramientas va a un power. La experiencia en herramientas sin herramientas —por ejemplo, notas de uso para una biblioteca— puede ir a cualquiera de los dos, y la pregunta de la audiencia generalmente lo resuelve.
Paso 2: Mantener las convenciones del equipo en steering, con el modo más restringido que aún se active
Para cada hecho del equipo, elige el modo de inclusión que lo cargue exactamente cuando se aplique.
Los estándares genuinamente universales se quedan en "always". Los ejemplos de Kiro para ese modo son "tu stack tecnológico, convenciones de codificación y principios arquitectónicos fundamentales".
Las convenciones vinculadas a una parte de la base de código obtienen inclusión condicional con un patrón de archivo, de modo que las reglas de componentes se cargan cuando los archivos de componentes están en juego.
La guía más extensa que solo importa para ciertas solicitudes obtiene auto inclusión, con un name y una description que Kiro pueda hacer coincidir. El uso recomendado por Kiro para auto es "Guía con mucho contexto que solo debería cargarse cuando sea relevante".
Los procedimientos que ejecutas ocasionalmente —una lista de verificación de migración, una guía de resolución de problemas— obtienen inclusión manual, que Kiro recomienda para "Flujos de trabajo especializados, guías de resolución de problemas, procedimientos de migración o documentación con mucho contexto que solo se necesita ocasionalmente".
Una regla estructural es importante para todos los modos: "La configuración de inclusión debe ser el primer contenido del archivo; sin líneas en blanco ni contenido antes de ella". Un bloque de front-matter después de una línea en blanco no es un bloque de front-matter.
Si utilizas agentes personalizados, comprueba también su configuración. Kiro señala que "Al usar agentes personalizados, los archivos de steering no se incluyen automáticamente. Debes agregarlos explícitamente a la configuración de resources del agente para cargar el contexto de steering".
Paso 3: Mover la experiencia en herramientas a los powers, verificar las palabras clave y luego verificar en cada superficie
Para las integraciones, instala el power en lugar de reconstruir su guía en steering. Si tu equipo utiliza una herramienta privada, Kiro admite la creación de una: un plugin.json con una description y keywords claras, además de skills y una configuración MCP opcional.
Lee las palabras clave de cada power que instales. Estas deciden cuándo se activa y están escritas según la forma en que los desarrolladores suelen hablar de la herramienta, lo que puede no coincidir con la forma en que lo hace tu equipo.
Luego, verifica. Inicia una tarea que debería activar un power y otra que no, y confirma que las herramientas aparecen y desaparecen. Inicia una tarea que afecte a un área incluida condicionalmente y confirma que el steering se carga. Haz esto en el IDE y, si lo usas, en la CLI, dadas las notas contradictorias en la página de steering. And si los powers son parte de la forma de trabajar de tu equipo, anota cuáles son, para que un nuevo colega pueda instalar el mismo conjunto.
Configuración de esto en MemoryLake
El Paso 1 produce una lista de hechos del equipo que son ciertos independientemente de qué agente, superficie o plugin esté cargado. MemoryLake es un lugar para mantener esa lista de modo que no dependa del diseño de carpetas o de los modos de inclusión de una sola herramienta.
Tú mismo escribes las entradas, con tus propias palabras. No se lee nada, ni se escribe, ni se elimina de .kiro/steering, de tus powers instalados o de la tienda de ningún proveedor.
Paso 1: Crear una clave API
Inicia sesión y genera una clave desde el panel de control. La clave es lo que permite a un agente leer las entradas que has escrito, ya sea en Kiro o en cualquier otra herramienta del equipo.
Paso 2: Subir tus primeras memorias
Agrega los hechos del equipo del Paso 1, uno por entrada, con la razón por la que existe cada convención. La razón es lo que permite a alguien decidir más tarde si la regla debe moverse, cambiar o mantenerse.
Paso 3: Conectar tu IA y agentes
Apunta tus agentes al espacio de trabajo. Las mismas convenciones estarán disponibles independientemente de la superficie o el conjunto de plugins que un compañero de equipo esté utilizando.
Qué cambia esto en la práctica
La primera diferencia es una línea base más pequeña. La guía de integración que se carga con su power no está pagando alquiler en cada tarea. El punto más amplio —que una ventana más grande cambia lo que cabe, no lo que merece estar allí— es el que respalda por qué el contexto largo no es memoria.
La segunda es que el conocimiento del equipo se queda con el equipo. Las convenciones en steering están en el repositorio, revisadas y compartidas. Los Powers siguen siendo un asunto de la configuración de cada persona, lo cual es correcto para las herramientas e incorrecto para las reglas que todos deben seguir.
La tercera es que los costos de contexto se vuelven legibles. Cuando el steering siempre activo contiene solo hechos universales, la parte fija de cada solicitud es pequeña y conocida. Los equipos que realizan un seguimiento de cómo la memoria reduce el uso de tokens generalmente encuentran los ahorros en lo que dejaron de enviar cada vez, un punto que también se menciona en de dónde provienen los ahorros en costos de tokens.
La cuarta es la resiliencia a las sesiones largas. El contexto que se carga bajo demanda también puede desaparecer cuando se compacta una sesión; saber qué hechos deben sobrevivir es la cuestión en decidir qué sobrevive a la compactación de Kiro.
Buenas prácticas para Kiro powers y steering
Enruta primero por audiencia. Si todos en el repositorio lo necesitan, pertenece a steering. Si viene con una herramienta que algunas personas usan, pertenece a un power.
Utiliza el modo de inclusión más restringido que aún se active. Always para estándares universales, patrones de archivo para reglas específicas de un área, auto para guías pesadas, manual para procedimientos ocasionales.
Coloca el front-matter primero. Los ajustes de inclusión solo funcionan como el primer contenido del archivo.
Lee las palabras clave de cada power. Estas deciden la activación y están escritas para el desarrollador promedio en lugar de para el vocabulario de tu equipo.
Mantén una lista de los powers de los que depende tu equipo. Un power instalado en una máquina es invisible para el repositorio y para la siguiente persona que lo clone.
Verifica en cada superficie. La página de steering de Kiro actualmente ofrece dos declaraciones diferentes sobre los modos de inclusión en la CLI. Realiza pruebas en lugar de asumir, y trata a los servidores MCP como parte del mismo panorama: MCP es la capa de memoria que falta solo cuando los hechos detrás de las herramientas también se guardan en algún lugar. Si más adelante mueves herramientas, migrar de Kiro a Codex muestra qué piezas se transfieren.
Conclusión
Los powers y el steering de Kiro resuelven problemas relacionados en diferentes lugares. Los Powers reúnen las herramientas y la guía de una integración y las activan y desactivan con la conversación. Steering contiene los propios estándares del repositorio, con cuatro modos de inclusión para controlar cuándo se carga cada archivo.
La documentación de Kiro establece la división directamente: powers "para integraciones donde necesitas tanto herramientas como guía", steering "para estándares y convenciones del proyecto". La parte que hay que añadir de las páginas de instalación es que steering viaja con el repositorio y los powers viajan con la persona.
Clasifica cada fragmento de contexto por audiencia y activador, mantén los hechos del equipo en steering con el modo más restringido que se active, deja que los powers lleven la experiencia en herramientas y verifica en cada superficie que utilices. Mantén las convenciones del equipo escritas en algún lugar que no dependa de ninguno de esos mecanismos.