When Your AI Agent Goes Down the Wrong Path, Don’t Correct It Yet

When your AI agent heads down the wrong path, stop it, inspect the change, and decide whether to keep any of its work before you send another prompt. Don’t spend ten more turns trying to steer a session whose assumptions, tool output, and partial implementation are now all pointing in the same wrong direction.

Stop the loop before it earns more confidence

The tell is rarely a syntax error. It’s the moment the agent starts making internally consistent progress toward something you did not ask for: adding a cache when the bug is a permissions check, replacing a parser instead of fixing one call site, or pulling in a framework because it missed the project’s existing abstraction.

Interrupt it before approving its next write or command. Then take a two-minute inventory in the terminal, not in the agent transcript:

git status --short
git diff --stat
git diff --check
git diff -- path/to/the/file-you-care-about

git diff --stat tells you whether the blast radius is still one file or has become 37. git diff --check catches whitespace errors, but it does not tell you whether the design is sound; run the narrowest relevant test or typecheck after that. If the agent created untracked files, git status --short is the command that keeps you from forgetting them.

Before discarding anything, save the patch somewhere outside the conversation. This is cheap insurance when the first 80% of the edit was useful but the agent took a bad turn near the end:

git diff > /tmp/agent-wrong-turn.patch
git status --short > /tmp/agent-wrong-turn-status.txt

Now you can reset tracked changes with git restore --source=HEAD --staged --worktree . if you truly want a clean tree. That command does not remove untracked files, and it will overwrite uncommitted tracked work, so don’t use it as a reflex in a shared or already-dirty branch. The better default is to review first and restore only the files the agent touched.

Name the failure before choosing the next prompt

“You went the wrong direction” is feedback, but it’s too vague to repair a run reliably. Classify the failure in one sentence. That sentence determines whether you continue, restart, or change the guardrail.

• Wrong objective: the request was ambiguous or the agent optimized for an unstated goal. Example: “make it faster” became a database rewrite instead of removing one N+1 query.
• Wrong evidence: it read an obsolete test, a generated file, a misleading error message, or an outdated internal doc and treated it as the source of truth.
• Wrong constraint: it knew the goal but not a boundary such as “no schema migration,” “keep the public API stable,” or “do not touch generated code.”
• Wrong context: the conversation contains too much prior exploration, failed theories, or decisions from another task, so each new turn reinforces a stale story.

If it’s the first three, you may be able to continue after you supply the missing fact and make the next action small. If it’s wrong context, start a fresh task. Cline’s own task guidance makes this distinction explicitly: when it keeps going off track, create a new task rather than fighting a cluttered context; its file checkpoints and history are there so a new conversation does not require throwing away the work. Claude Code also exposes session continuation and resume controls, but resuming is useful only when the shared understanding is still an asset.

Restart with a contract the agent can test

A restart prompt should be shorter than the original transcript and more precise than “try again.” Give it the current state, the one outcome you want, boundaries it must not cross, and proof required before it edits. Make it earn write access by first reporting the plan and the files it intends to touch.

We are fixing an authorization regression in POST /v1/invoices.

Observed behavior: a user with role=viewer receives 201; expected 403.
Source of truth: tests/api/invoices.authorization.test.ts, especially the viewer case.

Constraints:
- Do not change the role model, database schema, or endpoint response shape.
- Do not edit generated files or package versions.
- Keep the change limited to the authorization path unless the test proves otherwise.

First: inspect the route, middleware, and named test. Explain the likely cause,
list the files you would change, and propose one validation command. Do not edit yet.

This does three practical things. It tells the agent which evidence outranks its guesses, turns “don’t refactor everything” into an explicit boundary, and gives you a review point before the first diff. If its plan names unrelated files, correct the plan while the cost is one message instead of a rollback.

For terminal agents, use the tool’s planning or approval mode for this phase. Claude Code supports starting in --permission-mode plan, and its non-interactive mode can cap work with --max-turns; both are useful when you want a bounded investigation rather than an open-ended repair loop. For your own agent harness, put approval at the tool boundary, not just in the system prompt: OpenAI’s agent guidance recommends pausing a run before sensitive tool calls and attaching validation to the tool that causes the side effect.

Keep the good half without adopting the bad theory

Sometimes the agent’s diagnosis is wrong but its mechanical work is useful: a missing test fixture, a correctly extracted helper, a reproduction script, or an error log that finally makes the failure obvious. Keep those artifacts deliberately. Apply only the hunks you understand from /tmp/agent-wrong-turn.patch, or use your editor’s hunk staging to retain the test while dropping the speculative implementation.

Do not ask the agent to “clean up its own mess” as the first recovery move. It often treats its earlier edits as constraints and produces a second layer of workaround code. Start the new task against the cleaned tree, then show it the saved patch only if you want it to evaluate a specific idea. Phrase that request as review, not implementation: “Assess whether this diff contains a safe partial fix; identify the exact hunks worth keeping. Do not modify files.”

Change the workflow if this keeps happening

Repeated wrong-path behavior is usually a workflow problem, not a prompt-writing problem. Give agents small, verifiable jobs: reproduce, locate the owning code, propose, edit, validate. A 20-file refactor can still happen, but it should arrive as a reviewed plan with checkpoints between phases, not as one unattended command loop.

Also reduce the permissions that make a bad theory expensive. Let an agent read broadly if that helps discovery, but require approval for writes outside the workspace, network access, package installation, migrations, destructive commands, and production-adjacent tooling. Approval prompts are annoying when they fire on every harmless test command; they are valuable when they turn “the agent believed something” into “you reviewed a concrete side effect.”

The recovery habit is simple: stop, preserve, classify, clean, restart with evidence and boundaries. Your agent does not need a motivational correction. It needs a smaller search space and a point at which you can say no before its next confident mistake becomes a diff you have to untangle.