An agent forty minutes into a task has read three files, run the test suite twice, caught a stack trace, and written a plan for the fix. The window fills, compaction runs to evict history and make room, and the stack trace is what goes, because it is long and it is old. The next turn is spent re-running the tests to recover something the agent already had.
Favur is a team of agents that takes a written specification and builds the software from it, planning, coding, reviewing and testing with nobody driving. Jobs run long enough that this is the ordinary case rather than an edge case. One this month made over ten thousand model requests before it finished, and its full public record is here
Problem: Compaction is ignorant
By the time compaction fires, it is looking at four hundred messages of undifferentiated text. Some are tool results the agent consumed once. One is the plan it wrote. One is a directive a person typed. Nothing distinguishes them.
The only properties left are length and recency, and both are anti-correlated with what matters. The stack trace is long and old and the next turn needs it; the directory listing is short and recent and is already spent.
Most of the work in this area goes into making that judgment sharper. Give the model a tool to prune its own history. Train a smaller model to score relevance. Summarize in layers. All of it is real engineering, and all of it accepts that the judgment happens when the window is full, which is the one moment the system knows least about its own history.
Our Solution: Classify at append
Every message arrived through a specific call site, for a specific reason. At that instant nothing was ambiguous. The code knew it was recording a tool result for immediate consumption, or persisting a plan, or logging a directive. Then it kept the text and discarded the reason, and an hour later was left reconstructing it from undifferentiated text.
So Favur assigns a retention class at append time. Three of them, and the names carry the whole scheme. Forgettable, fuzzy, strict. The call site picks one, because the call site is the only part of the system that knows.
Progress reports, the journal an agent writes to itself and reads back to recover its own state, are appended strict. That keeps the journal available through the early compression rounds, which is when the agent is most likely to reach for it. Strict is not exemption, though. At the highest tier the journal is dropped like everything else. A directive injected into a running agent is appended strict for the same reason.
Compaction then carries no judgment. Under pressure it does not read messages, it reads the message classification.
What the tiers actually do
The first tier (typically 5% usage) summarizes forgettable and fuzzy material and deletes nothing. The history shortens; the shape of what happened survives compressed.
The second tier (10% usage) drops that material and begins summarizing strict. The journal and the directives are still present, smaller.
The third (25% usage) drops all three classes. We usually limit window usage to 50% - over that and the agent fails.
Circling back to the stack trace example - its appended strict, the stack trace is still there when the next turn reaches for it, because strict is not summarized until the second tier and not dropped until the third. Appended the way a directory listing deserves, it is a summary after the first tier and gone after the second, which is correct for a directory listing and wrong here. Neither outcome was compaction's call. Both were decided at the append.
The tier thresholds are configuration rather than constants. A trigger frozen into a client is a single opinion about when a conversation has run long, applied to every job that client will ever run, and the correct value for a two hour refactor is not the correct value for a six exchange question.
What the design costs
Moving the decision to the point of maximum information also moves it to the point of maximum call sites.
A compaction routine is one piece of code, wrong in one findable place. Retention classes are the opposite trade. Every line that appends a message now makes a small judgment, and a wrong one is silent, because a message appended forgettable does not announce that it should have been strict. It leaves a tier earlier than intended, in a job nobody is watching, and what surfaces much later is an agent that appears to have forgotten something.
The scheme is also only as good as its most careless call site. The tiers sort by intent for exactly as long as every message carries an intent, and one that arrives without a class is back to being sorted by length and recency while everything around it is sorted properly. That is not a visible failure. It is a region of the history quietly reverting to the behavior the design existed to replace.
Where that leaves compaction
Compaction is treated as a summarization problem and it behaves like a labeling problem. The labels are simply absent by the time anything goes looking for them.
Move the judgment to the append and the process that runs under pressure needs no intelligence at all. What that produces is not an agent with a larger window. It is an agent whose window empties in an order somebody chose.
Read more on our product site.
Favur Evals, the public benchmark these runs are scored on
Favur itself is invite-only for now. If you want to hand it a specification of your own, the waitlist is here
Top comments (2)
Append time knows where a message came from, not how long it will matter. Your own stack trace shows it: strict is right up until the fix goes green, and from then on the class preserves dead weight through two more tiers. The judgment happens once, but relevance keeps moving after it.
I ended up not deciding what the window keeps at all. In a game I run where models play against people, every step's state is stored outside the context, and each step gets the exact slice it needs injected as the last message - so compaction never holds anything I can't rebuild. Different trade: my call sites decide what to inject, yours decide what to retain, and both are wrong silently. Can a class change after append, or is the first judgment final?
Nothing reassigns a class after append. It comes off the call site's priority when the message is written and stays there, so yes - a strict stack trace is still strict long after the fix goes green.
A stale strict message does not ride at full size, though. Strict gets summarized at the middle pressure tier and only dropped at the top, so the weight shrinks a tier before it goes. These messages are also only around per agent - which have a lifetime of anywhere from 10 minutes to 2 hours. So a single
strictmessage is not in the conversation for days.Your design makes the question moot. We maintain conversation threads for agents and thus the context window can grow forever.