The Problem With AI Agents Isn’t Execution. It’s That Nobody Checks What’s Already True.

Execution agents do the work. State agents decide whether the work still needs doing.

There’s a pattern showing up across every team that’s started running AI coding agents seriously. The agent does the work. The agent opens the PR. And then someone notices the work was already done two weeks ago in a different branch.

Or the agent re-implements a path that was explicitly removed. Or it treats an out-of-date spec as ground truth and builds in the wrong direction for an hour before anyone notices.

The problem isn’t the model. The problem is that agents are being given tasks when they should be given state.

What’s missing is a different kind of agent: not an execution agent, but a state agent. An agent accountable for truth before action.

The Instruction That Changes Everything

There’s a small but significant difference between two ways of framing the same intent:

“Implement X”

“Ensure X is implemented”

The first is a task. The agent assumes X is missing and starts executing.

The second is an outcome. The agent has to check whether X already exists before deciding what to do.

That one word — ensure — forces a reconciliation step. Check the current state. Compare it against the desired state. Only act on the delta.

This sounds obvious. Very little agent tooling treats it as the default mode.

What Actually Happened

This isn’t theoretical. Running three parallel AI coding agents against a production codebase recently, one agent was dispatched to implement two tickets covering fields that make execution receipts reproducible and auditable — in plain English, the kind of data that lets you prove later exactly what ran, against what inputs, and what the outcome was.

The agent started by checking the git log on the target branch, inspecting the relevant code paths, and comparing the current implementation against the desired outcome. Then it stopped.

The work was already done. Both tickets had been merged in a previous PR several days earlier.

Rather than re-implementing and opening a no-diff PR, the agent reported what it found and stopped cleanly.

That’s the behavior you want. It’s also the behavior most agent setups don’t produce, because they’re built around task execution, not state reconciliation.

Why Agents Default to Execution

The current generation of AI coding tools is built around a simple model: give the agent a task, the agent does the task. This works well for isolated, clearly bounded work where the state of the codebase is exactly what the agent expects.

It breaks down in any real development environment where:

• Multiple agents or developers are working in parallel

• Work has been partially completed by a previous session

• The spec describes intent but the codebase has already moved toward it

• A dependency was resolved elsewhere without updating the task

In these cases, a pure execution agent doesn’t just fail to help — it actively creates work. Duplicate implementations, conflicting branches, PRs that have nothing to compare, review cycles spent on work that shouldn’t have been done.

The fix isn’t smarter execution. It’s a step before execution that asks: what is actually true right now?

The State Agent

A state agent is an agent whose primary accountability is truth before action.

Before any execution happens, the state agent answers three questions:

What is the desired state?

What does the ticket, spec, or requirement say should be true when this work is done?

What is the current state?

What is actually true in the codebase right now? What’s been merged? What fields exist? What tests are passing? What branches are in flight?

What is the delta?

What’s the gap between desired and current? Is it zero (already done), partial (some work needed), full (nothing done yet), or ambiguous (needs a human decision)?

Only after that reconciliation does the state agent hand work to an execution agent — and only the delta, not the full original task.

This changes the execution agent’s job from “implement X” to “close this specific gap, given this specific current state, with these specific constraints.”

What This Looks Like in Practice

The pre-flight check that would have caught the already-merged work is simple:

1. Check recent commits on the target branch for the ticket IDs

2. Check whether the required fields/functions/tests already exist in the codebase

3. If the desired state is already satisfied: report evidence and stop

4. If partially satisfied: report what exists and only implement the missing delta

5. If ambiguous: surface the decision with options and a recommendation

A few checks, one decision. The cost is seconds. The saving is the review cycle, the duplicate PR, and the confusion about why two implementations of the same thing now exist.

The same pattern applies beyond already-merged detection. A state agent running before a security fix would check: how many handler sites does the fix need to touch? If the spec says eight and the codebase has nine, that’s a delta that needs a human decision before execution starts — not something an execution agent should resolve silently.

The Deeper Problem: Prompts Don’t Hold State

The reason this pattern hasn’t become standard is that most agent orchestration is built around prompts. You write a prompt, the agent executes against it, the prompt disappears.

Prompts are good at carrying intent. They’re bad at carrying state. They don’t know what changed since they were written. They don’t know what’s already true. They don’t update when a dependency gets resolved upstream.

State is durable. A prompt that says “implement feature X” becomes wrong the moment feature X is merged. The state — “feature X is not yet implemented on the target branch” — was true when the prompt was written and false when the agent ran.

The shift from prompt-driven to state-driven agent orchestration is roughly the same shift that happened in infrastructure tooling when Kubernetes replaced shell scripts. Shell scripts are imperative: do this, then this, then this. Kubernetes is declarative: here is the desired state, reconcile it continuously.

The agent equivalent is: here is the desired outcome, here is the observed current state, act only on the delta.

Some spec-driven tools are beginning to move in this direction — living specs that update as agents work are a step toward it. But a spec that updates is still not the same as a state that’s verified. The difference is whether the agent checks ground truth in the codebase before acting, or trusts that the spec is still accurate.

What Changes When You Add a State Step

Agents stop doing redundant work. If the desired state is already satisfied, the agent reports that and stops. This sounds minor until you’re running multiple agents in parallel across a large codebase.

Escalations become meaningful. When an agent does escalate to a human, it’s because there’s a genuine decision required — the codebase state doesn’t match the spec’s assumptions, or the delta is ambiguous. Not because the agent lost its place or needed reassurance.

The execution spec gets tighter. Instead of handing an agent a full task description, you hand it a bounded delta: this specific gap, in these specific files, against this specific current state. The agent’s context is smaller and more precise. The output is correspondingly more reliable.

The Practical Starting Point

You don’t need a new framework or a new tool to start using this pattern. The change is in how you structure the first step of any agent dispatch.

Before execution starts, run a state check:

• What does the target branch actually contain right now?

• Which parts of the desired outcome already exist?

• What’s the minimal change needed to close the gap?

Write that check as a required first step in your agent prompt. Make it explicit that the agent should stop and report if the desired state is already satisfied.

The agents that catch already-merged work, flag unexpected file counts, and avoid duplicate implementations aren’t smarter models. They’re agents that check state before they act.

The next step in agentic software development is not just better execution. It is reconciliation.

Execution agents do the work. State agents decide whether the work still needs doing.

This article is based on direct experience running parallel AI coding agents against a production codebase.