Fork Eliminates Anchoring Bias: 89% vs 62% Accuracy

When you need to compare strategies, analyze options, or evaluate approaches, sequential exploration in one session produces biased results. The first option explored anchors the agent’s evaluation of everything that follows. fork_session eliminates this by creating independent branches from a shared baseline.

The mechanism

fork_session takes an existing session and creates a new independent branch. Both the original and the fork inherit the full context up to the fork point. After that, they diverge independently — tool calls, reasoning, and conclusions in one branch don’t affect the other.

You can fork more than twice. Three competing architectural approaches? Fork three branches from the shared codebase analysis. Each explores one approach in isolation.

The anchoring bias problem

A customer support system evaluated two resolution approaches sequentially in one session:

• Approach A (explored first): rated “recommended” 85% of cases
• Approach B (explored second): rated “acceptable but inferior” 90% of cases
• When order was reversed: Approach B got “recommended” more often

The bias follows position, not quality. Sequential evaluation causes anchoring — the agent commits to the first approach explored and evaluates everything else relative to it. This is structural contamination, not a prompt design issue.

The data: fork vs sequential

The 27-point accuracy gap on identical strategy pairs proves forked evaluation eliminates anchoring. The 1.8x cost increase is justified — wrong strategy selection has downstream costs far exceeding the evaluation overhead.

When to fork vs when to resume

Fork — for divergent exploration. Comparing strategies, evaluating alternatives, testing different analytical frameworks. The key test: would exploration A’s reasoning contaminate the evaluation of exploration B? If yes → fork.

Resume — for linear follow-ups. Clarifications, drill-downs, iterations on the same topic. The follow-up builds on prior context, not diverges from it.

One system over-forked: 12 forks per research task, but only 3 were genuinely divergent — the other 9 were simple clarifications. Each unnecessary fork cost 1.8x vs resume at 1.0x. Fix: fork only for divergent exploration, resume for everything else.

Rules for clean comparison

Don’t share findings between branches. Cross-branch information flow reintroduces the contamination that fork is designed to prevent. Each branch explores independently.

Don’t explore sequentially in one session. Even with explicit instructions to “evaluate independently,” the agent’s reasoning about approach A becomes context for approach B. The bias is structural, not correctable by prompting.

Use a fresh coordinator for synthesis. After forked branches complete, compare their outputs in a coordinator session that did NOT participate in any branch’s analysis. A coordinator that participated in one branch is biased toward it.

Use cases

• Architecture comparison: fork 3 branches for microservices vs modular monolith vs event-driven → independent evaluation → fresh coordinator recommends
• Dependency upgrade evaluation: fork from current analysis → explore upgrade impact in fork → original preserved untouched for comparison
• Research frameworks: fork from shared data → economic analysis, rights-based analysis, innovation analysis → compare conclusions
• Refactoring strategies: fork from codebase analysis → extract library vs plugin architecture → compare trade-offs

Sequential exploration isn’t always wrong

If you don’t need independent evaluation — if the task is building understanding progressively rather than comparing alternatives — sequential in one session or resume is fine. Fork’s overhead (1.8x cost) is only justified when anchoring bias matters.

One-liner: Fork eliminates anchoring bias (89% vs 62% accuracy on strategy comparison), costs 1.8x but prevents wrong decisions — use fork for divergent exploration only, resume for linear follow-ups, and never share findings between branches.