Skip to content

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

🕒 Published (v1): 2026-03-31 21:38 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

KAIJU introduces an Executive Kernel that decouples LLM reasoning from tool execution by having the model plan once (producing a dependency DAG), then handing scheduling, dispatch, failure recovery, and security enforcement to a kernel layer. A four-variable Intent-Gated Execution (IGX) gate—scope, intent, impact, and external clearance—enforces authorization in compiled code, structurally outside the model's observation. Token complexity drops from \(O(n^2 k)\) (ReAct) to \(O(nkd)\) or \(O(nk)\) depending on execution mode.

Problem

ReAct and its descendants keep the LLM coupled to execution mechanics, producing three compounding failures: (1) token context grows quadratically—a 7-tool task transmits ~63K tokens, an 18-tool task ~250K; (2) the model retains unilateral per-turn authority, so "always retry" prompt instructions cannot guarantee persistence; (3) tool safety enforced via prompts is structurally defeatable—Nasr et al. (2025) breach 12 LLM-level defenses with >90% success using adaptive adversaries who exploit the observable feedback channel from blocked calls.

Method

KAIJU defines two strict layers. The reasoning layer fires the LLM at three discrete points: (1) the planner, which receives the task and tool schemas and emits a dependency DAG with param_refs for field-level data flow; (2) reflection checkpoints, which evaluate batched evidence and may graft new nodes mid-flight; (3) an optional aggregator. The execution layer (the Executive Kernel) handles the DAG lifecycle: nodes fire when all depends_on references reach a terminal state, with parameters resolved from upstream JSON outputs at fire time via param_refs.

Three adaptive modes control reflection granularity: - Reflect: reflections inject at dependency-wave boundaries; \(O(nkd)\) tokens, \(d\) = dependency depth. - nReflect: reflections every \(N\) node completions, decoupled from graph structure. - Orchestrator: a lightweight per-node observer can inject follow-ups, cancel pending work, or trigger reflection; highest quality, \(O(nk)\) token growth.

The IGX gate enforces four independent variables before every tool dispatch—regardless of whether the call was planned, replanned, or observer-injected:

\[t \in S,\quad I(t, p) \leq \min(\sigma,\, c_s),\quad C(t, p, u) = \text{allow}\]

where \(S\) = scope (allowlist), \(I\) = impact (integer, declared per-tool at compile time), \(\sigma\) = intent ceiling (set by the trigger source, not the LLM), and \(C\) = external HTTP clearance endpoint. Blocked nodes fail with a generic error; the reflection sees "node failed," not the rejection reason, removing the adaptive probe surface.

Key Contributions

  • Two-layer architectural separation: reasoning layer is a stateless resource; execution layer owns all scheduling, dependency resolution, failure recovery, and security.
  • Intent-Gated Execution (IGX): four-variable gate evaluated in compiled code, structurally isolated from LLM observation—no single compromised variable defeats the gate.
  • Structural dependency injection via param_refs: field-level data flow declared at plan time, resolved at fire time, eliminating sequential reasoning loops for data passing.
  • Three adaptive execution modes (Reflect / nReflect / Orchestrator) with \(O(d)\) wall-clock latency and bounded per-call context.
  • Micro-planner for scoped failure recovery: grafts replacement subgraphs on failure without full replanning; preserves node immutability and audit trail.
  • Delegated resource clearance: domain-specific authorization delegated to external HTTP endpoints; unreachable endpoints default to deny.
  • Preemption via interjection nodes: operator messages enter as reflection checkpoints, gating pending work without breaking the execution layer abstraction.

Results

  • Running example (5-tool security audit): ReAct with parallel function calling—9 LLM calls, 14 tools, 64.5 s. KAIJU (Reflect mode)—4 LLM calls, 10 nodes, 41.8 s (35% faster), with bounded per-call context (never exceeding 6.2K tokens vs. growing to 6.2K cumulatively in ReAct).
  • Speedup vs. sequential ReAct: authors observe ~3.7Ă— on simple tasks (matching LLM Compiler), 7Ă— on complex queries, up to 18Ă— on highly complex queries.
  • Token complexity: \(O(n^2 k)\) (ReAct) → \(O(nkd)\) (Reflect) or \(O(nk)\) (Orchestrator).
  • Baseline comparison (multi-agent): CrewAI / AgentArch achieve only 35.3% success on complex enterprise tasks with 6.3% reproducibility (Bogavelli et al. 2026); KAIJU avoids agent-persona coordination overhead.
  • Safety baselines: Progent achieves 0% attack success on AgentDojo via argument-level policy but remains in the conversational loop; CaMeL achieves provable guarantees on 77% of AgentDojo tasks via data-flow separation. KAIJU IGX is structurally complementary to both.

Limitations

  • Planning overhead yields a latency penalty on simple queries relative to direct ReAct.
  • Structural advantage emerges only at moderate-to-high task complexity; the system converges with ReAct at a mid-complexity crossover point.
  • The planner can under-plan (demonstrated in the running example), requiring the reflection loop to compensate—this introduces non-determinism in the number of LLM calls.
  • Interjection (human preemption) narrows the layer separation: the operator message enters the execution layer, though it is mediated by a reflection checkpoint rather than injected directly.
  • The paper text is truncated before the full Limitations section (Section 8), so some stated limitations may be omitted here.
  • No evaluation on standardized agentic benchmarks (e.g., AgentDojo, WebArena) beyond the running example; comparisons to LLM Compiler and others are informal.

Relevance to Harnesses / Meta-Harnesses

KAIJU is directly a meta-harness architecture: it wraps any LLM agent in a kernel that imposes execution policy, context management, and security enforcement without modifying the model or its prompts. The three execution modes (Reflect / nReflect / Orchestrator) are essentially configurable harness policies that trade latency for oversight granularity—a design pattern transferable to any harness that must govern agent behavior at runtime. The IGX gate is a formal instantiation of what harness systems typically enforce informally via prompts, offering a concrete template for structurally sound tool-authorization in meta-harness design. The bounded-context insight—that harnesses can prevent quadratic token growth by staging LLM calls over live DAG execution rather than accumulating conversation history—is a key architectural lesson for scaling agentic pipelines.