Your agent hits 80% of its context window. Compaction fires and drops the oldest turns. Ten minutes later it re-reads a file it already read, and re-asks a question it already answered.
The threshold knew you were out of room. It knew nothing about what was safe to lose.
This is the third note in a series on long-horizon agent design, prompted by a close read of BEACON (Zhejiang University, arXiv:2605.06078). The first covered stall detection, the second covered milestone design.
Starting with our own implementation
Orkas is a multi-agent desktop client. Long tasks are the normal case here, so compaction comes up daily. Our implementation triggers on a token threshold, compacting once context reaches roughly 80% of the window. Until we wrote this up, none of us thought there was anything wrong with that.
There are about three common boundaries in the wild: percentage of the window, turn count, or letting the model write a summary that covers the old content. Ours is the first kind.
The first two never look at content at all. The third looks, but hands the entire question of what matters to the model.
All three answer when must I throw something out. The question you actually have is what is safe to throw out. Cutting at the threshold drops the oldest content, not the least important content.
The milestone boundary, and the assumption underneath it
The milestones from the previous note could give a better boundary than any of the three. But there is a trap here, and the previous note left it a little too smooth.
BEACON contains an assumption called the milestone Markov property. In plain terms: once you reach a milestone, what happens next depends only on the subgoals that remain, not on how you got there. Once you have the key, what matters is which door you open, not how you found it.
That sounds like a license to compact: past a milestone, the preceding stretch can be folded away.
But it is an assumption, not a fact. The paper writes ≈, not =, and the authors discuss where it fails.
Adequate for training, inadequate for compaction
Same assumption, two uses, an order of magnitude apart in strictness.
In training it only has to hold statistically. If a few dozen out of a few thousand rollouts violate it, the bias averages out. Training also runs a trajectory-level signal underneath as a backstop; ablate that layer and ALFWorld drops from 91.4 to 23.4, far below doing nothing at all.
In compaction it has to hold pointwise, for the single run in front of you. Drop the wrong thing once and that task is dead. There is nothing to average over.
So the paper leaning on this assumption does not mean you can carry it into compaction. The two uses do not ask the same thing of it.
Four cases where it breaks
We run these as a checklist when reasoning about a compaction policy.
1. Implicit knowledge accumulated along the way. Somewhere early on, a step establishes that a given API returns timestamps in UTC. That belongs to no milestone, and every step afterward needs it.
2. Resources already burned. Token budget, call quota, time remaining. A milestone does not record I have spent 60% of the budget, but that number decides whether a retry is still affordable.
3. Path-dependent side effects. The milestone says refactor complete. The moment debugging starts, you need to know which five files were actually touched.
4. The milestone itself is underspecified. This is the worst of the four. In the paper, a milestone is a complete environment state — you have the key or you do not, with no ambiguity. A plan step is one sentence of natural language. "Finish data cleaning" comes nowhere near covering what happened in that stretch.
What to carry across instead
Do not keep only a summary. A summary is written by the model, which decides by feel what mattered.
Keep a fixed set of fields, chosen by a human. At minimum four:
- What the workspace looks like now — which files were touched, and into what state.
- What budget is left — tokens, call quota, time.
- What has been established — the UTC fact, and everything like it that will shape later decisions.
- What is still open — the thing that blocked once, got worked around, and may come back.
Set that against the four failure cases above and they line up one to one. That correspondence is the simplest way to judge whether a compaction policy is sufficient.
Half of this is nearly free. As the previous note described, the host already records deterministic facts after every tool call: whether a file was really rewritten, whether a command actually ran. That data was collected to verify milestones, but it is the workspace snapshot, so compaction can carry it across directly without asking a model to summarize it again.
The hard half is the other two. What has been established and what is still open currently exist only if the model writes them down, which is exactly why they are the first casualties of compaction.
This is measurable, not arguable
After compaction, if the agent re-reads a file that was compacted away, or re-asks a question already answered, the assumption failed on that task and the evidence is right there.
The instrumentation is simple: intersect the file paths read after the compaction point with what was recorded before it.
With that number, which task types can be compacted aggressively and which cannot becomes a query rather than a design argument. It is the same approach as the first note in this series: measure first, then change something.
Where this has to be discounted
None of this is shipped. We are at design and instrumentation.
Which fields to keep and at what granularity should come from data on what actually gets re-fetched. Deciding now is a good way to decide wrong.
And this is one approach among several. Where the boundary goes and how the fields are defined could look completely different in another product shape. The four-case checklist travels; the specific answer does not.
The next and final note in this series covers self-reflection: why an agent's distilled lessons keep coming out as generic as "be more careful," and one genuinely surprising thing about what its inputs do and do not contain.