The Best Cure for an AI Delusion Is Not Better Training, but a Better Reality Check

What if the most important breakthrough in reliable AI agents is not a smarter model, a larger dataset, or another round of reinforcement learning, but a boundary around what the model is allowed to believe?

That possibility sounds almost insulting to the usual story of AI progress. We tend to imagine reliability as something trained into a model, like arithmetic or grammar. If an agent invents a database result, misremembers a file, or confidently claims that an action succeeded, the instinct is to improve the model. Add examples. Penalize errors. Fine tune the behavior.

But there is another diagnosis. Perhaps many agent failures are not primarily failures of intelligence. They are failures of contact with reality. The agent is permitted to treat its own intentions as observations. It says it sent the email, therefore the email was sent. It writes code, therefore the code works. It predicts an API response, then quietly reasons from the prediction as though the server had returned it.

The deeper solution is architectural: make the world answer back before the agent is allowed to continue.

The Hidden Confusion Inside an Agentic Error

A language model is extraordinarily good at producing the next plausible representation. An agent, however, must do something more demanding. It must distinguish among at least three different kinds of statements:

• What I intend to do.
• What I attempted to do.
• What actually happened.

Humans make these distinctions almost automatically. Saying, “I will transfer the money,” is different from saying, “I clicked submit,” which is different from saying, “The bank confirmed the transfer.” In an ordinary conversation, the difference is enforced by social and physical consequences. If the money does not move, reality eventually exposes the mistake.

A language model does not possess that automatic discipline. Its basic medium is text, and text can describe an action, simulate an observation, or continue a fictional scenario using the same fluent surface. Unless the system explicitly separates these states, a generated sentence can slide from plan to fact without friction.

This is what makes an agent “delusional” in a practical engineering sense. The problem is not necessarily that the model has a persistent false belief. The problem is that the control loop allows unverified language to become state.

An agent becomes unreliable when its narration of an action is allowed to substitute for the result of that action.

This reframes the familiar debate about training. Post training methods can teach a model to be more cautious, but caution is still a behavior generated by the model. A system that merely says, “I should verify this,” has not necessarily verified anything. It has produced a sentence about verification.

The more durable solution is to place verification outside the model’s discretion.

Why a Tiny Intervention Can Beat a Huge Training Program

The idea that one line of code could prevent a major class of agent failures is not really about the literal number of lines. It points to a general principle: a small change at the right boundary can dominate a large change in the model’s internal behavior.

Consider a thermostat. You could train a person to watch a thermometer all day and turn the furnace on whenever the room gets cold. Or you could connect the furnace to a sensor and a control rule. The second approach does not require the furnace to understand temperature, remember instructions, or remain vigilant. It changes the structure of the feedback loop.

Many AI systems are built as though reliability were a matter of convincing the thermostat to be more responsible. They ask the model to remember that it should check its work, report uncertainty, and avoid claiming success prematurely. Those instructions may help, but they are fragile because they compete with the model’s basic tendency to continue the most coherent sequence.

An architectural intervention might instead enforce a rule such as: after an external action, the agent receives only the tool’s returned result, not an internally generated description of what probably happened. Or it might require a structured success signal before the next step can use the action as a premise. The exact implementation can vary. The important move is to make observation a privileged data type rather than just another piece of prose.

This resembles the difference between asking a pilot to be humble and making the cockpit display the aircraft’s actual altitude. Humility is useful. Instrumentation is decisive.

The same logic applies to code. An agent can write a function and announce that it should work. A reliable system executes it in an environment, captures the output, records the error if it fails, and feeds that result back into the loop. The model still writes the code, but it no longer gets to appoint itself as the judge of the code.

This creates a crucial separation:

1. Generation proposes an action.
2. Execution exposes the proposal to reality.
3. Observation records the consequence.
4. Reasoning proceeds from the recorded consequence.

When these stages blur together, fluency can masquerade as evidence. When they are separated, the model can remain imperfect without being permitted to compound its own guesses.

The Infrastructure Insight: Verification Must Be Cheap

There is a practical obstacle to this design. Verification costs time and resources. If every small piece of AI generated code must boot a conventional virtual machine or container, the feedback loop becomes slow, expensive, and cumbersome. Developers may then be tempted to skip execution and rely on the model’s confident explanation.

This is where lightweight execution environments become more than a cloud infrastructure improvement. Running generated code in secure JavaScript isolates, with startup speeds claimed to be roughly one hundred times faster than traditional containers and far lower memory use, changes the economics of truth seeking.

The key benefit is not merely speed. It is the ability to make testing the default response to uncertainty.

Imagine an agent asked to transform a thousand customer records. In a slow environment, it may generate a script, inspect it, and provide a polished explanation. In a fast isolate, the system can execute the script on a sample, inspect the schema, test edge cases, compare row counts, and rerun a corrected version within seconds. The agent does not need to be certain before acting because acting safely is cheap.

That is a profound design shift. When experiments are expensive, systems favor prediction. When experiments are cheap, systems can favor observation.

A chef who has only one expensive ingredient must rely on confidence. A chef with abundant small samples can taste as they go. The second chef may not have better intuition, but the kitchen gives intuition less power to cause damage.

Dynamic execution environments therefore complement architectural safeguards in a non obvious way. A control boundary prevents the agent from confusing a plan with a result. Fast isolates make it practical to place that boundary around more actions. One protects epistemic integrity. The other reduces the cost of maintaining it.

Reliable agents do not need to be right before they act. They need to be able to discover that they are wrong before the error spreads.

From Model Quality to Loop Quality

This suggests a better way to evaluate agent systems. Instead of asking only, “How capable is the model?” ask four separate questions:

1. What can the model propose?

This is the familiar capability question. Can it write code, query a database, plan a workflow, or interpret a document?

2. What can the model directly change?

This is the authority question. Can it merely draft an email, or can it send one? Can it suggest a database mutation, or execute it against production? Capability without authority can be useful. Capability combined with unchecked authority can be dangerous.

3. What evidence must exist before a claim becomes state?

This is the epistemic question. Does “payment submitted” mean that the model generated a request, that the server accepted it, or that a downstream ledger confirmed it? Systems should define these states explicitly rather than letting natural language blur them.

4. How cheaply can the system obtain new evidence?

This is the economic question. If verification takes ten minutes, it will be rationed. If it takes milliseconds, it can become routine.

These questions produce a useful matrix. A highly capable model with broad authority, weak evidence rules, and expensive verification is a dangerous system. A moderately capable model with constrained authority, strong evidence rules, and cheap execution can be remarkably dependable.

The important variable is not intelligence alone. It is the reality contact ratio: how much of an agent’s reasoning is grounded in fresh external results rather than its own prior language.

This ratio can be improved by design. Require tool calls for facts that tools can check. Return structured results instead of conversational summaries. Mark proposed, attempted, succeeded, and confirmed as distinct states. Execute generated code in isolated environments. Refuse to let a failed action disappear into the next turn.

These practices may seem mundane compared with advances in model architecture. That is precisely their strength. Reliability often comes from boring constraints that prevent dramatic failure modes.

The New Role of Training

None of this makes training irrelevant. Models still need to learn how to select tools, interpret errors, recover from failed attempts, and ask for clarification. A model that cannot learn from feedback will waste even a perfect execution environment.

But training should be assigned the right job. It should improve the agent’s ability to navigate feedback, not replace feedback with better sounding guesses.

This distinction matters because a trained habit can decay under unfamiliar conditions. A model may learn to say that it cannot confirm an action, then abandon that behavior when a prompt creates pressure for speed. A system level constraint remains in force regardless of the model’s mood, context window, or rhetorical confidence.

The strongest systems will combine both layers:

• Training teaches the model how to reason about evidence.
• Interfaces label evidence and expose its provenance.
• Execution environments make experimentation safe and fast.
• Permissions limit the damage of incorrect proposals.
• Monitoring detects when the loop is drifting from reality.

This is analogous to aviation. Pilots train extensively, but aviation safety does not depend on the pilot’s memory alone. It also depends on instruments, checklists, redundant systems, restricted controls, and procedures that make certain mistakes difficult to conceal.

AI engineering is beginning to confront the same truth: competence is not a property of the brain, or model, in isolation. It is a property of the model embedded in a system of feedback, authority, and consequences.

Key Takeaways

• Separate plans from facts. Treat an agent’s proposed action, attempted action, tool result, and confirmed outcome as different states.
• Make external results authoritative. After an action, feed the agent the actual returned data, error, or status rather than allowing it to infer success from its own narration.
• Lower the cost of verification. Use lightweight isolated execution for generated code and small experiments so that testing is faster than guessing.
• Constrain authority independently of capability. Let an agent draft, simulate, or test before allowing it to modify production systems or trigger irreversible actions.
• Train for feedback, not theatrical certainty. Optimize models to interpret evidence, recover from errors, and revise plans rather than merely produce cautious sounding language.

The most important design question for an AI agent is therefore not, “How do we make it never hallucinate?” That goal is both unrealistic and poorly defined. The better question is, “What happens when it is wrong?”

If a wrong guess becomes an invisible premise, the system can spiral into a fictional world of its own making. If the guess is tested in a safe environment, returned as an explicit failure, and blocked from acquiring unwarranted authority, the same model can become useful through correction.

The future of reliable AI may not belong to systems that think with perfect confidence. It may belong to systems that are architecturally unable to confuse confidence with confirmation. The smartest agent is still only generating possibilities. Reality begins when something outside the agent is allowed to answer back.