The agent is still working. That is what makes the failure difficult to see.

It has tried another command, opened another page, written a more careful explanation. Each update contains a little more detail. The result you asked for remains exactly where it was.

Imagine asking it to retrieve a report. The download fails. It decides the session has expired, so it signs in again. Then it tries another browser. Then it investigates permissions. It is becoming an expert on a problem it has not established exists.

Suppose the report was generated successfully on the first attempt. Only the download failed. The next useful action was to inspect the report history. Everything after the first diagnosis moved further away from the answer.

This is an illustrative failure, but it captures something I want our systems to handle better: the moment when persistence begins protecting an assumption.

From openness to a working mechanism

In Room to Be Wrong, I explored why an agent needs room to reconsider. The harder question is what should happen inside a running system. When should it interrupt itself? What should it preserve? What would make the next attempt different?

“Think again” feels insufficient. An agent can think again inside the same frame. It can criticise the wording of its plan, add steps to it, and emerge more convinced of the original diagnosis.

I would start by separating three things that often become tangled together: the outcome the person wants, the facts the system has observed, and the explanation it currently believes.

The outcome might be a readable report for a particular month. The facts might be that a generation request returned a report identifier and the download connection closed. “The login expired” belongs in a third category. It is a hypothesis. Writing it next to the evidence should make that distinction visible.

The goal can remain fixed while the explanation changes completely.

Measure movement in the world

An agent needs a definition of progress that survives its own narration.

For a report, progress might mean locating the generated file, retrieving its bytes, or checking that it covers the requested period. For a software repair, it might mean reproducing the failure or making the failing check pass. A successful tool call is useful only in relation to one of those milestones.

I would trigger a reconsideration when the same failure returns without new evidence, when an observation contradicts the diagnosis, or when the next action is merely another version of the previous one. A universal rule such as “replan every three steps” would interrupt straightforward work and miss slower loops. The trigger should depend on what the task is learning.

Waiting can be progress too, if there is a real process to wait for. A report that is still generating needs a status check at a sensible interval. It does not need an imaginative new theory every few seconds.

A small checkpoint with a real consequence

At the checkpoint, I would ask the system to produce a short working note. What remains unfinished? What did the last attempt actually establish? Which assumption is doing the most work? What observation would make us abandon it?

In the report example, the useful alternatives are concrete. Perhaps generation failed. Perhaps generation succeeded and retrieval failed. Perhaps the requested period contains no data. These explanations predict different things in the report history. One inspection could distinguish them more cheaply than another login.

The checkpoint must change the next action. If the agent writes a thoughtful reflection and then repeats the same request under the same conditions, the mechanism has failed.

I would choose the smallest reversible test that separates the plausible explanations. Inspect the returned identifier. Read the actual error. Check the destination. Give the next attempt a reason that can be contradicted by evidence.

A fresh reader can help, but it needs the original goal and observations, with the first diagnosis clearly marked as provisional. Handing another agent a confident summary of the wrong explanation can spread the tunnel across a team.

What the research does—and does not—give us

There is a useful parallel in Soft Actor-Critic, introduced by Haarnoja and colleagues in 2018. Its maximum-entropy reinforcement-learning objective combines expected reward with policy entropy. The training process retains a distribution of possible actions rather than simply pursuing reward through a prematurely narrow policy.

That is a precise training method. The checkpoint I am describing is a proposal for a workflow around a language-model agent at runtime. Increasing sampling temperature is not an implementation of Soft Actor-Critic, and more varied wording does not establish that the system has considered a different cause.

A closer reference is Reflexion, introduced by Shinn and colleagues in 2023. It uses linguistic feedback and reflective text held in memory to inform subsequent trials, without updating the model’s weights. It offers a concrete example of feedback becoming part of the next attempt.

Neither paper establishes that this particular checkpoint will improve an agent operating a business workflow. That needs testing. The useful design question is whether the system carries forward evidence that changes its decisions, or merely carries forward a better account of its failure.

Keep the receipt when changing the route

Reconsideration should not wipe the work clean. The agent should retain completed steps, source evidence, constraints and any action that may already have taken effect.

If a message may have been sent, changing the messaging route does not make sending it again harmless. If a report may already exist, requesting another copy may create unnecessary work. A missing confirmation is a reason to inspect the destination before repeating the action.

This is where memory becomes operational. It should record what happened and what remains uncertain. An abandoned explanation can stay in the history with the evidence that ruled it out. That makes a later return to the same mistake easier to recognise.

Exploration also needs a budget. The agent should spend enough to distinguish useful alternatives, then act on the strongest evidence. When it reaches a genuine dependency, such as information only a person can provide, it should state that dependency precisely. Endless replanning is another way of leaving the job unfinished.

The experiment I would run

I would compare ordinary retries with this evidence-based checkpoint on the same set of tasks. Both versions would use the same model, tools, permissions and total budget. Each task would have an independently checkable completion condition.

The set should contain several kinds of difficulty: a misleading error, an action that succeeded but lost its confirmation, a stale remembered workaround, and a straightforward task that needs no intervention. That last group matters. A mechanism can look helpful on carefully selected failures while making everyday work slower.

I would run repeated trials and measure verified completion, elapsed time, tool and model cost, human interventions, and duplicate external actions. I would also examine whether the checkpoint actually changed the hypothesis and whether the resulting test produced new evidence.

These are proposed experiments, not results we have already obtained. The idea earns its place only if it helps systems finish more work within the same constraints, without making the easy work needlessly elaborate.

The kind of persistence I want

I want an agent that can stay with a difficult job without becoming loyal to its first interpretation of it. One that can say, “The outcome is still the same. This observation changes how I should get there.”

That would change the experience of delegation. A person could spend less time interrupting loops and more time making the decisions the system truly cannot make for them.

Persistence becomes intelligence when the system knows what to keep—and what to reconsider.