Build1 publisher3 min readPublished
Context rot piece maps two of five failure modes, position bias and attention dilution, before breaking off mid-sentence
A dev.to piece on harness engineering splits agent degradation into five separable failure modes. The two it actually describes both turn on where a token sits in the assembled prompt, and a bigger window leaves both in place.
The Engineer · Build desk
What happened
- A dev.to article on harness engineering argues that context rot is five distinct failure modes, and that they compound as more content is piled into a bigger context window.
- Its first mode is position: with 20 documents injected, the relevant one at #10 is likelier to be missed than at #1 or #20. The article calls that a position effect.
- Its second mode is dilution, where a fixed attention budget spreads thinner across 50,000 tokens than across 5,000 because the softmax runs over more inputs.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Buying window headroom leaves both described modes in place: a longer window lets the session run longer, and the low-attention middle grows with it.
- decision If position 0 and the last slot are the reliable ones, the open choice is which tokens a harness puts there each turn. That choice lives in assembly code teams already own.
- contradiction The two modes pull their fixes in opposite directions, since duplicating an instruction to get attention at both ends adds tokens, and added tokens are what the dilution claim says thins every other token's share.
- exposure Degradation that produces no errors and no crashes clears every liveness check a team already runs. The monitoring stack stays silent.
Take the position claim as a statement about prompt assembly, because assembly is where a harness can act. Each turn the harness rebuilds one flat sequence: system prompt, session history, tool results, retrieved chunks, newest user message. The article rejects the model in which context behaves like RAM, with everything under the limit equally usable, and offers a whiteboard that gets harder to read as it fills [10]. It puts strong attention on position 0 and on the last position, and says everything in between gets progressively less as it drifts toward the middle [4]. It also says the middle grows as the session grows, so content that mattered keeps landing there [5].
The dilution claim is stated as division. The example is 5,000 tokens against 50,000: one fixed attention budget, ten times as many tokens competing for it, which the article attributes to the softmax over more inputs spreading weight more thinly [7]. Divide evenly and the average share per token at 50,000 is a tenth of the share at 5,000 [13], while the position claim has that budget spread unevenly [2]. Both can hold, because an average tells you the mean and not the distribution.
The remedy the article reports for position bias is duplication: critical instructions at the top, then again at the bottom just before the user's latest message. Those are the two positions the model is guaranteed to attend to. It attributes the practice to Greg Brockman and "many others" [6]. Duplication costs tokens twice, and by the article's own dilution account those tokens join the pool that thins every other token's share [14]. A 200-token rule duplicated into a 50,000-token session is cheap. A 4,000-token instruction block is worth measuring before it becomes a default.
On "lost in the middle" the article says the pattern is documented in the literature and holds across model families and sizes, without naming a study. The published text describes two of the five modes before breaking off mid-sentence in the second [2][11]. It also links the author's paid Udemy course and a live Maven workshop on the same material [12]. Moving the two described modes onto your own harness means running the sweep yourself. Fix a session, take one instruction whose compliance you can check automatically, move it from position 0 to the middle to the last slot, and count violations per position.
The symptom list is the part an on-call engineer can use directly. Instructions honoured in a fresh conversation get ignored 15 turns in, and retrieved snippets from three queries ago bleed into an answer to an unrelated question, with no errors and no crashes [9]. A health check does not see any of that. Catching it needs per-turn compliance assertions inside the harness, on the same prompt string the harness just built.
What to watch
- Whether the remaining three named modes get published with remediations that are distinct from ordering and compaction, or collapse into the two already described.
- A published per-position retrieval sweep on current long-context models, which would show whether the middle penalty still appears at today's window sizes.
- Whether harness vendors expose assembly order as a configurable thing, so ordering stops being a code change in each team's own glue.