The run ends with the step cap or token budget fired and the goal unfinished. The transcript starts well — two or three steps of real progress — then drifts: the agent checks items nobody asked about, re-verifies facts it already has, or explores a side question at length. On a paid API the first sign is cost: one task consumed several times its normal spend and still delivered nothing usable.
Agents given open-ended goal wording: "look into the stock situation", "sort out the reorders", "research what we need". Common right after a team's first agent works and goals get ambitious. Long context makes it worse — the further the run goes, the more the growing history competes with the original goal for the model's attention. Small models drift sooner, but vague goals eventually walk every model off the path. Linked module: 3.9 (Agents).
This is goal drift: every step is locally reasonable, and the sequence still walks away from the target. The loop rewards action, not progress — each turn the model picks a plausible next tool call, and "plausible" is measured against the whole context, where the goal is one line among many observations. Nothing in a bare plan-act-observe loop measures distance to the finish. Confirm the diagnosis in the trace: find the last step that served the goal directly, then ask of each later step "which part of the goal needed this?" — with drift, the answer is none. Distinguish it from WR-045's retry loop by the arguments: drift explores new territory, a retry loop hammers the same call.
Three changes. First, tighten the goal into a brief: name the deliverable, the exact items or inputs in scope, and what is out of scope — "check these four items, bill refills for any below 3, write reorder.txt, do nothing else" leaves no room to wander. Second, add progress checks in the harness: every three steps, inject a message telling the model to list what the goal still needs and to make the next call serve one listed item — this re-anchors attention on the goal. Third, size budgets per goal from the honest step count of a good run, and on cap, return partial results with a stated reason instead of silence, so a drifting run still surrenders whatever it finished.
Write goals the way you would brief a new junior: deliverable, scope, exclusions. Keep a per-goal step budget in the harness from day one, sized from real traces, and alarm when any run uses more than double its usual steps. Review weekly for near-drift — runs that finished but spent steps on unasked work — because those mark goals whose wording needs tightening before the expensive failure arrives.
Q: "Your agent spent its whole budget and never finished the task. The trace shows no errors and no repeated calls. What happened and what do you change?" Strong answer: name goal drift, explain that the loop optimises for a plausible next action rather than progress toward the goal, and show the trace test — find the last step that served the goal. Then give the fixes: brief-style goal framing, periodic progress checks injected by the harness, and per-goal budgets with honest partial returns. Bonus for distinguishing drift from a retry loop by whether the arguments keep changing.