KAIJU: Separate the Decider From the Executor

ReAct agents have three structural problems that don't go away with better prompting.

In a single-agent ReAct loop, the reasoning is sequential. The model thinks one step at a time: thought, action, observation, repeat. Parallel tool calling exists at the API level, but the planning itself can't overlap with execution.

Context compounds with every step. Each iteration adds tokens. The window fills, and processing cost scales quadratically with length even when the growth itself is linear.

And there's no architectural barrier between what the model decides and what gets executed. If the model hallucinates a dangerous command, the only thing standing in the way is a prompt saying "be careful" or a human clicking approve.

I've built agents with all three problems. Retry logic, output validation, context trimming. It helps, but it patches symptoms without fixing the architecture.

The fix that keeps showing up in recent research is the same one software engineers have used for decades: separate the thing that decides from the thing that executes.

The model plans. A separate layer handles scheduling, tool dispatch, and access control. That separation addresses all three problems at once. The execution layer gathers data in parallel while the model plans the next step. It manages and compresses context independently, so the window doesn't fill up. And it enforces constraints before any action reaches the system.

Some recent work formalizes the security piece. Instead of binary allow/deny per tool, you gate execution on multiple dimensions: what's the scope of this action, what's the intent behind it, what's the potential impact, does it need external approval.

Take an agent that wants to run rm -rf ./data. Scope: filesystem write. Intent: cleanup. Impact: irreversible deletion. Approval: required. Three of four checks flag it. The action doesn't run.

A prompt is data the model processes. It can be overridden by other context, injected or not. An architectural constraint sits outside the model. It can't be reasoned away.

Parts of this are already shipping. Claude Code combines human approval (the Y/n on tool calls) with automated constraints: hooks that run before and after execution, allow-lists that pre-approve safe operations, a dedicated classifier that evaluates actions before they execute, and filesystem sandboxing. It's a hybrid, not pure automated gating, but it shows where things are heading.

We're moving from "trust the model" to "enforce it at the layer that wraps it." Right now most agent permission systems are binary. A tool is allowed or it isn't. Gating on scope, intent, and impact would be a real step forward.