During a long housing-authority casework session, Claude Code's context window fills with dozens of prior tool outputs and file reads. The team notices that instructions given early in the session are now being followed less reliably than instructions given recently. What phenomenon does this describe, and what is a reasonable mitigation?

Attention across a long context is not uniform. Information sitting in the middle of a large window competes with everything around it and exerts less influence than material near the beginning or the end, so an instruction's reliability can decay purely because of what has accumulated after it rather than because anything about the instruction itself changed.

Naming the phenomenon as lost-in-the-middle points at the actual lever, which is the composition of the context rather than the wording of the instruction. As a housing-authority casework session accumulates dozens of tool outputs and file reads, early instructions become buried; trimming stale material that is no longer relevant, or summarizing it while explicitly carrying the key instructions forward, keeps the effective context focused and restores those instructions' salience.

Treating the degradation as expected and harmless ignores a known failure mode that has practical mitigations, and in casework that inaction translates into real errors on real tenant files; diagnosing a hard token-limit defect misreads the symptom, since nothing has necessarily overflowed a limit and attention has simply diluted across a large volume of content; and adding more unrelated content earlier deepens the very dilution that is burying the instructions in the first place.

Exam caveat: summarizing is lossy, so a trim that compresses away a constraint the caseworker still needs trades one reliability failure for a quieter one. Operational check: after each trim, restate the governing instructions verbatim near the end of the context and probe the session with a question that only a preserved instruction can answer correctly.