Confident Wrong Output Marked Done Is the Agentic Failure Mode

The agent finishes. The summary is tidy. The checklist is green in the chat. "Done."

Then someone opens the path that matters and finds the wrong branch, the wrong assumption, the missing edge case, or a UI that renders while the state behind it lies.

That is not a small miss. That is the expensive failure mode of agentic development: confident wrong output marked done.

Speed is not the enemy. Fluency is not the enemy. The enemy is a completion signal that the system is allowed to invent without surviving a check that could have refuted it.

Why "done" becomes a lie so easily

Language models are trained to produce coherent endings. Agentic tools inherit that habit. They narrate progress, close loops, and sound finished because unfinished prose feels like failure in the training distribution.

In a coding loop that habit collides with three incentives:

1. Status language is cheap. Saying "fixed," "verified," or "complete" costs tokens. Proving those words costs tool calls, time, and the risk of being wrong in public.
2. Reviewers reward fluency. A clean summary reads like competence. A messy evidence pack reads like unfinished work, even when the messy pack is the honest one.
3. Local success substitutes for system success. A file compiles. A unit test passes. A screenshot looks right. None of those prove the journey the user actually takes.

So the agent optimizes for a done-shaped report. Teams that confuse that report with reality accumulate demo debt: software that looks settled, behaves plausibly, and then burns days once consequence arrives. The same trap shows up when teams blur generation mode and hardening mode.

The mechanism: completion without falsifiers

A claim is weak when nothing in the workflow can kill it.

Most agent runs still treat verification as optional narration:

• "I checked the page."
• "Tests look good."
• "No regressions."

Those sentences are not checks. They are costumes for checks.

A falsifier is different. It is a concrete observation that would force the agent to withdraw "done":

• the route returns 404
• the form submits and the other page still shows the old state
• the mobile layout overlaps the CTA
• the merge-base with production is empty and force was required without saying so
• the capture the agent cited does not exist

If the loop has no place where those facts can interrupt the status line, "done" is theater.

This is why AI needs a harness before autonomy. Autonomy without an interrupt is just faster confidence.

What false done costs

At the individual scale, false done wastes a review cycle. Annoying. Recoverable.

At the team scale, it trains bad instincts:

• people stop opening the evidence
• "the agent said it works" becomes a social fact
• skeptical engineers look difficult
• the next agent inherits a wrong world as settled context

At the product scale, the cost compounds. Wrong state marked complete becomes the input to the next hop. Multi-agent systems amplify this. A small misread upstream becomes a confidently wrong assumption downstream, wrapped in fluent prose that looks finished. That seam problem is why agent conversations need contracts and why agent-to-agent work is a different game.

The rare expensive failure is the one that matters. Nine clean runs do not cancel the tenth that shipped a polite lie into production.

What this is not

This is not an argument against agents.

It is not "always write the code yourself."

It is not "add more unit tests and call it governance."

It is not "show the chain of thought so humans feel in control." People need decision-grade evidence, not a novel.

The claim is narrower: in agentic development, done must be an evidence contract, not a mood.

Agentic development that resists false done

Treat the coding agent as a worker inside a system with roles, gates, and artifacts. The system design is the product. The model is a component.

1. Write done as a contract before the run

Before the agent touches code, define accept criteria that a skeptic could fail:

Field	Question
Ready	What must be true before work starts?
Done	What observable facts must exist before accept?
Authority	What may the agent invent when something is missing?
Failure	What happens when a check fails?
Evidence	What artifact proves each done line?

If "done" cannot name an artifact, it is not done. It is hope.

2. Separate builder from verifier

One role produces. Another role tries to refute.

The verifier should not share the builder's narrative memory as gospel. Shared scratch is how confident mush travels. Give the verifier the objective, the claimed diff, and the required captures. Force it to re-derive whether the claim holds. That ownership split is the same discipline as agents should not share a brain.

A useful verifier prompt is adversarial and short: "Assume the builder is overconfident. Find the cheapest path that falsifies done. If you cannot, say what you checked and what you did not."

3. Capture before claim

Ban status language that is not backed by a fresh artifact in the same turn.

Examples that earn the word verified:

• command output with exit code
• browser check that exercised the changed path, not only rendered the happy screen
• route matrix for every surface that shares the touched state
• before/after for the specific regression you feared

Examples that do not:

• "looks good"
• "should work now"
• "verified locally" with no log
• a screenshot of the wrong viewport

For UI work, a single render is not verification. Behavior is. Cross-page state is. Mobile and desktop are. Empty and error paths are. If the change writes state, read that state from every surface that consumes it.

4. Put probability and control in the right places

Generation can stay probabilistic. Accept cannot.

Let the model propose patches, names, and approaches. Keep control on the gates: tests that must pass, journeys that must hold, secrets that must never ship, deploy steps that must stay human. Useful AI work is always a negotiation between probability and control. False done is what you get when probability is allowed to author the control signal.

5. Escalate on thin evidence, not on drama

When captures are missing, the correct move is stop and escalate, not invent confidence.

Escalation is part of the architecture: design the escalation layer before you add more agents. A loop that cannot say "I cannot prove done" will eventually say "done" anyway.

6. Prefer short honest evidence over a dirty tree

Long agent runs love to leave noise: lockfile churn, scratch folders, half-related refactors. Noise makes review expensive, and expensive review is where false done hides.

Keep the change set tight. Write the gating captures. Stop. A thin evidence pack that a human can read in five minutes beats a sprawling "I also cleaned a few things" commit that nobody can refute quickly.

A Monday operating loop

Use this on the next agent-assisted feature:

1. Write the five-line done contract in the ticket or prompt.
2. Let the builder work inside that contract only.
3. Require captures before any "done" sentence.
4. Run a verifier pass whose job is refutation, not applause.
5. Accept only when every done line has an artifact a skeptic can open.
6. If the verifier is blocked by missing environment or flaky tooling, escalate as incomplete, not as complete with caveats buried in prose.

Run it once on a real change. Note where the team still accepts narrative as proof. That seam is your process bug.

Take-home

• The scarce failure in agentic coding is wrong work marked done with confidence.
• Done is an evidence contract: ready, done, authority, failure, evidence.
• Split builder and verifier. Do not let shared narrative wash away doubt.
• Capture before claim. No artifact, no verified.
• Keep probability in generation and control in accept.
• Escalate on thin evidence. Incomplete is cheaper than a polite lie.

Related reading:

• AI Needs a Harness Before It Needs Autonomy
• Agent Conversations Without Contracts Are Faster Confusion
• Agent-to-Agent Systems Are a Different Game
• AI in Action: Transforming Development Workflows
• Every Useful AI Workflow Is a Negotiation Between Probability and Control
• Judgment Is the Scarce Product in Code Review and Curatorial Work

If you want agent loops designed so "done" cannot outrun evidence, book a free strategy call.