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

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

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

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