LangChain's Deep Agents offloads oversized tool output to a filesystem at 20,000 tokens

All three steps keep the original bytes. A tool response over 20,000 tokens goes to a file, and what stays in the history is the path plus a preview of the first 10 lines ^[4]. Write and edit arguments are already persisted by definition, so truncating them to a pointer discards a duplicate ^[14][5]. Even summarisation writes the complete original messages to the filesystem as a canonical record ^[8]. What is lost is lost from the window, and recovery is a read_file call; Chester Curme and Mason Daugherty link a trace where the model does exactly that to fetch previously offloaded messages ^[11][2].

The triggers use different units. Tool-result offloading fires at a fixed 20,000 tokens ^[4]. Tool-input truncation fires when session context crosses 85 percent of the model's available window, and the thresholds are fractions of the window taken from LangChain's model profiles, which supply the token limit for the model you configured ^[5][9]. So the step that fires most often is the one working from a flat count, with the model profile playing no part in it ^[16]. On a small-window model, one 20,000-token response is most of the budget; on a very large one it is noise. It goes to disk either way.

The substitution moves a decision onto the model. It sees a path and ten lines, and it has to work out whether what it needs is further down ^[4][10]. For a directory listing or a file head, ten lines usually identify the content. For a long JSON envelope, or a log with a banner, the first ten lines describe the wrapper. In my view the first thing to test is an agent that treats the preview as the answer and stops there.

Adopting this means adopting the filesystem. The abstraction covers listing, reading, writing, search, pattern matching and file execution, and agents use it to search and retrieve offloaded content as needed ^[10]. Tool output the harness saves on its own now lands in that store, and the same abstraction can execute files.

The measurement note is the useful part of the post. Curme and Daugherty write that runs on real-world tasks, in benchmarks such as terminal-bench, trigger compression only sporadically, and that makes individual features of the harness hard to isolate ^[12]. Their answer is to raise the trigger: summarising at 10 to 20 percent of the available window produces significantly more summarisation events and lets two implementations be compared, though they note it "may lead to suboptimal overall performance" ^[13]. A summary written every few turns loses different things than one written once, late, over a long history. For a summariser change validated at 10 to 20 percent to hold at the shipped default, its failure modes under heavy compression have to be the same ones it has at 85 percent ^[5].