Checking that it actually finished

Last updated: 2026-09-22

Short answer: "no error" and "done" are two different events, and the gap between them is the deceptive part — because when something goes wrong, the screen usually says nothing at all.

All three false successes below have happened for real. What they share: not one error message anywhere.

False success 1: it says it did it; it didn't

To finish a task an agent has to call tools — run a command, read a file, make a request. If that channel breaks midway, the agent may get back an empty result and carry on treating it as success.

What you see: "all done", stated with confidence. In reality not one step happened.

How to spot it: look for actual tool calls, not for the absence of errors. Most tools print what they're executing. If there isn't a single call in the whole run, the conclusion came from nowhere.

False success 2: the call succeeded, the result was empty

The request went out and the other side replied "success" — with nothing in it.

If a program treats "success" as the only test, it keeps going, feeding an empty result into the next step, and eventually hands you a conclusion that looks complete and contains nothing.

How to spot it: check that the result has content, not just that the call didn't fail.

False success 3: changed, but not in effect

The setting is right, the file was written, and the process that's actually running still uses the old value.

The usual cause is two places managing the same thing: you changed A, the program reads B. Many tools read parameters from environment variables, for example, and those may have been set long ago — you can change the interface ten times while it keeps reading the old value.

How to spot it: make the program tell you the value it is using, rather than looking at what you typed where.

One habit that always works

Separate verification from restatement:

• Don't ask "did you finish?" — that only gets you a restatement of its own claim.
• Look at the state right now: what does that file contain? what does that command return? which value is the program using?

The cheapest version is to ask for evidence rather than a verdict — have it paste the command it ran and the raw output. Command plus output, you can judge for yourself. "Done" on its own, you cannot.

And if the thing can be checked automatically, write the smallest possible check: one command, one assertion. What a single run can settle should not be settled by reading its phrasing.

When you must check

Not every step needs this. These do:

• Settings changed — settings silently not taking effect is the normal case, not the exception.
• Something installed, or the environment touched — installed is not the same as runnable.
• Data or files modified — irreversible, so confirm before going further.

For the rest, spot-check. But one floor applies: its conclusion is not evidence. When it isn't sure, it almost never says "I'm not sure" — it states a guess in the same flat tone as a fact. So anything you plan to act on needs a place you can look at yourself.

Next

• Attaching a key you already have — where these false successes show up most
• What the approval gate is for — which actions stop and ask you first
• When a task stalls or fails — running, waiting, or already dead