In a long ReAct run, why should thoughts restate the goal and remaining steps?
answer
- distance from the original instruction
- recent tokens dominate the next decision
- carry a progress ledger, not just a goal
- re-anchor from the source, not the last copy
- cadence, not every single step
basics
~20 sOn long runs the original instruction sits far behind a wall of observations, and its influence on the next token weakens. Periodically re-writing the goal and what remains puts the objective back near the point of generation, which is the cheapest defence against drift.
solid answer
~50 sThe problem is distance. After twenty tool calls the request that defined success is buried under thousands of tokens of retrieved text, and the model's next decision is dominated by recent material — so agents quietly start optimising the last observation instead of the task. Having thoughts re-anchor every few steps — "goal: reconcile the shipment manifest; done: matched 3 of 5 lines; remaining: lines 4 and 5" — restores the objective and a progress ledger right where the next action is chosen. Two disciplines make it safe. Re-anchor from the authoritative original statement, not from the previous restatement, or you get telephone drift where each copy shifts slightly. And keep it to one compact line on a cadence, because restating every step burns tokens and buries observations under boilerplate. If a restatement is wrong, it entrenches the error, so it is worth checking in review.
go deeper
Know that on long tasks an agent can lose track of the original request, and that repeating the goal in its reasoning helps it stay on target.
Explain the mechanism — the instruction is far from the generation point and recent observations dominate — and describe a restatement that carries both the goal and a done/remaining ledger.
Demonstrate the operational rules: anchor from the original wording to avoid telephone drift, use an event-driven cadence, and audit traces for restatements that have mutated or ledgers that claim unearned progress.
Treat it as a horizon-design question. Decide when anchoring is compensating for a task that should be decomposed into shorter runs, and require evidence that a mandated anchoring policy actually moves task success before it is paid for on every step.
## Why long runs drift A ReAct agent's next action is a function of everything in its transcript, but not uniformly. The user's goal was stated once, at the beginning; by step twenty it is separated from the generation point by every tool result the agent has collected, which on document-heavy or search-heavy tasks can be the overwhelming majority of the context. Recent tokens exert more influence on what comes next. The practical consequence is goal drift: the agent begins solving the problem posed by the most recent observation rather than the one posed by the user. It chases an interesting anomaly it found, answers a sub-question thoroughly, and returns something coherent that was never asked for. A second, related failure is losing the ledger. Which subgoals are already satisfied? On a five-part reconciliation task, an agent with no running tally will re-verify things it already verified and quietly skip things it never did. Both are wasted steps, and the skipped item is the one that reaches the user. ## Self-anchoring: putting the goal back in front The cheap intervention is to make the thought itself carry the anchor. Every few steps, the thought opens with a compact restatement: "Goal: reconcile the shipment manifest against the invoice. Done: lines 1-3 matched. Remaining: line 4 (quantity mismatch, needs the warehouse count), line 5 (not yet fetched). Next: fetch line 5." That single line does three things. It reintroduces the objective adjacent to the decision point, where it has the most influence. It records progress in a form the next step can read without re-deriving it from twenty observations. And it makes drift visible to a human reviewer scanning the trace, because a restatement that has quietly mutated is far easier to spot than a slow shift in behaviour. ## The two rules that make it work **Re-anchor from the source, not from the last copy.** If each restatement is written by paraphrasing the previous restatement, small distortions accumulate — the telephone effect. "Reconcile the manifest against the invoice" becomes "check the manifest for errors" becomes "summarise manifest issues," and by then the agent is doing a different job with full internal consistency. The goal clause should be a faithful restatement of the original request, ideally close to verbatim, and only the progress ledger should evolve. **Restate on a cadence, not every step.** Restating in every thought is pure repetition tax: it is paid on write and again on every subsequent re-read, and it pushes real observations further apart. A reasonable policy is to re-anchor after any step that returned a large observation, after a failure or a change of direction, and otherwise every few steps. Long-horizon tasks warrant it more often than short ones. ## What it does not fix Self-anchoring is a mitigation, not a solution. It does not help if the agent misunderstood the goal in the first place — then restatement entrenches the misunderstanding and makes it look deliberate. It does not survive a context that has been compacted or truncated in a way that dropped the original request, unless the restatement itself was preserved. And it competes for the same tokens as the evidence the agent needs, so on a genuinely enormous task the answer is usually to shorten the horizon rather than to narrate harder. It is also worth being honest that this is a workaround for a limitation rather than an elegant design. Models attend unevenly across long contexts; restating the goal is how practitioners compensate today. Where a task is long enough that anchoring is doing heavy lifting, that is itself a signal the task should be decomposed into shorter runs with narrower objectives. ## Reviewing for it In trace review, three checks are worth automating. First, does the restated goal still match the original request — a similarity or entailment check catches telephone drift. Second, does the progress ledger match what the trajectory actually did, or is the agent claiming completion of a subgoal that has no corresponding observation? Third, does the restatement cadence correlate with success on your eval set at all — because if it does not, you are paying tokens for a ritual. That last check matters: teams frequently mandate elaborate anchoring boilerplate and never measure whether it moved task success.
- What goes wrong if each restatement is paraphrased from the previous one?Telephone drift. Each copy shifts the goal slightly and the shifts compound, so after several rounds the agent is pursuing a related but different objective with complete internal consistency — which is the hardest kind of failure to spot, because the trace looks coherent end to end. Re-anchor close to the original wording and let only the progress ledger evolve.
- How do you decide the restatement cadence?Trigger on events rather than a fixed counter: after a large observation that floods the context, after a failure or a change of direction, and otherwise every few steps. Then validate empirically — compare success rates across cadences on your eval set. If a heavier cadence does not move the metric, it is boilerplate you are paying for on every subsequent re-read.
- When is heavy anchoring a sign of a design problem rather than a fix?When the horizon is long enough that restatement is doing real work, the task is usually too big for one run. Shortening the horizon — narrower objectives, a fresh run per subgoal — removes the drift pressure instead of compensating for it. Anchoring is a workaround for uneven attention over long contexts, not an architecture.
saying these in an interview costs you the question
- Thinks the initial instruction stays equally influential all run
- Restates the goal in every single thought as boilerplate
- Paraphrases the goal from the previous restatement each time
- Tracks the goal but never which subgoals are already done
- Assumes anchoring can rescue a goal the agent misread initially