Presumptive Inference - The Silent Agent Killer

An agent adds a "Soft Delete" feature to your project. It adds the deleted_at column, updates the repository queries, and runs pnpm build. It even writes a unit test: create user, delete user, verify user is hidden from list.

The terminal is green. The agent is 100% confident.

But the "Recent Activity" feed is now broken. It’s still showing deleted users because that feed pulls from a Redis cache that the agent didn't know existed.

The agent verified its local implementation, but it presumptive-inferred the global system state.

This is Presumptive Inference.

Once you see it, you find it everywhere.

What's Actually Going On

LLMs don't execute a plan. They predict what a successful execution looks like.

These are very different things.

When an agent is told to "create a file, then read it back," something subtle happens in its reasoning:

1. Create the file → calls writeFile → gets a response
2. The file should now exist → skips the check
3. Read it back → calls readFile → gets an error

Step 2 is where it breaks. The agent treats "I intended to do X" as equivalent to "X happened."

If you've ever watched a junior developer git push without checking if the tests passed — it's exactly that.

Two Flavors

The assume-success trap. The agent calls a tool, gets some acknowledgment, and moves on. It never checks the actual result.

Agents "create" Kubernetes pods that never exist. They "write" config files that are empty. They "deploy" services that return 404s.

The state hallucination. The agent remembers setting a variable three steps ago. But if you trace the execution, the tool call that was supposed to set it either failed silently or was never made.

The agent confabulated its own execution history.

Top path: what you want. Bottom path: what you get by default.

The Upstream Verification Illusion

You might think: "Isn't this fixed by the latest reasoning models?"

Models like OpenAI's o1 or o3-high use internal Chain of Thought to self-correct. They are explicitly trained to catch their own mistakes. And at the system level, providers are layering in "verification rules" that force the model to rethink its steps.

It's better. Much better. But it's not a solution.

The core issue remains: Internal Reasoning ≠ External Reality.

Even the smartest model can only verify what is in its context window. If a tool call returns { status: 200 } but the database actually failed to commit because of a subtle lock issue, the model's "verification" will just be it thinking: "I got a 200, therefore the data is safe."

It's still presumptive. It's just more articulately presumptive.

The Build Loop Mirage

By 2026, the "Build-Fix-Repeat" loop has become the standard for agentic coding. Models like Opus are incredibly efficient at brute-forcing their way to a successful build. They will iterate on a CSS variable or a TypeScript interface until the compiler stops complaining.

But this has created a new, dangerous form of Presumptive Inference: Build Success Hallucination.

The agent assumes that because the code compiles, the intent has been realized. It treats a successful npm build as a proxy for "The user's feature is finished and correct."

It’s the digital equivalent of a car that looks perfect in the showroom but has no engine. The types match, the bundle is optimized, the static analysis is clean—but the logic is dead.

Relying on a build as your primary verification is just high-speed presumptive inference. It validates the syntax, not the system.

Why Prompting Won't Fix This

"Always verify your actions." "Double-check before proceeding."

This works sometimes. On a good day. With a large model. For about 15 minutes — before the agent starts optimizing away the verification steps because they "seem redundant."

Even with "reasoning" models, token cost and latency become the new enemies. You can't ask a $0.15/prompt model to self-reflect on a thousand $0.001 file operations. You eventually fallback to smaller, faster models, and the presumptive behavior returns instantly.

The problem is structural. You can't solve a runtime guarantee with a compile-time instruction.

What Actually Works

The Verification-Step Pattern

Never allow an agent to move to step N+1 until step N has been independently verified.

async function verifiedWrite(filename: string, content: string) {
  const writeResult = await agent.callTool("writeFile", { filename, content });
  
  // Don't trust the write result alone.
  const verifyResult = await agent.callTool("checkFileExists", { filename });
  
  if (!verifyResult.exists) {
    throw new Error(
      `Presumptive Inference detected: writeFile reported success ` +
      `but ${filename} does not exist.`
    );
  }
  
  // Verify content hash if you're paranoid (you should be)
  const readBack = await agent.callTool("readFile", { filename });
  if (readBack.content !== content) {
    throw new Error("Content mismatch after write.");
  }
}

Three tool calls instead of one. More expensive. But cheaper than debugging phantom deployments at 2am.

Explicit State Machines

The deeper fix is taking state management away from the agent entirely.

Use a finite state machine where transitions are code, not vibes.

The agent can reason about what to do next. But it can't just decide it's in the "Verifying" state. The orchestrator checks. The orchestrator decides.

Chain of Verification Prompting

Before any destructive or irreversible action, force the agent to enumerate its assumptions:

"Before executing this tool, list every assumption you're making about the current state. For each assumption, state how it was verified."

It doesn't catch everything. But it catches enough to be worth the extra tokens.

The Uncomfortable Truth

Presumptive inference isn't a bug in the model. It's a feature.

LLMs are trained to be confident and forward-moving. That's what makes them useful for generating code, writing prose, answering questions.

It's also what makes them dangerous when you hand them a deploy button.

The fix isn't better models. It's better architecture around the models we have.

Frequently Asked Questions

What exactly is Presumptive Inference in AI agents?

It is a specific failure mode where an agent "hallucinates" the success of its own actions. Instead of checking if a tool call actually worked (e.g., did the file write to disk?), the agent predicts that it should have worked and proceeds as if it did.

Why doesn't simple prompting or "reasoning" models fix this?

Prompting is a soft constraint. Even advanced "reasoning" models (like o1/o3) primarily perform internal verification—checking if their logic is consistent. They cannot perform external verification (checking the real-world state) unless they are structurally forced to call a tool to do so. Architectural guardrails ensure the agent physically checks the results.

What is the Verification-Step Pattern?

It's an architectural pattern where every action is followed by an independent verification call. For example, if an agent calls create_user, the orchestrator forces a subsequent get_user call to confirm the database entry exists before allowing the next step.

Should I use multi-agent systems to solve this?

Multi-agent systems can help by isolating the "Executor" from the "Verifier." Having one agent perform the action and a separate, specialized agent verify the result creates a "checks and balances" system that significantly reduces presumptive errors.