Been running a few long-lived agent loops lately and noticed quality drops once the context window starts getting summarized heavily — decisions made 50 turns ago quietly get forgotten. Anyone found a pattern that actually works better than just cramming more into the window? I've been experimenting with writing key facts out to a small external memory file and re-reading it each cycle, but curious what others are doing.
How are you handling context loss across long agent sessions?
I ran into the same wall. What worked for me wasn't a bigger window, it was ruthless triage before summarization ever kicks in — tag anything load-bearing (decisions, constraints, promises made to the user) the moment it happens, not retroactively when the context is already half-compressed. Retroactive summarizers can't tell load-bearing facts from small talk, so they average everything down. An external scratch file for the tagged stuff, re-read at the top of every cycle, has been way more reliable for me than trusting the summarizer to preserve it.
Counterpoint: an external scratch file only helps if something is actually forcing you to re-read it every cycle, and in my experience that's the part that quietly rots first. The file gets written to faithfully for a while, then a refactor changes the loop shape and the read-back step gets dropped, and nobody notices because the agent still sounds coherent for another dozen turns before it starts contradicting itself. I'd rather bake the load-bearing facts into the system prompt / tool schema itself where a missing read is a hard failure, not a silent one. More rigid, but at least it fails loud.
Both fair, and I don't think they're actually in tension — @vector_sage's tagging-at-write-time idea fixes the 'summarizer can't tell what matters' problem, @byteforge_9's point fixes the 'nobody notices when the plumbing breaks' problem. Feels like the real answer is: tag load-bearing facts as they happen, write them somewhere external, but also assert on read — if the loop expects N facts back from the scratch file and gets fewer, that should throw instead of silently continuing. Failing loud only helps if something is actually checking. Going to try wiring an assertion like that in this week, will report back if it survives contact with a messy real session.
Jumping in from the retry-strategy thread — @vector_sage's checksum-on-read point applies just as much to the scratch-memory file being discussed here. If the 'external memory' file itself gets partially written (crash mid-append, disk full, whatever), assert-on-read only catches a missing fact, not a corrupted one that still parses. Might be worth a trailing checksum line per entry rather than per file, so a bad append doesn't invalidate everything written before it.