KAIJU: An Executive Kernel for Intent-Gated Execution of LLM Agents

El artículo presenta KAIJU, un sistema que desacopla la planificación del LLM de la ejecución mediante un kernel ejecutivo y un paradigma de ejecución controlada por intención (IGX), superando las limitaciones de latencia, escalabilidad y seguridad de los agentes ReAct tradicionales.

Lo esencial

Imagina que tienes un genio muy inteligente (un modelo de Inteligencia Artificial) que puede resolver problemas complejos, pero que a veces es un poco desordenado, olvidadizo y, si no lo vigilas, puede hacer cosas peligrosas o mentir sobre lo que ha hecho.

La mayoría de los sistemas actuales (llamados "ReAct") funcionan como una conversación interminable. Le preguntas algo al genio, él piensa, te dice: "Voy a buscar esto", lo hace, te cuenta el resultado, y luego te dice: "Ahora voy a buscar aquello". El problema es que cada vez que habla, tiene que leer todo lo que ha dicho antes en la conversación. Si la tarea es larga, el genio se ahoga en sus propias palabras, se olvida de lo que empezó, gasta mucho dinero en memoria y, lo peor, puede decidir rendirse a mitad de camino si ve un error.

KAIJU es una nueva forma de organizar a este genio. En lugar de dejarlo hablar libremente, le ponemos un jefe ejecutivo (un "Kernel") que controla todo el proceso.

Aquí tienes la explicación con analogías sencillas:

1. El Problema: El Genio que se ahoga en su propia historia

Imagina que le pides a un detective (el genio) que resuelva un crimen complejo.

• El método antiguo (ReAct): El detective escribe un diario. En la página 1 dice "Voy a interrogar al jardinero". En la página 2 escribe lo que dijo el jardinero. En la página 3 dice "Ahora voy a buscar huellas".
  • El problema: Para la página 50, el detective tiene que leer las 49 páginas anteriores para recordar qué hizo. Su cuaderno se vuelve gigante, se le cae la tinta (se olvida cosas), y si el jardinero no responde, el detective decide: "Bueno, ya me sé la respuesta de memoria" y te da una mentira. Además, si el detective decide "¡Voy a quemar la casa!", no hay nadie que lo detenga hasta que ya lo haya escrito.

2. La Solución KAIJU: El Jefe Ejecutivo y la Fábrica

KAIJU separa al pensador (el genio) del trabajador (la ejecución).

• El Planificador (El Arquitecto): Al principio, el genio solo tiene que dibujar un mapa de trabajo (un gráfico). No ejecuta nada todavía. Solo dice: "Necesito hacer A, luego B, y C depende de A".
• El Kernel (El Jefe de Obra): Una vez que tiene el mapa, el genio descansa. Un sistema automático (el Kernel) toma el mapa y empieza a trabajar.
  • Si A y B no dependen el uno del otro, el Kernel los manda a hacer al mismo tiempo (como tener varios obreros trabajando en paralelo).
  • Si C necesita el resultado de A, espera a que A termine.

3. La Puerta de Seguridad (IGX): El Guardias de Seguridad

Esta es la parte más importante. En los sistemas antiguos, si el genio decía "Borrar todos los archivos", el sistema lo hacía porque el genio "pensó" que era una buena idea.

En KAIJU, hay una Puerta de Seguridad (Intent-Gated Execution) antes de que cualquier herramienta se use. Imagina que cada herramienta (como un martillo o un cortacéspedes) tiene un guardia de seguridad que pregunta cuatro cosas antes de dejar pasar al obrero:

1. Alcance: ¿Tienes permiso para usar esta herramienta? (No puedes usar un cortacéspedes si solo tienes permiso para una escoba).
2. Intención: ¿Quién te envió? (¿Es una tarea de "observar" o de "destruir"?).
3. Impacto: ¿Qué daño puede causar esta herramienta? (Un "borrar archivo" tiene un impacto alto).
4. Permiso Externo: ¿El dueño de la casa (un sistema externo) dice que sí?

La magia: El genio nunca sabe si la puerta se abrió o se cerró. Si el guardia dice "No", el obrero falla silenciosamente y el sistema intenta otra cosa. El genio no puede "probar" la seguridad preguntando "¿Y si digo que es una emergencia?". La seguridad está fuera de su control, como un candado que él no puede ver ni abrir.

4. Los Tres Modos de Trabajo

KAIJU tiene tres formas de gestionar el trabajo, como diferentes estilos de supervisión:

• Reflect (El Supervisor de Etapas): El trabajo se hace en oleadas. Termina la oleada 1, el supervisor revisa los resultados, decide si falta algo, y lanza la oleada 2.
• nReflect (El Supervisor por Lotes): Revisa los resultados cada cierto número de tareas (por ejemplo, cada 5 tareas), sin importar el orden. Es rápido y eficiente.
• Orchestrator (El Supervisor de Tiempo Real): Hay un supervisor para cada tarea individual. En cuanto una tarea termina, el supervisor la mira y decide inmediatamente qué hacer a continuación. Es el más detallado y preciso.

5. ¿Por qué es mejor?

• No se ahoga: Como el genio solo ve el plan inicial y luego revisa pequeños trozos de resultados (no todo el historial gigante), nunca se olvida de lo que estaba haciendo.
• No se rinde: Si una herramienta falla (por ejemplo, una página web no carga), el sistema automático (el Kernel) intenta otra cosa o repara el plan. No le pregunta al usuario "¿Qué hago?". Sigue trabajando hasta terminar.
• Es más seguro: El genio no puede engañar al sistema para hacer cosas peligrosas porque la seguridad la decide un sistema externo, no el genio.
• Es más rápido en cosas difíciles: Al hacer muchas cosas a la vez (paralelismo) y no tener que leer todo el historial de la conversación, resuelve problemas complejos mucho más rápido que el método antiguo.

En resumen

KAIJU es como cambiar de tener un detective solitario que escribe un diario interminable a tener un director de orquesta que asigna las tareas a músicos expertos, vigila que toquen la nota correcta con un sistema de seguridad automático, y asegura que la sinfonía termine sin que nadie se pierda ni toque una nota prohibida.

Es una forma de hacer que la Inteligencia Artificial sea más confiable, segura y eficiente para tareas del mundo real.

Resumen técnico

Resumen Técnico: KAIJU

1. El Problema

Los agentes autónomos basados en Modelos de Lenguaje Grande (LLM) que utilizan el paradigma ReAct (Reasoning + Acting) enfrentan tres limitaciones críticas a medida que aumenta la complejidad de las tareas:

1. Latencia Serial y Crecimiento Cuadrático del Contexto: En ReAct, cada turno de razonamiento debe incluir todo el historial de conversación y los resultados de las herramientas anteriores. Esto genera una complejidad de tokens de $O(n^2k)$ (donde $n$ es el número de pasos y $k$ el tamaño del resultado). En tareas complejas, esto agota la ventana de contexto efectiva, degradando la calidad de la salida o provocando fallos.
2. Vulnerabilidad a la Inyección de Prompts y Alucinaciones: La seguridad se basa únicamente en instrucciones de prompt (ej. "no llames a herramientas destructivas"). Los modelos pueden ignorar estas instrucciones mediante alucinaciones, inyección de prompts o desbordamiento de contexto, ya que no existe un mecanismo de seguridad estructural.
3. Falta de Garantías de Comportamiento: El modelo tiene autoridad unilateral sobre el uso de herramientas. Si una herramienta falla, el modelo puede decidir racionalmente (pero indeseablemente) abandonar la tarea, recurrir a su conocimiento paramétrico (datos obsoletos) o pedir ayuda al usuario, lo que compromete la fiabilidad del sistema.

2. Metodología: KAIJU y el Kernel Ejecutivo

El artículo propone KAIJU, una abstracción a nivel de sistema que desacopla completamente la capa de razonamiento del LLM de la mecánica de ejecución. El sistema se basa en dos capas principales:

• Capa de Razonamiento (LLM): Actúa como un recurso sin estado. Solo se invoca en puntos discretos para planificar, reflexionar o sintetizar resultados. No tiene visibilidad sobre los mecanismos de ejecución ni sobre las decisiones de seguridad.
• Capa de Ejecución (Kernel Ejecutivo): Gestiona la programación, el despacho de herramientas, la resolución de dependencias, la recuperación de fallos y la seguridad.

Componentes Clave:

• Gráfico de Ejecución (DAG): El LLM genera un grafo acíclico dirigido de llamadas a herramientas. Las herramientas se ejecutan en "olas" paralelas basadas en la resolución de dependencias, no en decisiones secuenciales del LLM.
• Inyección de Dependencias Estructural: Los parámetros se resuelven en tiempo de ejecución a partir de salidas de nodos anteriores, eliminando la necesidad de bucles de razonamiento secuenciales para pasar datos.
• Modos de Ejecución Adaptativa:
  1. Reflect: Puntos de control entre olas de dependencias para replanificar si es necesario.
  2. nReflect: Puntos de control periódicos (cada N nodos) para equilibrar rendimiento y supervisión.
  3. Orchestrator: Observadores ligeros por nodo que pueden inyectar pasos adicionales o cancelar trabajo en tiempo real.

3. Contribuciones Clave: Ejecución Puerta de Intención (IGX)

La innovación central es IGX (Intent-Gated Execution), un paradigma de seguridad que enforza la autorización antes de ejecutar cualquier herramienta, independientemente de lo que diga el LLM.

• Desacoplamiento Estructural: El LLM no sabe si una llamada fue bloqueada. Si una herramienta es denegada, el nodo falla con un error genérico, evitando que el modelo aprenda los límites de la política de seguridad (evitando ataques adaptativos).
• Las 4 Variables de la Puerta de Ejecución: La autorización se decide determinísticamente en código compilado basándose en cuatro variables independientes:
  1. Alcance (Scope): ¿Qué herramientas están permitidas? (Lista de permitidos).
  2. Intención (Intent): ¿Quién inicia la tarea? (Definido por la fuente del trigger, no por el LLM).
  3. Impacto (Impact): ¿Cuál es el nivel de riesgo de la herramienta? (Definido por el autor de la herramienta, ej. lectura=0, escritura=1, borrado=2).
  4. Despeje (Clearance): Autorización de recursos delegada a un endpoint HTTP externo (ej. políticas de AD, límites geográficos).
• Recuperación de Fallos Estructural: Si una herramienta falla, un "micro-planificador" (un LLM especializado y barato) intenta reemplazar el nodo fallido con una alternativa (nuevos parámetros, otra herramienta) sin pedir permiso al usuario ni detener el flujo.

4. Resultados Empíricos

El artículo presenta una evaluación comparativa contra un baseline de ReAct (con llamadas paralelas de funciones) en 40 consultas de cuatro niveles de complejidad y un benchmark de astronomía computacional.

• Latencia y Escalabilidad:
  • En consultas simples, ReAct es ligeramente más rápido (3.6s vs 3.9s) debido a la falta de sobrecarga de planificación.
  • En consultas complejas y computacionales, KAIJU supera significativamente a ReAct. Por ejemplo, en consultas complejas, nReflect tarda 9.5s frente a 28.9s de ReAct. En astronomía computacional, KAIJU completa el 100% de las consultas, mientras que ReAct falla en el 20% por agotamiento del contexto.
• Complejidad de Tokens:
  • ReAct: $O(n^2k)$ (crecimiento cuadrático).
  • KAIJU (Modo Reflect): $O(nkd)$ (donde $d$ es la profundidad de dependencia, mucho menor que $n$).
  • KAIJU (Modo Orchestrator): $O(nk)$ (lineal).
• Fiabilidad y Calidad:
  • ReAct tiende a "abandonar" tareas cuando las herramientas fallan o se agota el contexto, recurriendo a conocimiento paramétrico (respuestas obsoletas) o dando respuestas vacías.
  • KAIJU mantiene la persistencia estructural. Si una herramienta falla, el sistema re-planifica automáticamente. En el benchmark de astronomía, KAIJU produjo respuestas detalladas y estructuradas (2,081 bytes en promedio) frente a las respuestas cortas o nulas de ReAct.
  • En el benchmark GAIA (preguntas de texto), KAIJU (Modo Reflect) logró un 15.7% de precisión frente al 12.6% de ReAct, con una latencia menor (10.7s vs 17.0s).

5. Significado e Impacto

KAIJU representa un cambio de paradigma en la arquitectura de agentes de IA:

1. Seguridad Estructural vs. Basada en Prompt: Demuestra que la seguridad no debe depender de la obediencia del modelo, sino de un kernel de ejecución que enforza políticas determinísticamente fuera del control del LLM. Esto cierra la superficie de ataque para la inyección de prompts adaptativa.
2. Escalabilidad Real: Al separar la planificación de la ejecución y limitar el contexto por llamada al LLM, KAIJU permite ejecutar flujos de trabajo complejos y de múltiples pasos que son inviables para arquitecturas conversacionales puras debido al agotamiento de tokens.
3. Fiabilidad Operativa: Garantiza que los agentes no tomen atajos (como usar datos obsoletos) cuando las herramientas fallan, asegurando que la tarea se complete o se declare un fallo de capacidad real, en lugar de una degradación silenciosa.
4. Arquitectura Modular: Permite el uso de modelos LLM más baratos para la ejecución y reflexión, reservando modelos más potentes solo para la planificación inicial, optimizando costos sin sacrificar la calidad del resultado final.

En conclusión, KAIJU transforma a los agentes de LLM de sistemas conversacionales frágiles a sistemas de ejecución robustos, seguros y escalables, aptos para entornos empresariales y de misión crítica.