Context Engineering: Why Your Agent Forgets Everything After Message 50

Your agent was brilliant at message 5. It knew the goal, followed your rules, remembered the plan. By message 55 it is a different thing. It repeats itself. It forgets a constraint you set at the start. It confidently contradicts something it said ten steps ago.

Nothing broke. The model did not get dumber. You hit the wall that kills almost every long agent run, and almost nobody names it: the context window filled up, and the important stuff got pushed out.

Here is what is actually happening, and the four moves that fix it.

The lie: "it remembers our conversation"

It does not. A model has no memory between turns. Every single message, the entire conversation so far gets re-sent to the model as one big block of text. That block is the context window. The model reads all of it from scratch, answers, and forgets everything the instant it finishes.

So "memory" is an illusion built by re-feeding the transcript every turn. That works great at message 5. The transcript is short, everything fits, the model sees all of it clearly. By message 50 the transcript is huge, and three things go wrong at once.

Why message 50 is a wall

Three forces hit at the same time, and they compound.

First, the window fills. Every window has a hard limit. Long back-and-forth, tool outputs, pasted files, error logs. It adds up fast. Once you are near the ceiling, something has to give, and the oldest content is first to go. That early instruction you cared about? Gone.

Second, lost in the middle. Even when everything still fits, models do not read a long context evenly. They pay the most attention to the beginning and the end, and the middle turns to mush. This is a measured effect, not a vibe: researchers named it "lost in the middle" after showing models miss facts placed in the center of a long context. Your constraint from message 12 is now buried in the exact spot the model reads worst.

Third, instruction drift. The rules you set at the start get further and further from the model's "now" with every message. Recent tokens dominate. So the agent slowly drifts toward whatever you said most recently and away from the system-level rules that should hold the whole way through.

Put together: the window overflows, the middle blurs, and the old rules fade. That is why your agent forgets after message 50. It is structural, not random.

The fix is not a bigger window

The obvious reaction is "just use the model with the giant context window". It does not save you. A bigger window delays the wall, it does not remove it. Lost-in-the-middle gets worse as the context grows, not better. Cost and latency climb with every token you carry. And you still have no control over what the model actually attends to.

Stuffing more in is the problem. The skill is deciding what the model should see at each step and, just as important, what it should not. That skill is context engineering. Here are the four moves.

Move 1 - Externalize memory into a state file

Stop treating the chat log as your memory. Write the things that matter to a file the agent can re-read: the goal, the hard constraints, decisions made, where it left off.

# state.md - re-read at the top of every run
GOAL: migrate the billing service, no downtime
HARD RULES: never touch the payments table; all changes behind a flag
DECIDED: use the new schema v2; keep v1 read-only until cutover
DONE: steps 1-4 verified
NEXT: step 5, backfill user rows

Now the constraint lives somewhere permanent instead of drifting to the top of a window about to overflow. The agent reads this file first, every time, and the goal never falls off the edge.

Move 2 - Compact on a schedule, do not wait for the overflow

Do not let the window hit the ceiling and drop content at random. Compact on purpose. At a set point (say 70 to 80 percent full), summarize the history so far into a tight brief, keep the summary, and drop the raw back-and-forth.

The trick is what you keep. A good compaction preserves the goal, the open decisions, and any constraint, and throws away the chatter. A lazy one summarizes the vibe and quietly loses the one rule that mattered. Treat the summary as the memory that survives, and write it like it.

Move 3 - Retrieve at the point of use, do not front-load

The instinct is to paste every doc, every file, every spec up front "so the agent has it". That is exactly what buries the important part in the middle. Do the opposite. Keep the window lean and pull the specific piece in only when the current step needs it. The one function being edited. The one doc the question is about. Relevant now, in the window now. Everything else stays on disk until it earns a place.

Move 4 - Isolate long sub-tasks in their own window

Some jobs are just long: read twenty files, test ten cases, crawl a big log. If that happens in your main window, it drowns everything else. So hand it to a sub-agent with its own clean context. It does the messy 20-step job in isolation and reports back one short result. The main agent never sees the mess, only the summary. Its window stays sharp.

The 3 ways this still bites you

• Silent constraint loss. A rule from message 3 vanishes in a compaction and the agent starts doing the one thing you forbade. Fix: keep hard rules in the state file, not the chat, and re-read them every run.
• Summary rot. Each compaction summarizes the last summary, and detail erodes generation over generation until the goal is mush. Fix: always summarize from the state file plus the latest window, never a summary of a summary.
• Retrieval misses. Pull-at-point-of-use fails when the agent does not know a doc exists. Fix: keep a short index in the state file - a list of what is available and where.

What to do this week

You do not need a framework. You need to stop trusting the chat log as memory.

• Create a state.md for your next long task. Put the goal and hard rules at the top.
• Have the agent re-read it at the start of every run.
• Set a compaction point and write a real summary at it, from the state file, not the vibe.
• Move big, messy sub-jobs into sub-agents so they never pollute the main window.

The takeaway

Your agent does not forget because it is weak. It forgets because it never had memory to begin with, only a window you kept overflowing. Context engineering is the discipline of spending that window on purpose: externalize what matters, compact before you overflow, retrieve at the point of use, isolate the long jobs. Do that, and the agent that fell apart at message 55 holds its thread at message 500.

If this helped, follow me. I break down AI systems and prediction markets every week, no fluff.