Instruction Fragmentation: When Requirements Arrive Across Turns and Agents Don't Recover

Instruction fragmentation is the failure mode where an agent's requirements are never delivered in one complete specification but arrive piecemeal across several turns, and the agent forms a premature synthesis from the first few pieces that later, corrective turns fail to dislodge. A user describes a task across three follow-up messages instead of one; a ticket gets amended after the agent has already started; a multi-step agent session receives a new constraint at step six that changes what step two should have done. In each case the agent had, at every individual point in the conversation, technically correct information about what it had been told so far. What it lacked was the full picture, and what went wrong afterward was not that the picture changed, it is that the agent kept building on its first guess instead of rebuilding from the corrected one.

This is a different mechanism from goal drift, where an agent's objective diverges from a correctly understood starting point over the course of a session, and from context rot, where quality degrades as a function of how much context has accumulated. Instruction fragmentation needs neither a long session nor a drifting objective: the requirement was simply never stated all at once, and the failure shows up as soon as a later turn contradicts or extends an earlier one, sometimes within a handful of exchanges. The objective was defective from the moment of first synthesis, not eroded from a once-correct state, and the fix is a different shape too, since re-anchoring an agent to a goal it never had right in the first place does not help; it has to actually re-derive the goal from the complete requirement set.

Mechanism

The clearest evidence comes from a large-scale simulation study that took fully-specified, single-turn benchmark prompts and mechanically split each into several pieces, called shards, delivered one per turn instead of all at once, then compared the model's final output against the same task answered in a single turn (Laban et al., arXiv:2505.06120). Across more than 200,000 simulated conversations, six generation tasks, and every major open- and closed-weight model tested, the sharded version scored an average of 39% lower than the single-turn version of the identical task.

The paper's more useful finding is how that 39% breaks down. It is not a uniform quality haircut: aptitude, the best score a model achieves across multiple attempts at the same sharded task, drops only slightly. What collapses is reliability, the consistency of getting a good answer across repeated attempts at a task that is, in substance, identical every time. A model might solve a fragmented version of a task well on one run and badly on a near-identical rerun. That is a worse operational property than a flat quality drop, because it defeats the usual fix for unreliable output, retrying, since a retry samples from the same unstable distribution rather than converging back on the single-turn answer.

The mechanism behind the unreliability is premature commitment. Models tend to attempt a complete solution as soon as they have enough of the shards to produce something plausible, rather than waiting for the full specification, then treat that early attempt as a fixed point to patch rather than a draft to discard. When a later shard reveals the initial assumption was wrong, the pattern the authors describe is direct: the model takes a wrong turn and does not recover, continuing to build on the flawed premise rather than resynthesizing from the complete picture. This is structurally different from the attention-based degradation behind context rot, since it shows up regardless of how much total context has accumulated. What matters is not volume, it is whether the specification was ever complete at a single point the agent could reason from.

For agents, this generalizes beyond chat prompts. A plan built after the first of several requirement updates, a scope synthesized before a ticket is done being edited, or an agent that locks in an interpretation at step two of a ten-step run and treats step six's clarification as an amendment to patch rather than grounds to reconsider steps two through five, is the same premature-commitment pattern the sharding study measured in single-response generation tasks, applied to multi-step execution instead.

How to measure

• Sharded replay tests: take tasks from your own eval suite that are normally given as a single complete specification, split them into ordered shards, run both versions, and score the single-turn/sharded gap directly, following the paper's methodology; a wide gap on your task types is the primary signal that fragmentation is a live risk in your deployment.
• Variance across reruns, not just mean score: since the dominant loss is reliability rather than aptitude, run the same sharded task several times and track the spread of outcomes. A stable mean with a wide variance is exactly the pattern the mechanism predicts, and a mean-only eval will miss it.
• Early-commitment audits: inspect intermediate plans, drafts, or partial answers an agent produces before all requirements have arrived, and check how much of that early material survives unrevised into the final output despite later corrective turns.
• Revision-acceptance rate: log whether a later turn that adds to or corrects an earlier requirement actually changes the agent's plan or output, versus being acknowledged in text but not applied to the work.
• Add a sharded variant of your golden tasks to a replayed suite per drift regression tests, since the failure is cheap to reproduce deterministically once a task is shardable.

Mitigation

Defer synthesis until the specification is explicitly complete. The premature-commitment mechanism is triggered by attempting a full answer as soon as a plausible one is available; a harness-level rule that withholds a final plan or deliverable until an explicit "requirements complete" signal, from the user or an upstream system, removes the trigger rather than trying to correct its output after the fact.

Recap before continuing, not after. Restating the full requirement set gathered so far, then proceeding from that restatement rather than from the raw turn history, is a direct, testable countermeasure to the premature-commitment pattern: fold every shard delivered so far into a single current statement of the task, and treat that as what the agent reasons from next.

Externalize the requirement set as a ledger, not a transcript. Per state externalization, keep a single, rewritten record of the current understanding of the task rather than letting later shards accumulate as additional conversational turns layered on top of the first synthesis; a later correction should overwrite the relevant line of the ledger, not get appended after it.

Prefer batched specification when it is available. Since the failure is structural to fragmentation itself rather than to any one model's weakness, the most reliable mitigation is not delivering the specification in shards in the first place: a requirement-gathering step batched before execution starts avoids invoking the mechanism at all, where feasible.

Restart synthesis on detected contradiction instead of patching. Because aptitude loss is minor and unreliability is the dominant cost, a fresh attempt that reasons from a corrected, complete recap tends to recover close to single-turn quality; patching a wrong early commitment in place is the more expensive and less reliable path, and the finding that models rarely self-correct once anchored means the harness, not the model, has to force the restart.

Related terms

• Goal drift: divergence from a correctly understood objective over time; instruction fragmentation is a defective synthesis from the start, not an erosion of one that began correct.
• Context rot: degradation driven by accumulated context volume; instruction fragmentation is driven by how the specification was delivered, independent of length.
• Plan decay: a plan drifting out of sync with a changed world; instruction fragmentation is a plan built on an incomplete world in the first place.
• Re-anchoring patterns: the injection mechanics a recap-based mitigation relies on.
• State externalization: where a rewritten requirement ledger should live.
• Drift regression tests: where sharded replay tests belong in an ongoing suite.

FAQ

Is instruction fragmentation the same as context rot? No. Context rot is a function of how much context has accumulated; instruction fragmentation is a function of how the specification was delivered, and shows up in conversations short enough that context volume is not yet a plausible explanation.

Does this only happen in long-running agent sessions? No. The underlying study measured the effect in ordinary multi-turn chat completions, some only a handful of turns long. Any agent workflow where requirements can be added to or corrected after the agent has started producing output is exposed to it, regardless of session length.

If retries don't fix it, what does? Retrying alone samples from the same unreliable distribution the fragmentation created, since the loss is concentrated in reliability rather than raw aptitude. What tends to work is forcing a fresh synthesis from a complete, current recap of the requirements, rather than resampling around the model's original, partially-informed commitment.