Blöcke mit Fallfakten und Kürzen der Ausgabe

In a long agentic conversation, the full message history grows past what's comfortable to keep in context. The common fix is progressive summarization: compress older turns into a running summary so the window stays manageable.

But summarization has a quiet failure mode. It's great at preserving the gist of a conversation and terrible at preserving exact values. As you compress, the precise things a model needs to act correctly start to blur.

Progressive summarization makes numbers, percentages, and dates vague. A turn that said "order #88231 shipped 2026-03-14, refund of $412.50 approved" can degrade into "the customer's order shipped recently and a refund was approved."

That's fine for narrative flow, but catastrophic for a tool-calling agent that must pass order_id=88231 or reason about a $412.50 threshold. The model can't recover a value the summary already erased.

The architectural pattern is to pull transactional facts into a separate "case facts" block kept verbatim, outside the summary. The summary handles the conversational narrative; the case-facts block holds the exact, load-bearing values.

Crucially, this block is never summarized or compressed. When you compact older turns, the case-facts block passes through unchanged. The summary can be lossy; the facts cannot.

Put anything exact and consequential in the case-facts block:

• IDs: order numbers, customer IDs, ticket numbers, SKUs
• Amounts and thresholds: refund totals, balances, limits
• Dates and timestamps: ship dates, deadlines, SLA windows
• Verified identity state: e.g. "customer identity confirmed via get_customer"

Leave chit-chat, rephrasings, and explanatory prose in the summary. The test: would a wrong or vague value here cause a wrong action? If yes, it's a case-fact.

Keep the case-facts block as terse, structured key/value lines — easy for the model to scan and copy verbatim into tool inputs. Inject it into the system prompt or as a pinned context block that rides along every turn.

The two pieces are complementary. On each turn you send: a compressed summary of older narrative, the verbatim case-facts block, and the recent raw turns. Remember the model keeps no state — you resend this whole assembly every request.

The summary keeps the window small; the case-facts block guarantees the exact values survive. Compress aggressively in the summary, knowing the facts that matter are safe elsewhere.

There's a second reason placement matters. Models exhibit a lost-in-the-middle effect: they attend more strongly to the start and end of the context than to the middle.

So a critical fact buried in the middle of a huge tool dump or a long summary is the most likely thing to be overlooked. Position your case-facts block where attention is strongest — early in the system prompt or pinned near the end of the input.

Case-facts solve retention. The second discipline is controlling what enters the window in the first place. Tools — APIs, database queries, file reads — often return huge, deeply nested JSON payloads, most of which is irrelevant to the decision at hand.

Appending that raw blob to history bloats the window, pushes important content into the lost-in-the-middle zone, and dilutes the model's attention. The rule: trim verbose tool output to the relevant fields before the model sees it.

Do the trimming deterministically in your own code, between getting the raw result and appending it to the message history. Extract only the fields the model actually needs to reason or to fill the next tool call.

You can also enforce trimming with a PostToolUse hook, which intercepts a tool result before the model sees it. This makes trimming deterministic and centralized rather than relying on each tool's implementation to behave.

The hook is the right home for a strict, always-applied projection of fields — the same deterministic-enforcement logic you'd use for any policy that must run 100% of the time, not ~90% of the time as a prompt would.

Trim for relevance — not so hard that you discard what you'll later need to act or to cite. If a value is going to drive a tool call or a customer-facing claim, promote it into the case-facts block instead of dropping it.

One clean division of labor: trim tool output going into the running history, and pin the exact values that must survive into the verbatim case-facts block. Lossy where it's safe, verbatim where it's not.

A support agent runs long multi-turn sessions. To stay in budget, older turns are progressively summarized. Testers report it sometimes refunds the wrong amount or passes a stale order number after the conversation has run a while. What's the best fix?

Key takeaways:

• Progressive summarization blurs exact values — numbers, percentages, and dates go vague.
• Pin transactional facts in a verbatim case-facts block outside the summary; the summary may be lossy, the facts must not be.
• Lost-in-the-middle: models attend most to the start and end — place critical facts there, not buried mid-context.
• Trim verbose tool output to relevant fields before appending to history; a PostToolUse hook makes this deterministic.
• Division of labor: trim what flows into history, pin what must survive verbatim. Lossy where safe, exact where it counts.