Iteration vs Redirection Decisions

The core trade-off

Every troubled agent session presents the same question: continue iterating or start over?

The instinct is to continue. Work has been done. Context has been established. The agent seems close. Starting fresh means throwing all of that away.

This instinct is often wrong. Developers wait too long to restart. The cost of abandonment is visible and immediate; the cost of grinding forward in degraded context is hidden and usually higher.

Boris Cherny, creator of Claude Code, reports discarding 10-20% of sessions that "end up nowhere." That is not failure. That is resource management. Knowing when to abandon ship matters as much as knowing how to steer.

The sunk cost problem

The psychological pattern is the sunk cost fallacy: weighting decisions by past investment rather than future returns.

In agent sessions, the fallacy looks like continued prompting despite evidence of diminishing returns. The agent keeps failing to resolve an issue, but the developer persists because abandoning feels like wasting the last hour.

One developer describes it: "You're prompting and prompting again, your agent is completely lost. You realize you would have been done much sooner if you hadn't used AI at all, but you're in too deep by now. Surely by the next prompt it will finally do what you're asking for..."

That "surely by the next prompt" reasoning is the sunk cost fallacy in action. Past prompts do not increase the probability that the next one succeeds. Accumulated incorrect reasoning in context probably decreases it.

The antidote is mechanical: establish decision criteria before the session begins, then follow them regardless of how much time you have already spent.

The 30% context rule

One mechanical criterion: remaining capacity.

Restart when remaining context drops below 30% of maximum capacity. Below this threshold, the agent lacks room for the working memory needed to reason about complex problems.

Consider a 200,000 token context window. At 70% utilization, 60,000 tokens remain. That sounds like plenty, but large codebases can require 20,000 tokens just for relevant file context. Complex reasoning chains need another 10,000-20,000 tokens. Tool outputs from searches and file reads pile up fast.

At 80% utilization, 40,000 tokens remain. Margins are tight. At 85%, the agent starts trading off between retaining earlier context and processing new information.

Module 4 covered the 70% proactive compaction threshold. The 30% rule is about a different question: not when to compact, but when compaction is no longer enough.

Compaction preserves some context while reducing token count, but it also loses information. When compaction has already been performed and utilization still climbs toward 70% again, accumulated compression losses may have degraded context quality beyond recovery.

At 30% remaining, a fresh session with a handoff summary typically outperforms continued iteration in degraded context.

The 70/30 problem

Addy Osmani describes the "70% problem": AI gets 70% of code done rapidly, but the remaining 30%, the edge cases, security considerations, and integration details, takes as long as ever.

The percentages are approximate, but the pattern is consistent. Agent-assisted development accelerates the straightforward portions. The hard parts stay hard.

This creates a trap for iteration decisions. The session that reached 70% rapidly feels like it should finish quickly. The agent understood the requirements well enough to generate most of the code. But that same session may be poorly positioned to handle the remaining complexity.

The context is now packed with generated code. Error messages from failed tests pile up. Each fix attempt adds more reasoning chains. The agent may have committed to an architectural approach that makes the remaining 30% harder than it needs to be.

Sometimes the 30% is easier to complete in a fresh session focused specifically on the complex portions, treating the initial 70% as exploration that informed requirements rather than code to preserve.

Plan-then-execute as prevention

Boris Cherny calls plan-then-execute "probably the most important thing" in his workflow. The principle: don't let the agent start coding until the approach is agreed upon. Iterate on the plan first. Only then switch to execution mode.

This front-loads iteration where it costs least. Planning iterations consume minimal context. A few exchanges refining approach, scope, and constraints might use 5,000 tokens. The same refinement during implementation, with code diffs, error outputs, and fix attempts, might consume 50,000 tokens and produce worse results.

The Cherny workflow: start in Plan Mode, iterate until the plan is solid, then switch to auto-accept mode for execution. A good plan often enables the agent to complete implementation in a single pass. A poor plan leads to iteration during execution, which degrades context and reduces success probability.

Plan mode prevents many iteration versus redirection decisions by reducing the situations where that decision arises in the first place.

Decision thresholds

When prevention fails and the iteration question arises, explicit thresholds guide the decision.

The three-strike rule: if the same error appears three times despite correction attempts, the issue is unlikely to resolve through continued iteration. The context may contain incorrect reasoning that the agent cannot escape. Redirect.

Complexity escalation is another signal. If each fix attempt introduces more complexity rather than less, the approach itself may be wrong. Agents sometimes solve surface problems by adding layers that create deeper problems. When the codebase grows despite bug-fixing, redirect.

Contradictions indicate degraded context. If the agent contradicts its own earlier statements or forgets constraints established in the conversation, context degradation has progressed beyond recovery. Continuing will produce more contradictions. Redirect.

Circular reasoning means the agent has exhausted its understanding. If explanations begin looping, restating the same justification in different words without new information, further prompting is unlikely to produce insight. Redirect.

Finally, trust your gut. If you find yourself hoping the next prompt will work rather than expecting it to work, that emotional shift reflects accumulated evidence that the session has derailed. The pattern recognition generating that feeling is often right.

The redirect protocol

Redirection is not starting from zero. The failed session produced valuable information: what the agent struggled with, which approaches failed, what clarifications were needed.

Effective redirection captures this information in a handoff summary before starting fresh.

A handoff summary contains the original goal stated precisely, what was accomplished before derailing, what specifically caused the derail (the error, the confusion, the constraint that couldn't be satisfied), and any insights about approach that the failed attempts revealed.

This summary, provided at the start of the new session, gives fresh context everything needed to avoid repeating failures.

Previous session attempted to implement payment processing but
derailed on webhook signature verification. Three attempts to fix
the signature mismatch failed. The issue may be environment
variable loading order rather than signature logic.

This session: focus specifically on verifying environment
configuration before attempting signature validation. The
webhook handler code from the previous session is saved in
src/handlers/webhook.ts.backup if the signature fix succeeds.

The handoff costs maybe 200 tokens. It prevents repeating iterations that consumed thousands.

When to persist

Not every difficulty signals redirection. Some problems are genuinely hard and require sustained effort.

Persistence makes sense when progress is measurable. Each iteration brings the agent closer to the goal, even if not there yet. Test pass counts increase. Error messages change to reflect new failure modes rather than repeating. Code quality improves even if bugs remain.

Persistence also makes sense when the agent demonstrates understanding. Explanations are coherent. Corrections are applied accurately. The agent asks clarifying questions that reveal engagement with the problem rather than confusion about it.

Healthy context is another green light. Token utilization is below thresholds. No contradictions, no forgotten constraints, no circular reasoning.

Finally, persist when the problem is scoped. The remaining work is bounded. The agent is not chasing an ever-expanding set of issues.

When these conditions hold, iteration typically succeeds. The session may take ten more turns, but each turn makes progress.

The judgment call

Iteration versus redirection is a judgment call informed by signals, not a rule that can be mechanically applied.

The signals matter: context utilization, error patterns, complexity trends, agent behavior. But they require interpretation. A session at 75% context with steady progress is different from a session at 75% context with circular reasoning.

Experience calibrates judgment. Developers who track their own decisions, noting when they redirected and whether that helped, develop intuition for the thresholds that work for their codebases and working styles.

Boris Cherny's 10-20% discard rate is instructive. If redirection never happens, the threshold is probably too high. If redirection happens constantly, the threshold is probably too low, or planning needs improvement.

The goal is not zero redirections. The goal is redirecting at the point where continued iteration costs more than starting fresh.

Cost accounting

A useful frame for iteration decisions is explicit cost accounting.

Estimate the cost of continuing: how many more iterations might this take? What is the probability of success given current trajectory? What is context utilization, and how much runway remains?

Estimate the cost of redirecting: five minutes to write a handoff summary, a few turns to re-establish context in the new session, maybe 20-30 minutes to reach the current state in cleaner context.

Compare.

Often the comparison reveals that redirection is cheaper than intuition suggests. The perceived cost of abandoning accumulated context looms large. The actual cost, measured in time and tokens, is usually modest.

Developers who perform this accounting explicitly, even roughly, report more confidence in redirection decisions and fewer regrets about sessions that dragged on too long.

The calculation is never precise. But it shifts attention from "what I'm giving up" to "what each path actually costs."