What you will learn What actually happens when the window fills, the signals that tell you, and four practical responses.
At the limit, the oldest content is pushed out first.
The problem is that the important things are usually at the front. Role setup, constraints, the original goal — you write all of them at the start. And they go first.
| Symptom | What it really is |
|---|---|
| The tone you set at the start drifts | the tone instruction got pushed out |
| It does something you said not to | the constraint got pushed out |
| It asks again about something already decided | that decision got pushed out |
| It drifts off the original goal | the goal got pushed out |
| Answers become generic | the specific context got pushed out |
A large share of "the model got dumber" moments are this. The model is unchanged; what it is looking at changed.
Agents turn dozens of times inside one request. Each turn's tool result accumulates in the context.
HyperTeamsgraph TD
A["Turn 1: goal + tool result 1"] --> B["Turn 5: goal + results 1–5"]
B --> C["Turn 15: results 6–15<br/>the goal has been pushed out"]
C --> D["What were we doing again?"]A large lookup result (say a 500-row table) can fill it in a few turns. So in practice tool results are trimmed rather than inserted whole.
Do not put ten jobs in one conversation; start each separately.
✗ In one conversation: research → analyse → write report → review → slides✓ Each in a new conversation. Carry only a summary of the previous resultIn most cases the next step needs the previous result, not the previous process. Dragging the process along only takes up space.
Re-confirm constraints midway through a long job.
Do not say it once and stop. What you wrote at the start may be gone.
Rather than inserting a 500-row table whole, insert only the part you need. When building a system, design this to happen automatically.
For a long job, do this midway:
Take that summary and start a new conversation. You discard the messy process and carry only the conclusions.
Suspect the window when you see:
Before changing the model or editing the prompt, try a new conversation. A large share of cases resolve there.
This property does not stop at personal technique. It affects how you split up work.
The methodology that pushes this principle all the way is micro-sprints. This is one of the reasons work gets split into atomic units.
1. Why is it specifically the important things that disappear?
The oldest goes first, and the important things are usually at the front. Role setup, constraints, and the original goal are all written at the start, so they are the first to go.
2. Why is this worse with agents?
Because they turn dozens of times inside one request and each turn's tool result accumulates. With large lookup results it fills within a few turns, and the original goal gets pushed out, blurring what the job was.
3. What should you try first when "the model seems to have got dumber"?
Starting a new conversation. Before changing models or editing prompts, summarise the decisions so far and move them into a fresh conversation — a large share of cases resolve there.
Manufacture the moment it gets pushed out. Thirty minutes → Push context out on purpose
[System instruction: do not touch anything outside this folder] ← pushed out first[turn 1][turn 2]...[turn 47][turn 48] ← still there(after about 20 turns)To reconfirm: do not touch the payment logic — we're only changing theon-screen messages. Under that constraint, look at the next file.Summarise the decisions made so far as a list.Only what's needed for the next step.