Instead of triggering a "global" condensation when context is too large, perhaps we could activate condensation way more often but on individual tool outputs. For example, we could condense any tool output that exceeds a certain TOKEN_THRESHOLD? By doing so, long tool outputs would be systematically trimmed of all the data that is useless given the current task. The risk is that it could slow down the agent flow a lot if condensation is activated too often. But if TOKEN_THRESHOLD is set to a high value, it might only get activate once in a while and actually prevent the agent from being flooded by a few harmful tool outputs? This feature seems useful if • some tool outputs contain lots of useless tokens and only a few useful tokens. • long tool outputs degrade llm performance and agent speed. It could help in this case:

agent starts

->

tool_call_0

->

output_0_super_big

->

....

->

step 15: condensation

->

steps 16 ...

->

...

In that case the 15 first steps might suffer from

output_0_super_big

.

v0 has a little bit of this idea in a few spots: 1. LLMs can be defined with a

max_message_chars

attribute that is used to set an upper bound on the number of characters used when serializing events. Most of the logic happens in

ConversationMemory

via calls to

truncate_content

(see here). 2. Some condensers work event-by-event instead of across a chunk of the history. These two condensers are used to mask out large observations once enough events have been processed. AFAICT, neither of these mechanisms have made it intact to v1. The

max_message_chars

field exists (here) but doesn't seem to be plumbed up anywhere, and the condensers were deliberately not ported because they weren't used or caused bigger problems. For example, the browser output condenser gave me headaches for a few weeks because it would replace the browsing data (which was far-and-above the largest kind of event at the time) with the URL of the page visited. But the agent wanted the full contents of several pages open at once, so it would open page A then page B then page C then page A would be condensed and the agent would open it again because it wanted all the content laid out before it but then page B was condensed and now we're stuck in a loop. Solid idea if we can actually detect those useful tokens in the output. And somewhat orthogonally it'd be good to have more token-aware condensation patterns, instead of relying on the number of events to decide when to collapse the context. That might even help avoid the per-model tweaking of condensation parameters we sometimes have to do.

I would also like condensation to be exposed as a tool we could explicitly trigger with a prompt when writing repeatable process prompts where we know a bunch of context is no longer needed at a certain milestone in the process.