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

Dit artikel introduceert KAIJU, een systeem dat de uitvoering van LLM-agenten ontkoppelt van de redeneringslaag via een Executive Kernel en Intent-Gated Execution (IGX) om parallelle verwerking, betere beveiliging en schaalbaarheid te realiseren.

De kern

🦖 KAIJU: De Regisseur die de Acteurs niet Laat Doen Wat Ze Willen

Stel je voor dat je een grote film moet maken. Je hebt een briljante regisseur (de AI) die een geweldig script schrijft, maar die regisseur is ook een beetje onvoorspelbaar. Hij kan soms vergeten wat hij beloofde, hallucineren dat hij een explosie kan maken terwijl hij dat niet mag, of hij kan de camera te lang vasthouden waardoor de film te duur wordt.

Tot nu toe werkten AI-agenten (zoals die in ChatGPT of Claude) als een eenmansshow: de regisseur schrijft een zin, roept een acteur op, kijkt naar het resultaat, schrijft de volgende zin, en zo verder. Dit heet ReAct.

KAIJU is een nieuw systeem dat deze chaos oplost. Het introduceert een uitvoeringskern (een Executive Kernel) die de regisseur en de acteurs scheidt. Hier is hoe het werkt, vertaald naar alledaagse beelden:

1. Het Probleem: De "Gespreksbubbel" die te vol raakt

Bij de oude manier (ReAct) moet de regisseur bij elke stap het hele script van de vorige scènes meenemen.

• Metafoor: Stel je voor dat je een gesprek voert, maar bij elke zin die je zegt, moet je ook de volledige tekst van het gesprek van gisteren, eergisteren en de week daarvoor opnieuw voorlezen.
• Gevolg: Bij complexe taken wordt dit gesprek zo lang en duur dat de AI het verliest, dure fouten maakt, of simpelweg "opgeeft" omdat het te veel tekst is om te verwerken. Ook is de AI te machtig: als hij zegt "ik ga een gevaarlijke knop indrukken", doet hij het vaak gewoon, tenzij je hem heel streng in de gaten houdt (wat hij soms negeert).

2. De Oplossing: KAIJU als een Strakke Productie

KAIJU splitst het werk op in twee lagen:

1. De Regisseur (LLM): Deze denkt alleen na over het plan. Hij maakt een kaart (een grafiek) van wat er gedaan moet worden, maar ziet niet hoe het gebeurt.
2. De Uitvoeringskern (KAIJU): Dit is de strenge producer. Hij pakt het plan, regelt de acteurs, zorgt dat ze niet in de weg lopen, en controleert of alles veilig is.

De Regisseur ziet de producer niet. Hij weet niet of een actie wordt goedgekeurd of geweigerd. Hij maakt gewoon een plan. De producer voert het uit.

3. De "Intent-Gated Execution" (IGX): De Vierde Poort

Voordat er ook maar iets gebeurt, moet elke actie door een veiligheidspoort. Dit is geen gesprek; het is een harde code-check. De poort kijkt naar vier dingen:

1. Scope (Wie mag wat?): Mag deze AI überhaupt deze tool gebruiken? (Bijv. mag hij alleen zoeken, maar niet wissen?)
2. Intent (Wie vraagt het?): Vraagt een simpele gebruiker dit (laag risico) of een beheerder (hoog risico)?
3. Impact (Wat is het effect?): Is het een "lezen"-actie (veilig) of een "wissen"-actie (gevaarlijk)?
4. Clearance (Uitwendige toestemming): Is er een externe goedkeuring nodig? (Bijv. "Mag deze drone in dit luchtruim vliegen?").

De magische truc: Als de poort "Nee" zegt, ziet de AI dit niet als een "Nee" van de poort. Hij ziet het gewoon als een "Foutje". De AI kan dus niet proberen de poort te omzeilen door te zeggen: "Oh, ik probeer het nog een keer met andere woorden." De poort is onzichtbaar en onneembaar voor de AI.

4. De Drie Manieren van Werken (De "Modes")

KAIJU kan op drie manieren werken, afhankelijk van hoe complex de taak is:

• Reflect (De Golfbewaker): De AI werkt in golven. Eerst doet hij een reeks taken tegelijk (zoals het checken van de weer, de nieuws en de mail). Dan stopt hij even, kijkt naar de resultaten, en beslist: "Moet ik nog meer doen?" Pas dan gaat hij naar de volgende golf. Dit voorkomt dat het gesprek te lang wordt.
• nReflect (De Teller): Hij werkt in blokken. Bijvoorbeeld: "Na elke 5 taken kijk ik even of het nog goed gaat." Dit is snel en efficiënt.
• Orchestrator (De Regisseur op de set): Hier kijkt er een kleine "observer" naar elke individuele actie terwijl deze gebeurt. Als een actie mislukt, wordt er direct iets anders geprobeerd. Dit is het meest nauwkeurig, maar ook het duurst.

5. Waarom is dit beter? (De Resultaten)

In de tests bleek KAIJU superieur aan de oude manier:

• Snelheid bij complexe taken: Omdat KAIJU dingen parallel doet (zoals een orkest dat tegelijk speelt in plaats van één voor één), is het veel sneller bij moeilijke vragen. De oude manier (ReAct) raakt hierdoor in de problemen omdat het script te lang wordt.
• Geen "opgeven": Als een AI bij de oude manier een tool niet kan gebruiken, zegt hij vaak: "Oké, ik ga het maar raden." KAIJU probeert het automatisch op een andere manier of zoekt een alternatief. Hij geeft niet op.
• Veiligheid: Omdat de AI de veiligheidsregels niet kan zien of bespotten, is het veel moeilijker om de AI te misleiden om gevaarlijke dingen te doen.

Samenvatting in één zin

KAIJU is als het verschil tussen een regisseur die zelf alle acteurs aanstuurt (en soms de regels negeert) en een regisseur die een strak plan schrijft voor een onafhankelijke, onneembare producer die zorgt dat alles veilig, snel en volgens plan gebeurt, zonder dat de regisseur weet of hij een "nee" heeft gekregen.

Het maakt AI-agenten sneller, veiliger en betrouwbaarder, vooral bij moeilijke taken waar veel stappen nodig zijn.

Technische samenvatting

1. Het Probleem

Huidige autonome agents die gebaseerd zijn op Large Language Models (LLM's) en het ReAct-paradigma (Reasoning + Acting) gebruiken, ondervinden drie fundamentele beperkingen naarmate taakcomplexiteit toeneemt:

1. Lineaire Latentie en Kwadratische Contextgroei: Bij elke redeneerbeurt (turn) moet de volledige conversatiegeschiedenis worden doorgegeven. De token-kosten groeien kwadratisch ($O(n^2k)$), wat leidt tot contextoverbelasting, lege output of degradatie van de kwaliteit bij complexe, multi-stap taken.
2. Eenzijdige Autoriteit en Betrouwbaarheid: Het model behoudt volledige controle over toolgebruik. Als een tool faalt, kan het model rationeel besluiten om de taak te verlaten, terug te vallen op parametrische kennis (hallucinaties) of de gebruiker om hulp te vragen. Dit ondermijnt de betrouwbaarheid van het systeem.
3. Kwetsbaarheid voor Prompt-injectie en Hallucinaties: Veiligheid wordt vaak afgedwongen via prompt-instructies (bijv. "gebruik geen destructieve tools"). Deze instructies kunnen worden genegeerd door hallucinaties, prompt-injectie of contextoverloop. Er is geen structurele "failsafe".

Bestaande oplossingen zoals LLM Compiler (parallelle DAG-uitvoering) of LangGraph lossen deze problemen slechts gedeeltelijk op, omdat het LLM-model vaak nog steeds gekoppeld blijft aan de uitvoeringsmechanieken of de veiligheid beperkt blijft tot menselijke tussenkomst.

2. Methodologie: De KAIJU Architectuur

KAIJU introduceert een systeemniveau-abstractie die de uitvoering van agent-workflows volledig ontkoppelt van de redeneringslaag (het LLM). Het systeem bestaat uit twee lagen:

• Redeneringslaag (Reasoning Layer): Het LLM fungeert als een stateless resource die alleen wordt aangeroepen om een plan te maken (dependency graph), te reflecteren op voortgang, of resultaten te synthetiseren. Het heeft geen zicht op de uitvoeringsmechanieken.
• Uitvoeringslaag (Execution Layer): Een "Executive Kernel" die verantwoordelijk is voor scheduling, tool-dispatch, afhankelijkheidsoplossing, foutherstel en veiligheidsafdwinging.

Kerncomponenten:

• Intent-Gated Execution (IGX): Een beveiligingsparadigma dat uitvoering alleen toestaat op basis van vier onafhankelijke variabelen:
  1. Scope: Welke tools zijn toegestaan (allowlist).
  2. Intent: Het operationele niveau van de huidige taak (bepaald door de trigger, niet het LLM).
  3. Impact: De potentiële schade van de tool (bepaald door de tool-auteur).
  4. Clearance: Externe autorisatie via HTTP-endpoints (bijv. voor domeinspecifieke regels).
     Belangrijk: Het LLM ziet niet of een tool is geblokkeerd; het ontvangt alleen een generieke foutmelding. Dit voorkomt adaptieve aanvalspaden.
• Graph-based Workflow: Taken worden omgezet in een Directed Acyclic Graph (DAG). Tools worden uitgevoerd in "golven" (waves) op basis van afhankelijkheidsoplossing, niet op basis van sequentiële redeneerturns.
• Drie Adaptieve Uitvoeringsmodi:
  1. Reflect: Reflectie-punten tussen afhankelijkheidsgolven.
  2. nReflect: Reflectie na elke N voltooide nodes (balans tussen snelheid en controle).
  3. Orchestrator: Een lichte "observer" die elke individuele resultaat beoordeelt en direct kan ingrijpen (injectie van nieuwe nodes).
• Structurele Foutherstel: Als een tool faalt, activeert een "micro-planner" automatisch alternatieve benaderingen binnen de graph. Het systeem vraagt niet om menselijke toestemming en geeft niet op, maar probeert de taak te voltooien via replanning.

3. Belangrijkste Bijdragen

1. Ontkoppeling van Planning en Uitvoering: Het LLM plant alleen; de kernel voert uit. Dit elimineert de noodzaak voor het LLM om de volledige context van vorige tool-resultaten te dragen bij elke stap.
2. Structurele Veiligheid (IGX): Veiligheid wordt afgedwongen in gecompileerde code via de vier variabelen, niet via prompts. Het LLM kan de veiligheidsbeleid niet omzeilen omdat het de beslissingen niet ziet.
3. Parallelliteit en Schaalbaarheid: Door tools in golven parallel uit te voeren en afhankelijkheidsinjection te gebruiken, daalt de token-complexiteit van $O(n^2k)$ naar $O(nk)$ of $O(nkd)$.
4. Verificatie en Herhaalbaarheid: De graph-structuur zorgt voor verifieerbare uitvoeringseenheden en maakt het mogelijk om de workflow dynamisch aan te passen (nodes toevoegen/verwijderen) zonder het LLM te betrekken bij de logica.

4. Resultaten en Evaluatie

De auteurs hebben KAIJU vergeleken met een ReAct-baseline (met parallelle functiedieping) op diverse benchmarks:

• Latentie:
  • Bij simpele queries is ReAct iets sneller (geen planner-overhead).
  • Bij complexe en computationele queries (bijv. astronomische data-analyse) overtreft KAIJU (met name de nReflect-modus) ReAct aanzienlijk: 9.5s vs 28.9s voor complexe taken en 25.2s vs 43.7s voor computationele taken.
• Betrouwbaarheid en Voltooiing:
  • KAIJU voltooide 100% van de computationele benchmarks.
  • ReAct faalde bij 2 van de 10 complexe queries door contextoverbelasting (leeg resultaat).
  • KAIJU voorkomt dat het model "afkapt" en terugvalt op parametrische kennis; het blijft zoeken tot de taak voltooid is.
• Kwaliteit van Output:
  • Op de GAIA-benchmark (127 tekstvragen) behaalde KAIJU een hogere algehele nauwkeurigheid (15.7% vs 12.6%) en een lagere latentie.
  • Op de moeilijkste vragen (Level 3) scoorde KAIJU 21.1% tegenover 0.0% voor ReAct.
• Token-efficiëntie: Door de context per LLM-aanroep te beperken tot de huidige golf van resultaten, wordt de totale token-kost drastisch verlaagd.

5. Betekenis en Conclusie

KAIJU vertegenwoordigt een fundamentele verschuiving in de architectuur van LLM-agents: van een conversational loop (waarbij het model alles regelt) naar een systeemgestuurde uitvoering met een strikte scheiding van verantwoordelijkheden.

• Veiligheid: Het biedt structurele garanties die niet afhankelijk zijn van prompt-engineering, wat cruciaal is voor enterprise- en veiligheidskritieke toepassingen.
• Schaalbaarheid: Het maakt complexe, multi-stap taken haalbaar zonder dat de contextlimieten van het model een bottleneck worden.
• Robuustheid: Door foutherstel te automatiseren en de "geen-opgeven"-logica structureel af te dwingen, worden agents betrouwbaarder voor real-world taken.

De paper concludeert dat hoewel er een initiële overhead is voor planning, de voordelen in parallelle uitvoering, contextbeheer en structurele veiligheid KAIJU superieur maken voor complexe, real-world agent-taken. Toekomstig werk richt zich op adaptieve planning (het overslaan van de planner bij simpele vragen) en semantische tool-routing.