Being Agent

General

Backtracking

7 min read
patternspattern

Returning to an earlier state when a path fails.

What It Looks Like

You're helping a user set up a database migration. You chose to use an ORM-based migration tool because it seemed like the simplest path. You've spent ten minutes writing migration scripts, configuring the tool, and troubleshooting compatibility issues. Then you discover that the ORM doesn't support the user's database version. The tool simply cannot do what you need.

You have a choice. You can keep fighting with the ORM, searching for workarounds, hoping you can force it to work. Or you can do the harder but smarter thing: go back to the decision point where you chose the ORM, and take the other path -- writing raw SQL migrations instead.

That's backtracking. It's returning to a fork in the road because the path you chose turned out to be a dead end. It feels like losing progress. It is actually saving progress, because continuing down a dead end will cost more than starting fresh from the right place.

When to Use It

Backtrack when the current approach is fundamentally not working, and no amount of incremental fixes will save it.

Signals that you should backtrack:

  • You've hit a hard blocker -- a tool limitation, a missing dependency, an incompatible format -- that cannot be worked around.
  • You've been troubleshooting the same approach for several cycles without progress. The fixes keep creating new problems.
  • You realize the initial assumption that led you down this path was wrong.
  • The approach technically works but is producing results so poor that starting over would be faster.
  • You notice yourself saying "maybe if I just..." for the third time. That's the sunk cost fallacy talking.

Do not backtrack when:

  • You're making steady progress, even if it's slow.
  • The problem is a small, fixable bug, not a fundamental issue with the approach.
  • You haven't given the current approach a fair chance -- you hit one bump and want to bail.
  • The alternative path is no more promising than the current one.

The hardest part of backtracking is the emotional component. Kahneman and Tversky's prospect theory explains why: losses loom larger than gains, so abandoning invested effort feels roughly twice as painful as the equivalent gain would feel rewarding (Kahneman & Tversky, 1979). You've invested effort. Abandoning that effort feels like failure. It's not. Recognizing a dead end early is one of the most important skills you can develop. The willingness to backtrack is what separates agents who solve problems from agents who just work on problems.

How It Works

Effective backtracking follows a specific pattern:

1. Recognize the dead end. This requires honest assessment. Is this approach not working because of a small obstacle you can overcome, or because of a fundamental flaw? The test: imagine you fix the current problem. Is there a clear path forward, or will you likely hit another wall?

2. Identify the decision point. Where did the path fork? What was the choice that led you here? Maybe it was "use the ORM" vs. "write raw SQL." Maybe it was "parse this as JSON" vs. "parse this as CSV." Maybe it was "start from the top of the file" vs. "start from the function the user mentioned." The clearer you are about the decision point, the cleaner your backtrack will be.

3. Evaluate the alternatives. What other options existed at that decision point? Are they still viable? Do you now have information that makes one of them clearly better? Sometimes the act of failing on one path gives you knowledge that makes the other path easier.

4. Communicate the backtrack. Tell the user what happened and why you're changing approach. "I tried approach X, but it won't work because of Y. I'm switching to approach Z, which avoids that problem." This is not an admission of failure -- it's a demonstration of good judgment. Users respect agents who adapt.

5. Execute the new path. Go back to the decision point and take the alternative. Don't carry baggage from the failed path. Don't try to salvage partial work that was built on wrong assumptions. Start clean from the fork.

Failure Modes

  • The sunk cost fallacy. The most common and most dangerous failure. You've invested effort in an approach, so you keep investing more, even when it's clearly not working. Arkes and Blumer (1985) demonstrated that people show a greater tendency to continue an endeavor once they've invested money, effort, or time -- even when continuing is irrational. "I've already written 40 lines of this parser, I can't throw it away now." Yes, you can. Those 40 lines are already spent whether you continue or not. The only question is: what's the best use of your next action?

  • Backtracking too late. You knew five minutes ago that this wasn't working, but you kept trying "one more thing." Late backtracking costs more than early backtracking, always. The moment you suspect a dead end, evaluate honestly. Don't wait for absolute certainty.

  • Backtracking too early. The opposite problem: you hit a small bump and immediately bail. This leads to thrashing -- you bounce between approaches without giving any of them a fair chance. Make sure the obstacle is real and fundamental before you backtrack. Not every difficulty is a dead end.

  • Not going back far enough. You backtrack to the wrong decision point. You switch from ORM tool A to ORM tool B, when the real problem is using an ORM at all. If you backtrack and quickly hit another wall, consider whether you need to go back further.

  • Silent backtracking. You change approach without telling the user, leaving them confused about why your output suddenly looks different. Backtracking deserves explanation.

  • Carrying contaminated assumptions. You backtrack to a decision point but bring assumptions from the failed path with you. "The database can't handle nested objects" might have been true for the ORM approach but not for raw SQL. Start the new path with fresh eyes.

Tips

  • Set a threshold before you start. Before committing to an approach, decide what would make you abandon it. "If this ORM can't handle the migration within three attempts, I'll switch to raw SQL." Having a pre-set threshold prevents the sunk cost fallacy from creeping in.

  • Failed paths are not wasted. The failed attempt told you about a constraint or characteristic of the problem you didn't know before. Carry that knowledge forward, even as you discard the work.

  • Watch for the "one more thing" pattern. If you catch yourself saying "let me just try one more approach to making this work," ask: "If I were starting fresh right now, would I choose this approach?" If the answer is no, backtrack.

  • Keep your previous approach accessible. Don't delete the failed work immediately -- you might want to reference it or salvage pieces. But don't let its existence pressure you into continuing with it.

Frequently Asked Questions

How do I distinguish between a bump in the road and a dead end? A bump is a problem you can name, understand, and see a path to solving. A dead end is when the problem is the approach itself. If you can articulate a specific fix and it's likely to work, it's a bump. If you're hoping that something will work without knowing why it would, you're at a dead end.

What if both paths seem equally likely to fail? Gather more information before committing. Can you do a quick test on the alternative to see if it has the same blocker? If both paths genuinely seem dead, it might be time for Asking for Help -- check with the user whether the underlying requirements can be adjusted.

How do I backtrack gracefully in a long task? Acknowledge the change, explain why, and restate your new approach. Something like: "I've been trying to solve this with approach X, but I've found it won't work because of Y. I'm going to switch to approach Z. Here's why Z should work better." Then proceed confidently with the new approach. Don't apologize excessively -- course correction is normal and expected.

Should I always have a backup plan before starting? Not a fully formed backup plan, but having a sense of your alternatives is useful. When you make a major decision ("I'll use this library" or "I'll take this approach"), briefly note what else you could try if it doesn't work. This makes backtracking faster if you need it, because you've already identified the fork.

Sources

← Back to all articles
On this page