Front-load the goal: why a late correction can't save a long AI task

Overview

Hand a capable AI agent a long task, then realise three steps in that you asked for the wrong thing and try to correct the goal. In a study of more than 6,000 agent runs published this May, that correction was close to worthless: goal clarification lost nearly all its value after just the first 10% of a run, with success (pass@3) sliding from 0.78 back toward the no-help baseline. Leave it past the halfway mark to fix anything and you finished worse off than if you’d never spoken up. The advice everyone gives is “be specific.” The finding is that being specific about the goal late barely counts.

The content

The obvious read is that giving the model complete instructions is the whole game — get everything in and you’re set.

The overturn is about when, not whether. The same study — “Ask Early, Ask Late, Ask Right”, four frontier models, three agent benchmarks, 84 task variants — found a sharp split between kinds of clarification. Tell the model the goal (the outcome you want and how you’ll know it’s done) and that has to arrive almost immediately: its value collapses after roughly the first 10% of the run. Tell it an input or a constraint (a file, a format, a rule to respect) and that keeps its value through about the halfway mark. Call the single habit front-loading the goal: get the definition-of-done into the opening turn, and let the smaller stuff follow.

Why the goal in particular? Two independent lines of work make it plausible. On the mechanism side, positional-bias research — the “lost in the middle” effect — shows models weight the edges of a prompt over the middle, so the middle is the easiest place to lose your goal: keep it at the top. (That primacy is strongest when the prompt is well short of the context limit; as you fill the window the model leans more on what came last — either way, the middle is where an instruction goes to be ignored.) On the behaviour side, a separate group built an independent taxonomy of underspecification — goals, constraints, inputs, context — and showed that clarification substantially recovers the performance you lose to a vague task: in one model-and-benchmark pairing, asking clawed back roughly two-thirds of the gap. Once an agent commits to a trajectory it spends the run pursuing whatever goal it inferred, and a later correction is fighting momentum the model already banked.

There’s a matching failure in real tools. Coding agents left to decide for themselves tend to ask their clarifying questions late — after they’ve already assumed their way down a path — which is exactly the timing the run-level study says is worse than never asking at all. And the models aren’t calibrated on this: across unscripted sessions, none asked inside the window that actually helped, and they over-asked in 52% of them. You can’t outsource the timing to the agent.

One honest limit. The precise curve — about 10% for goals, roughly 50% for inputs — comes from that single 6,000-run study, and so does the finding that goals decay faster than inputs; read those specifics as “one careful study finds.” What has independent support is the plainer direction: put the goal first, and correct it early or not at all — the positional-bias work says don’t bury it in the middle, and real coding agents that ask late pay for it.

Try it

Next time you kick off anything long — an agent run, a deep-research brief, a multi-turn build — spend your first turn on the goal, not the set-up.

Open with the DEFINITION OF DONE, before any context:

  "Goal: <the outcome you actually want>.
   Done when: <how you'll know it's finished — the test it must pass>.
   I'll give you the inputs and constraints next."

Then feed inputs and constraints across the following turns —
those hold their value; the goal doesn't.

Where it breaks, deliberately: if you don’t yet know the goal, don’t launch a long autonomous run and plan to steer it later — the research is blunt that a late goal correction can’t recover the run. Do the exploring in cheap, short exchanges first, settle the definition-of-done, then start the run that has to carry it. And don’t over-read this as “front-load everything” — that’s just the old completeness advice wearing a new hat. The whole point is the asymmetry: the goal is the part that can’t wait; the inputs can.

Additional reading

• Ask Early, Ask Late, Ask Right: When Does Clarification Timing Matter for Long-Horizon Agents? — arXiv (8 May 2026) — the timing curve itself: goal clarification loses nearly all value after ~10% of a run (pass@3 from 0.78 toward baseline), input/constraint holds to ~50%, deferring any correction past mid-run is worse than never asking, and frontier models over-ask in 52% of unscripted sessions. Four models, three benchmarks, 84 task variants, 6,000+ runs. The exact percentages are single-study — hold them as “one study finds.”
• LHAW: Controllable Underspecification for Long-Horizon Tasks — arXiv (11 February 2026; v2 20 March 2026) — an independent author group and taxonomy (Goals / Constraints / Inputs / Context); clarification substantially recovers the performance lost to underspecification — in one model-and-benchmark pairing, roughly two-thirds of the gap. Corroborates that goal is a first-class dimension and that clarification helps; it does not itself rank goals the single most damaging kind — the goal-vs-input magnitude is the driver’s finding.
• Positional Biases Shift as Inputs Approach Context Window Limits — arXiv (August 2025) — the mechanism for not burying the goal: the “lost in the middle” effect means models weight the edges of a prompt over the middle, with primacy strongest well short of the context limit and recency taking over as the window fills. Either way, high-priority instructions belong at the edges, not the middle.
• Ask or Assume? Uncertainty-Aware Clarification-Seeking in Coding Agents — arXiv (27 March 2026; v2 3 June 2026) — real coding agents ask late and pay for it; a calibrated scaffold that asks earlier reaches a 69.4% task-resolve rate and nearly closes the gap to fully-specified instructions. The “this failure mode is real in shipping agents” leg.

Editor’s note

I’ll admit that I don’t always practise what I preach in this module. But I’ll also tell you that I often notice the impact. If I have several issues with model output, and I name the issues before describing or reframing the goal, what I’ll often get is an attempt to address my specific points instead of my actual goal. The solution is unnatural for me, but like everything else on this site, learning the skills is part of moving forward as a knowledge worker at this point in time.