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

O artigo apresenta o KAIJU, um kernel executivo que desacopla o raciocínio de LLMs da execução de ferramentas por meio de abstracções de execução baseada em intenção (IGX) e planeamento antecipado, superando as limitações de latência e segurança dos agentes ReAct tradicionais ao permitir execução paralela e garantias comportamentais robustas.

O essencial

Imagine que você pediu para um assistente de IA muito inteligente (um "agente") resolver um problema complexo, como investigar um crime digital ou planejar uma viagem espacial.

No mundo atual, a maioria desses assistentes funciona como um estagiário ansioso que faz tudo sozinho, mas se distrai facilmente. Eles pensam, agem, olham o resultado, pensam de novo, agem de novo... e assim por diante. O problema é que, quanto mais longo o trabalho, mais bagunçado fica o "bloco de notas" deles (o contexto), eles ficam lentos e, se alguém sussurrar uma instrução errada no ouvido deles, eles podem começar a fazer coisas perigosas sem perceber.

O artigo "KAIJU" apresenta uma solução radical: em vez de deixar o estagiário fazer tudo, criamos um Gerente de Obra (o Kernel Executivo) e um Porteiro de Segurança (IGX).

Aqui está como o KAIJU funciona, usando analogias do dia a dia:

1. A Separação: O Arquiteto vs. A Equipe de Campo

No modelo antigo (chamado ReAct), o mesmo cérebro da IA tinha que pensar no plano, pegar as ferramentas, executar e checar o resultado, tudo na mesma conversa. Era como pedir para um cozinheiro cozinhar, lavar a louça e atender o telefone ao mesmo tempo.

No KAIJU, separamos as funções:

• O Planejador (LLM): Ele é o Arquiteto. Ele recebe o pedido, desenha o mapa de como fazer tudo e entrega o plano. Depois disso, ele descansa. Ele não vê o que acontece na obra.
• O Kernel Executivo (KAIJU): Ele é o Gerente de Obra. Ele pega o plano do Arquiteto, contrata os trabalhadores (ferramentas), resolve quem precisa esperar por quem, e garante que tudo seja feito. Se algo der errado, o Gerente tenta outro caminho sem perguntar ao Arquiteto.

A Analogia: Imagine que você quer construir uma casa. O Arquiteto desenha os planos. O Gerente de Obra não deixa o Arquiteto entrar no canteiro de obras para tentar colocar tijolos. O Gerente garante que os pedreiros sigam o plano, troquem de ferramenta se uma quebrar e não pulem etapas.

2. O Porteiro de Segurança (IGX)

A maior preocupação com IAs é: "E se ela decidir apagar todos os arquivos do computador?" ou "E se um hacker enganar a IA para fazer isso?".

No KAIJU, existe um Porteiro de Segurança chamado IGX. Antes de qualquer ferramenta ser usada, ela passa por uma porta blindada. O Porteiro verifica 4 coisas, independentemente do que a IA diz:

1. Escopo: "Essa ferramenta está na lista de permitidas?"
2. Intenção: "Quem pediu isso? É uma tarefa de leitura segura ou uma ordem de destruição?"
3. Impacto: "O que essa ferramenta faz? É inofensivo ou perigoso?"
4. Autorização Externa: "O dono do recurso (ex: o servidor de banco de dados) disse 'sim'?"

A Analogia: É como entrar em um aeroporto. Mesmo que você (a IA) diga "Eu sou o piloto e preciso abrir a porta do cofre", o segurança (IGX) olha seu crachá, verifica o nível de permissão e pergunta ao gerente do banco. Se o gerente disser "não", a porta não abre. A IA nem sabe que foi bloqueada; ela apenas vê que a ferramenta não funcionou e o Gerente de Obra tenta outra solução. Isso impede que a IA seja "enganada" para burlar regras.

3. Execução em Onda (Paralelismo)

No modelo antigo, a IA fazia uma coisa de cada vez. Se ela precisava de 10 dados, ela esperava o primeiro, depois o segundo... Isso era lento e o "bloco de notas" ficava gigante.

O KAIJU usa Ondas de Execução.

• O Gerente olha o plano e vê: "Preciso de dados A, B e C. Ninguém depende do outro. Vamos fazer os três ao mesmo tempo!"
• Depois, ele verifica os resultados. Se faltou algo, ele manda uma nova onda para buscar o que falta.

A Analogia: Imagine um time de bombeiros.

• Modelo Antigo: Um bombeiro entra, apaga o fogo na sala 1, volta para o caminhão, pega a mangueira, entra na sala 2...
• KAIJU: O capitão (Gerente) manda 3 equipes entrarem nas salas 1, 2 e 3 ao mesmo tempo. Quando terminam, eles se reúnem para ver se precisam de mais ajuda. É muito mais rápido e eficiente.

4. Por que isso é melhor? (Os Resultados)

O artigo testou o KAIJU contra o modelo antigo em tarefas difíceis (como calcular posições de planetas em tempo real).

• Velocidade: Em tarefas simples, o modelo antigo é um pouco mais rápido. Mas em tarefas complexas, o KAIJU é muito mais rápido porque trabalha em paralelo e não perde tempo relembrando toda a conversa anterior.
• Confiabilidade: O modelo antigo, quando se deparava com um erro ou demora, muitas vezes desistia e inventava uma resposta baseada no que "achava que sabia" (alucinação). O KAIJU, como tem um Gerente de Obra, não desiste. Se uma ferramenta falha, o Gerente tenta outra automaticamente até ter a resposta correta.
• Segurança: O KAIJU impede que a IA faça coisas perigosas, não importa o quanto você tente "convencê-la" no prompt. A segurança está no código, não na conversa.

Resumo Final

O KAIJU transforma a IA de um "estagiário solitário e distraído" em uma empresa organizada com um Arquiteto, um Gerente de Obra e um Porteiro de Segurança.

• O Arquiteto planeja.
• O Gerente executa em paralelo e conserta erros.
• O Porteiro garante que nada perigoso aconteça.

Isso permite que as IAs façam trabalhos complexos, rápidos e seguros, sem se perderem no meio do caminho ou serem enganadas. É como trocar uma conversa de bar por uma operação militar bem coordenada.

Resumo técnico

Resumo Técnico: KAIJU - Um Kernel Executivo para Execução de Agentes LLM com Gate de Intenção

1. O Problema

Os agentes autônomos baseados em Grandes Modelos de Linguagem (LLMs) que utilizam o paradigma ReAct (Reasoning + Acting) enfrentam três limitações críticas à medida que a complexidade das tarefas aumenta:

1. Latência Serial e Crescimento Quadrático de Contexto: Em cada turno de raciocínio, o modelo deve reenviar todo o histórico da conversa. O custo de tokens cresce quadraticamente ($O(n^2k)$), onde $n$ é o número de turnos e $k$ o tamanho do resultado da ferramenta. Isso pode esgotar a janela de processamento em tarefas complexas, levando a saídas degradadas ou vazias.
2. Vulnerabilidade à Falha e "Desistência" Racional: O modelo mantém autoridade unilateral sobre o uso de ferramentas. Se uma ferramenta falhar, o modelo pode decidir racionalmente (por turno) abandonar a tarefa, recorrer ao conhecimento paramétrico (alucinação) ou pedir ajuda ao usuário, comprometendo a confiabilidade global da consulta.
3. Fragilidade de Segurança: A segurança é frequentemente imposta apenas via instruções de prompt ("não chame ferramentas destrutivas"). Modelos podem ignorar essas instruções através de injeção de prompt, alucinação ou overflow de contexto, pois não existe um mecanismo de segurança estrutural (failsafe).

2. Metodologia: A Arquitetura KAIJU

O KAIJU introduz uma abstração de nível de sistema que desacopla a camada de raciocínio do LLM da camada de execução. O sistema opera através de dois componentes principais:

A. Kernel Executivo (Executive Kernel)

É uma camada de execução que gerencia o agendamento, despacho de ferramentas, resolução de dependências, recuperação de falhas e segurança.

• LLM como Recurso Stateless: O LLM é invocado apenas em pontos discretos (planejamento, reflexão, agregação) e não tem visibilidade sobre os mecanismos de execução.
• Execução Baseada em Grafos (DAG): O LLM gera um grafo de dependências de chamadas de ferramentas. O kernel executa esses nós em "ondas" paralelas, resolvendo dependências e injetando parâmetros de dados estruturalmente (sem necessidade de loops de raciocínio sequencial para passar dados).
• Recuperação Estrutural: Se uma ferramenta falha, um "micro-planejador" tenta alternativas automaticamente antes de avaliar se a evidência é suficiente. O sistema não pede permissão ao usuário; ele persiste na execução.

B. Execução com Gate de Intenção (Intent-Gated Execution - IGX)

É um paradigma de segurança que impõe autorização no momento da execução, baseado em quatro variáveis independentes, nenhuma das quais é controlada pelo LLM:

1. Scope (Escopo): Lista de permissões de quais ferramentas o agente pode invocar.
2. Intent (Intenção): O "teto operacional" definido pela fonte do gatilho (ex: observador vs. operador humano), não pelo LLM.
3. Impact (Impacto): Classificação de impacto da ferramenta (ex: leitura=0, escrita=1, deleção=2), declarada pelo autor da ferramenta.
4. Clearance (Autorização): Autorização de nível de recurso delegada a endpoints HTTP externos (ex: políticas de AD, geofencing).

Mecanismo de Segurança: O kernel avalia essas variáveis em código compilado. Se uma chamada for bloqueada, o nó falha com um erro genérico. O LLM não vê o motivo do bloqueio, impedindo ataques adaptativos onde o agente tenta "provar" os limites da política.

Modos de Execução Adaptativa

O sistema suporta três modos para controle de granularidade:

1. Reflect: Pontos de verificação entre ondas de dependência. O sistema avalia resultados acumulados e replaneja se necessário.
2. nReflect: Reflexão disparada a cada $N$ conclusões de nós, desacoplando a frequência de avaliação da profundidade de dependência.
3. Orchestrator: Observadores leves por nó que podem injetar novos passos ou cancelar trabalho pendente em tempo real.

3. Principais Contribuições

1. Separação de Contexto e Redução de Tokens: Ao limitar o contexto visto pelo LLM em cada chamada (apenas a evidência da onda atual ou do nó específico), a complexidade de tokens cai de $O(n^2k)$ para $O(nk)$ ou $O(nkd)$.
2. Segurança Estrutural (IGX): A segurança é aplicada via código e variáveis externas, não via prompt. O LLM não pode contornar o gate, pois não vê as decisões de bloqueio.
3. Injeção de Dependência Estrutural: Os dados fluem entre etapas através de referências estruturais no grafo, eliminando a necessidade de loops de raciocínio sequencial para passar valores entre ferramentas.
4. Resiliência a Falhas: O sistema persiste através de falhas de ferramentas via replanejamento automático, em vez de delegar ao usuário ou desistir.

4. Resultados Experimentais

O KAIJU foi comparado com uma base ReAct (com chamadas de função paralelas) em 40 consultas de quatro níveis de complexidade e no benchmark GAIA.

• Latência e Desempenho:

  • Em consultas simples, o ReAct é ligeiramente mais rápido (sem overhead de planejamento).
  • Em consultas complexas e computacionais, o KAIJU (especialmente o modo nReflect) supera significativamente o ReAct.
    • Consultas Complexas: 9.5s (KAIJU) vs 28.9s (ReAct).
    • Consultas Computacionais: 25.2s (KAIJU) vs 43.7s (ReAct).
  • O KAIJU completou 100% das consultas computacionais, enquanto o ReAct falhou em 20% devido ao esgotamento do contexto.

• Qualidade e Confiabilidade:

  • O KAIJU evita o "atalho" onde o modelo abandona a pesquisa ao encontrar um erro de ferramenta. O ReAct tende a retornar conhecimento paramétrico (alucinado) quando uma ferramenta falha.
  • No benchmark GAIA (perguntas de texto), o modo DAG Reflect alcançou 15.7% de precisão (vs 12.6% do ReAct) e 21.1% em perguntas de nível 3 (as mais difíceis), onde o ReAct obteve 0%.

• Segurança: O gate de execução adiciona sobrecarga de sub-milissegundos e impede que o modelo aprenda ou explore os limites da política de segurança, algo impossível em loops conversacionais tradicionais.

5. Significado e Conclusão

O KAIJU representa uma mudança de paradigma na arquitetura de agentes LLM:

• De Conversacional para Estrutural: Move-se de um modelo onde o LLM controla tudo (e pode falhar ou ser enganado) para um modelo onde o LLM é um componente de um pipeline estruturado e seguro.
• Garantias Comportamentais: Oferece garantias de segurança e completude que não podem ser alcançadas apenas com prompting. A separação entre planejamento e execução impede que o modelo desista de tarefas complexas ou ignore políticas de segurança.
• Escalabilidade: A arquitetura permite que agentes realizem tarefas de investigação profunda e análise de dados em tempo real sem sofrer com o custo exponencial de tokens e a degradação de qualidade associada a conversas longas.

Em suma, o KAIJU demonstra que a execução de agentes autônomos complexos e seguros requer uma camada de kernel executiva que gerencia a lógica de controle, segurança e fluxo de dados, deixando o LLM focado apenas no raciocínio e planejamento dentro de contextos delimitados.