The 3-compaction problem

Every agent you have used has a wall in it. Not a wall of intelligence. A wall in its memory of why decisions were made. Long enough sessions hit it. Most people notice the symptom and not the seam, and the seam is where the work that matters lives.

// the moment of forgettingThe agent re-proposed the rejected thing

Four hours into a session, the agent suggested the exact thing I had told it not to do.

Not something similar. The same approach. The same flaw. An hour earlier we had gone back and forth about why it wouldn't work, and it had agreed, and we had moved on. Now it was proposing it again, cheerfully, as if that conversation had never happened. Because for the agent, it hadn't.

It had not gotten dumber. The model behind it was the same model it had been at minute zero. Same weights, same capability. What it lost was not intelligence. It was the memory of why decisions were made. The reasoning was gone and only the surface remained, and the surface was confidently wrong.

I scrolled back to find the moment it forgot. It was easy to spot. One line in the log: the session had been compacted. Then, later, compacted again. Somewhere around the third one the thread that held the work together had quietly been cut, and neither of us noticed until the agent walked face-first into a wall it had already mapped.

That is when I went looking for what actually happens when a harness compacts a session. What it keeps. What it throws away. And why almost every agent you have used has this wall in it, waiting for the session that runs long enough to hit it.

// what compaction actually isTwo ways to make room

To see why the agent forgot, you have to know what a compaction is. The word makes it sound technical. The mechanism is simple, and it has only two real flavours.

Every agent runs a loop. The model at the centre of it has no memory between calls. Each call is a fresh slate. Whatever was said three turns ago is gone, as far as the model is concerned, unless someone shows it again. That someone is the harness. Every turn, it ships the whole conversation back to the model along with the new user message, and that is the only reason the agent appears to remember anything at all. The model reads it, decides what to do, writes a response. The harness appends the response to the conversation, and the next turn ships the whole thing back again. The conversation grows, turn by turn, like a transcript that gets longer every minute. The mechanics of that loop got a full unpacking in the previous piece; this one is about the part of it that decides what you remember.

A model has a maximum amount of text it can read in one go. Once the conversation gets close to that limit, something has to give. The harness has to make room. That is compaction. There are two ways to do it.

The two are easiest to see side by side. Same starting history, two different things a harness can do to it when the context window fills up.

The strategic preference is obvious once you say it out loud, and has been written down before. Raw history first. Reversible compaction when raw stops fitting. Lossy summarization only as a last resort. That order is how a session keeps its memory intact for as long as possible.

The trouble is that the third step comes faster than people realise. And it is where the wall lives.

// the wallAfter three compactions, the agent forgets why

After two or three lossy compactions, the agent's reasoning is gone.

This is the claim a pseudonymous engineer has been documenting for months, and once you have seen it once you cannot unsee it. After one summarization, the conversation can still cohere. The summary captures the broad shape of what happened. After the second, things start to thin. By the third, the agent is operating on a third-generation copy of its own past. A summary of a summary of what once was a conversation. The detail is gone. The branches it considered and rejected are gone. The constraints it agreed to are blurred into general guidelines. The conclusions are preserved by the kind of summary an LLM tends to write. The reasoning behind them is thrown out.

What disappears, specifically, is recognisable once you watch for it.

• The reason a particular approach was rejected. The agent that compacted the rejection often re-proposes the same approach a few turns later, cheerfully, because the summary kept that the approach was considered and lost why it was abandoned.
• The state of a multi-step task. After a compaction, the agent forgets which steps it has completed and which it has not, unless the summary captured that explicitly. It often did not.
• Outstanding blockers. A list of things the agent was waiting on can be reduced to a vague mention of dependencies, which is exactly enough to forget about them.
• The state of a side task. If another agent or another process was handling something in parallel, the summary keeps the main thread and quietly drops the side thread, because that is what summaries do.

The shape of the wall is easier to see as a picture. What survives at each compaction, by category:

You can see all of this by paying attention. The tells are precise. The agent suggests the rejected idea again. The agent forgets which file it just edited. The agent declares a task complete when only the first half is done. The agent stops mentioning a problem it was halfway to solving. Each one is a specific thing the summary did not carry forward, and the agent, working only from the summary, has no way to know it is missing.

That is the wall. It is not made of intelligence. It is made of what a summary cannot encode about a conversation that mattered.

// the harness tourWhat each agent actually does

Different agents hit the wall at different points, and they hit it differently. The table below is what I found after reading the compaction code of nine of the popular ones. Names belong in the data, where the comparison can be checked. Patterns belong in the prose.

Reading the table, the differences are in what each chose to keep, not in how aggressively each compresses. Two harnesses can hit the same compression ratio and produce dramatically different quality on the work that depends on what was lost. The reduction percentage is not the achievement. The achievement is what the harness chose to keep before it threw the rest away.

The split that matters most is the one between the harnesses that summarize cumulatively and the ones that regenerate from scratch. A cumulative summary carries the chain forward across compactions. A from-scratch summary at each compaction means the third summary is reading the second summary as raw context, and the third generation loses what the second generation had already lost. This is the structural reason the third compaction is so often the one where the wall appears.

One vendor's published evaluation of three commercial systems, including its own, surfaces one weakness worth naming. Awareness of files and artifacts is the lowest-scoring dimension across all three. None handle it well through summarization alone. The honest finding is that this is not a summarization problem. It is a retrieval problem dressed as a memory problem.

// surviving twelveThe four pieces that hold the line

The same engineer who documented the wall has published a fix that, in their own production use, survives it. The claim, in their words: "sessions regularly survive 12+ compactions with full context intact." The author is candid about what kind of evidence sits behind that line: "no formal benchmarks. This comes from daily production use, not a research lab." That makes it a practitioner technique, not a peer-reviewed result. Worth taking seriously for what it proposes; worth holding loosely until others build on or contradict it.

The four pieces are not a clever trick. They are mostly the patient engineering a default compaction prompt does not bother with.

Read those four pieces together and the pattern becomes plain. The default compaction is a single step of summarization in an empty room. The fix is to surround that step with structure and external information so that the summarization is not the only thing carrying the work forward. Most of the why lives outside the conversation. Compaction by itself cannot preserve it. A harness that adds the surrounding structure can.

The numbers people publish about how aggressively a harness compresses do not capture any of this. A harness can hit a 99 percent reduction with no hooks and no continuity rules and feel impressive in a demo, then collapse silently on the third real session that runs long enough to need it. The reduction is the achievement that markets well. The structure around the reduction is the achievement that ships.

// the seam nobody marketsWhere the next year of work happens

Once you have seen the wall, you stop talking about agents the same way.

The marketing of these tools is about the model. A new model arrives, the demo videos play, the leaderboards shuffle. Most of what people argue about lives in that layer. The model that just shipped is better than the one before it at a benchmark.

The thing that decides whether your eight-hour session falls apart at 2 a.m. is not the model. It is the compaction. The model is the same. The compaction is what one harness writer thought about more carefully than another. That writer's choices, made in a code file that almost nobody reads, are why the agent at 2 a.m. either remembers why it rejected an approach an hour ago, or proposes it again as if for the first time.

The seam between the model and the harness keeps showing up here. The intelligence is in one place. The decision about what to remember is in another. The model is replaceable. The compaction is not.

The model is a commodity now. The compaction strategy is the product.

I think about the session where I noticed all of this, four hours in. The agent had not gotten dumber. The harness had thrown out the part that knew why. The wall was not a property of the model behind it. The wall was a single function in someone's codebase that had decided, on my behalf, which sentences of our conversation were worth keeping. It made a defensible choice. It did not make the right one for the work we were doing.

That is the part that is going to keep me reading the code. Every harness has this function. Every team that ships one has chosen what it preserves. Most teams have not published their choice. The next year of agent tooling will be decided by how well that choice is made, by people patient enough to think about it more carefully than a default prompt.

If you are building one of these, or buying one, you now know where to look. Open the source. Find the function. Read what it keeps. That tells you, more honestly than any benchmark, whether the agent you are holding will still be useful at hour four.