Trim, Summarize, or Retrieve? Three Ways to Survive a Long Agent Run

Around turn thirty, a long-running agent hits the same wall regardless of what it's doing: the context no longer fits. There are three standard responses, they fail in different ways, and picking the wrong one produces failures that look like the model getting dumber over time.

The three strategies

Trimming drops old turns, usually oldest-first, keeping the system prompt and the most recent N exchanges. Cheap, predictable, zero extra model calls.

Summarizing replaces a span of old turns with a model-generated précis. Preserves the gist of a long history in far fewer tokens, at the cost of an extra model call and whatever the summary omitted.

Retrieval stores turns or artifacts externally and pulls back only what's relevant to the current step. Keeps context small indefinitely, at the cost of an index to maintain and a relevance judgment that can miss.

What each one loses

This is the part that decides the choice, and it's rarely stated plainly.

Trimming loses the oldest information, completely and silently. That's usually where the task definition, the user's constraints, and the early decisions live. → The characteristic failure: an agent that starts violating a rule it obeyed for the first twenty turns, because the rule scrolled off. Nothing in the trace marks the moment it happened.

Summarizing loses specificity, unpredictably. Summaries keep narrative and drop identifiers. "Checked several accounts and found two with issues" is a faithful summary that has destroyed the account IDs the next step needed. Worse, a summary of a summary compounds — run long enough and the early history becomes a vague impression with confident tone.

Retrieval loses whatever the query didn't match. Failure is invisible from inside the run: the agent doesn't know a relevant turn existed and wasn't returned. It proceeds as though the record is complete.

A decision rule that holds up

Ask what the run's later steps need from its earlier steps.

• Later steps need only recent state (a conversation, a linear workflow where each step consumes the previous output) → trim, and stop there. It's the cheapest and its failure mode is the easiest to reason about.
• Later steps need the narrative — what was tried, what was ruled out, why the approach changed (research, investigation, debugging) → summarize, but see the pinning rule below.
• Later steps need arbitrary specifics from anywhere in a long history (large document sets, multi-day sessions, many entities) → retrieve.
• Many runs need two of these, and combining them is normal, not a design smell.

💡 The pinning rule that fixes most of this

Whatever strategy you pick, some content must never be eligible for compaction. Keep a pinned region that is re-sent verbatim on every call:

• the original task as stated
• hard constraints the user gave ("nothing before 10am", "read-only on production")
• identifiers the run has committed to — ticket IDs, account numbers, file paths
• decisions already made and not to be revisited

Pinning is what separates a compaction scheme that degrades gracefully from one that produces an agent which contradicts its own instructions in hour two. It costs a few hundred tokens per call and prevents the single most common long-run failure.

A useful implementation detail: keep the pinned region as structured state your loop owns, not as messages in the array. The loop appends it fresh each turn. Then no summarizer can rewrite it and no trimmer can drop it, because it isn't part of the history being compacted at all.

Making the losses visible

Each strategy has a cheap instrument that turns a silent failure into a loud one:

• Trim → log the turn index of the oldest surviving message. When that number jumps past the point where the task was defined, you know constraints are now out of scope.
• Summarize → keep the pre-summary span on disk, keyed by run. When a run goes wrong, diff what the summary kept against what was there. The pattern of what gets dropped is remarkably consistent, and one look usually tells you what to pin.
• Retrieve → log the queries and the IDs returned, every time. Retrieval failures are query failures nine times out of ten, and you cannot debug a query you never recorded.

The takeaway

These are not three tiers of sophistication where retrieval is the mature answer. They are three different bets about what old information the run will need. Trim when the past is genuinely spent. Summarize when the shape of the past matters more than its details. Retrieve when any detail might come back. Whichever you choose, pin the task, the constraints, and the identifiers outside the compactable region — most "the agent forgot" incidents are a pinning failure wearing a compaction costume.