Case-Facts Blocks & Trimming Output
Pin facts outside the summary; trim verbose tool results.
Case-Facts Blocks & Trimming Output is a free Claude Architect lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Claude Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The Long-Conversation Problem
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.
What Summarization Destroys
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 Fix: A Case-Facts Block
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.
What Belongs in Case-Facts
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.
Structuring the Block
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.
CASE_FACTS = """
<case_facts>
customer_id: CUST-77421 (identity: VERIFIED via get_customer)
order_id: 88231
ship_date: 2026-03-14
refund_requested: 412.50 USD
refund_policy_threshold: 500.00 USD
</case_facts>
"""
system = (
"You are a support agent. The values in <case_facts> are "
"authoritative and exact. Always copy IDs and amounts from "
"<case_facts> verbatim; never reconstruct them from the summary.\n\n"
+ CASE_FACTS
)Summary + Facts Working Together
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.
def build_messages(summary, recent_turns):
# case_facts lives in `system`; summary + recent turns in messages
return [
{"role": "user",
"content": f"<conversation_summary>{summary}</conversation_summary>"},
*recent_turns, # last few raw turns, uncompressed
]
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system=system, # contains the verbatim CASE_FACTS block
messages=build_messages(summary, recent_turns),
tools=tools,
)Lost in the Middle
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.
The Other Half: Verbose Tool Output
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.
Trimming in Code
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.
raw = lookup_order(order_id=88231)
# raw has 60+ fields: internal flags, audit log, warehouse meta, etc.
trimmed = {
"order_id": raw["order_id"],
"status": raw["status"],
"total": raw["total"],
"ship_date": raw["fulfillment"]["ship_date"],
}
messages.append({
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": tool_use_id,
"content": json.dumps(trimmed),
}],
})Trimming with a PostToolUse Hook
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.
# PostToolUse hook: keep only whitelisted fields per tool
KEEP = {
"lookup_order": ["order_id", "status", "total", "ship_date"],
}
def on_post_tool_use(tool_name, result):
keys = KEEP.get(tool_name)
if not keys:
return result
return {k: result[k] for k in keys if k in result}Trim, but Don't Lose Provenance
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.
Quick Check
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?
Recap
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.
Frequently asked questions
Is the “Case-Facts Blocks & Trimming Output” lesson free?
Yes — the full text of “Case-Facts Blocks & Trimming Output” is free to read here on the web, and the Claude Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Claude Architect course, upgrade to CoddyKit PRO.
What will I learn in “Case-Facts Blocks & Trimming Output”?
Pin facts outside the summary; trim verbose tool results. You practise Claude Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Claude Architect?
No prior experience is required. Claude Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Case-Facts Blocks & Trimming Output” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Claude Architect lesson?
Yes. Every Claude Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Full History Is Required
- Progressive Summarization Risks
- Lost-in-the-Middle Effect
- Case-Facts Blocks & Trimming Output