Quick answer: When an agent's context fills up, the content sitting in the middle is the first to be compressed, dropped, or underweighted, while the opening instructions and the most recent messages tend to survive. A larger window only delays this. The practical fix is to place the facts the model must act on near the edges, keep the middle lean, and label it so a trimmed fragment still makes sense.
Why the middle is the first to go
Two forces work against the middle. First, there is a hard budget. Every request carries a fixed amount of usable context, shared among the system prompt, tool definitions, retrieved files, conversation history, and the new user turn. When the sum exceeds that budget, something has to give, and most runtimes trim or summarize the oldest bulk material, which by then sits in the middle of the assembled prompt.
Second, even when nothing is deleted, attention is not spread evenly across positions. The documented "lost in the middle" pattern shows that models use information at the start and end of a long context more reliably than the same information placed halfway in. A schema rule or a constraint buried between two large file dumps can be present in the prompt and still fail to change the answer. Position then acts like a quiet form of truncation, with no warning in the output.
Where this bites in a coding workflow
Long agent sessions are the common trigger. Early in the conversation, the model holds the project rules and the shape of the task. After dozens of tool calls, file reads, and pasted logs, those early rules now sit in the middle, surrounded by bulk. The agent can start ignoring a naming convention it followed at first, or reuse a helper it was told to avoid. For more on how these sessions are meant to run, see the AI coding agent guide.
The same thing happens with a single large paste. Drop a fifteen-file repository into one prompt and ask for a change, and the files in the center get less weight than the first and last files, even though the model technically received all of them.
| Position in the assembled context | Typical fate | What belongs there |
|---|---|---|
| Start (system prompt, ground rules) | Retained and weighted strongly | Hard constraints, output format, "do not" rules |
| Middle (file dumps, older turns) | Summarized, trimmed, or underweighted | Reference detail, chunked and clearly labeled |
| End (latest turn, active request) | Retained and weighted strongly | The current task and the decision you need now |
How to keep middle content from disappearing
Front-load the constraints that must never break. Put them in the system prompt, and repeat the single governing rule right before the task when a session has grown long. Restatement near the end costs a few tokens and buys reliability.
Move the active decision to the end. Name the specific question and the relevant file or symbol in the latest turn instead of assuming the model remembers it from twenty messages ago. Compress before you append: strip boilerplate, collapse repeated log lines, and send the smallest chunk that answers the question.
Label and anchor every chunk with a clear heading or a revision reference, so a retrieved fragment carries its own meaning once the surrounding turns are summarized away. Prefer bounded, relevant context over a full repository dump. Powerduck reviews current differences with bounded related context rather than feeding the whole codebase, and its agent handoff exports context with revision anchors so a fragment stays interpretable after trimming.
Frequently asked questions
Is a larger context window a fix? It delays the problem rather than removing it. Past a point, the new middle is still underweighted, and each call costs more because you are moving more tokens.
How can I tell whether the model actually read a middle constraint? Ask it to restate the constraint before acting, or move that constraint next to the task. If it cannot echo it, trimming or position bias is already working against you.
Does retrieval make this worse? It can, when a run pastes many ranked documents into one prompt. Order the chunks so the most relevant land near the edges, or split them across turns instead of one long paste.
The bottom line
Treat the middle of a context window as unreliable storage even when the text is technically there. Put hard rules at the start, put the current decision at the end, keep the middle small and labeled, and confirm the model can repeat the constraint you care about. When an agent never loses a buried requirement, it is usually because you placed that requirement where it could not be missed.
Top comments (0)