## TL;DR
A 200-message thread does not fit in the context window, and truncating from the front loses the original problem while truncating from the back loses the latest state. Summarize in chunks: compress older messages into a running summary, keep recent messages verbatim, and always preserve the key facts (ids, decisions, promises) structurally. The agent needs the story of the thread, not every word of it.

## The query

```text
200-message ticket thread overflowed the agent's context window: chunked summaries
```

## Use this when

- Agents fail or degrade on long threads
- Context limits cut off ticket history
- You are building agents that read tickets
- Debugging "the agent missed earlier context"

## Not for

- Configuring model context limits
- Ticket UI pagination design
- Choosing between LLM providers
- Ticket archiving policy

## Steps

### 1. Split the thread into chronological chunks

Divide the messages into chunks that each fit comfortably: older chunks get summarized, the newest chunk stays verbatim. Chronological order preserves the story; arbitrary splits lose it.

Expected output: chunked thread with a verbatim recent tail.

### 2. Summarize each older chunk with facts preserved

Summarize chunk by chunk, carrying forward a running summary. Instruct the summarizer to preserve identifiers, dates, decisions, and promises verbatim: these are the facts the agent will act on, and paraphrasing them introduces errors.

Expected output: running summaries with exact facts intact.

### 3. Keep structured key facts alongside the summary

Extract and store the load-bearing facts separately: order ids, error strings, promised actions, current status. Structured facts survive summarization loss and give the agent reliable anchors.

Expected output: a structured fact sheet per long thread.

### 4. Budget context explicitly per thread size

Decide the split by token budget: summary gets X, recent messages get Y, facts get Z. Fixed budgets keep behavior predictable across threads of any length. Unbudgeted inclusion is how overflows happen.

Expected output: explicit token budgets enforced per thread.

### 5. Detect when summarization loses something critical

Spot-check: have the agent answer "what did we promise the customer" from the summary and compare against the full thread. Lossy compression needs quality control; the check catches summarizer failures before they reach the customer.

Expected output: summary quality spot-checks.

## Template: the checklist

```text
Long-thread context handling:
[ ] Thread chunked chronologically, recent tail verbatim
[ ] Running summaries preserving exact facts
[ ] Structured key-fact sheet alongside summaries
[ ] Explicit token budgets per thread
[ ] Summary quality spot-checks
```

## Variant phrasings

### ticket thread too long for agent context

Steps 1 and 2. Chunk and summarize.

### context window overflow support ticket

Steps 2 and 4. Summaries plus budgets.

### agent missed earlier messages long thread

Steps 3 and 5. Fact sheet plus quality checks.

## Why it happens

Long threads accumulate the way support conversations do: back-and-forth clarifications, status updates, repeated summaries for new agents. The thread is a complete history, which is exactly what makes it too big: completeness and context limits are in direct tension. Naive truncation resolves the tension by deleting information blindly; chunked summarization resolves it by compressing intelligently.

## Edge cases

- Threads with many participants: attribute statements to speakers in the summary; "we promised" needs a "who."
- Attachments and screenshots: summaries cannot see images. Note their existence and key content explicitly.
- The critical message buried in the middle: recency-weighted verbatim tails miss it. The fact sheet is the backstop.
- Extremely long threads (1000+ messages): summarize hierarchically (chunks, then chunk-summaries) rather than in one pass.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VdogDP8cQ4skbtfHbUE93g