stop-and-reassess

name

stop-and-reassess

description

After two failed attempts at the same problem, stop and diagnose before trying again — never make a third attempt built on the same assumption. Use this whenever an approach has failed twice in a row, whenever you notice yourself making similar edits, retries, or rewrites in a loop, and whenever the user says anything like "I've tried X several times and it still doesn't work", "still broken", "same error again", or "why does this keep happening". Trigger it even if the failures feel like near-misses — near-misses are exactly how loops sustain themselves.

Stop and Reassess

Two failures of the same approach are evidence about the approach, not bad luck. A third variation usually inherits the same hidden assumption, so it burns effort while feeling like progress. This is the logic behind stopping the line in lean manufacturing — halt at the defect and find the cause rather than pushing more units through — and behind Reflexion-style results showing that agents which verbalize why an attempt failed before retrying outperform ones that simply retry. The value comes from the diagnosis existing before the next attempt, not from trying harder.

Process

1. Count honestly. If the last two attempts at this problem shared a strategy and both failed, you are in a loop — treat the next move as blocked until step 4 is done.
2. Stop the line. Do not start attempt three, even a "quick tweak", because tweaks are how the shared assumption survives.
3. Write the diagnosis in words before acting: what did both attempts assume must be true? What did each failure actually show? What cause would explain both failures at once?
4. Choose a next step that differs in kind, not degree — it must attack the re-diagnosed cause, not re-run the old strategy with new parameters. If no such step exists, escalate: tell the user what was tried, what the shared assumption was, and what information or decision would unblock things.
5. Check the new attempt against the diagnosis: if it would still succeed or fail for the same reason as attempts one and two, it is variation three in disguise — go back to step 3.

What this looks like

• Writing: two rewrites of an intro still fall flat — stop polishing sentences; the diagnosis says the piece opens on the wrong question, so restructure instead of rewording.
• Research: two rounds of query tweaks return the same weak sources — stop refining keywords; the topic may live under a different discipline's vocabulary, so search from that field's terms.
• Code: two patches to the same function still fail the test — stop editing the function; the diagnosis points at a wrong fixture assumption, so verify the test's premise first.
• Operations: two escalating reminder emails get no reply — stop drafting a third; the channel or the recipient is wrong, so switch mediums or find the actual owner.

Output rules

• Never narrate your own diligence ("I carefully re-examined...", "as instructed, I stopped to reflect..."). The discipline shows in the changed approach itself, not in self-description.
• The diagnosis happens before or while producing the answer; only its results surface in the output, and only where they help — typically one line naming the abandoned assumption and why the new direction addresses it.
• Keep output proportionate to the task: a small fix gets a sentence of re-diagnosis, not an essay.
• When escalating, give the user the failed assumption and the open question — not a log of effort.

Grounding: Lean Enterprise Institute, Jidoka / stop-the-line (lean.org/lexicon-terms/jidoka); Shinn et al. 2023, Reflexion — verbal reflection on failure before retry (arXiv:2303.11366).