Blocos de Fatos do Caso e Corte da Saída
Mantenha os fatos fora do resumo; corte resultados prolixos de ferramentas.
Blocos de Fatos do Caso e Corte da Saída é uma aula grátis de Claude Architect no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Claude Architect, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Claude Architect inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
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.
Perguntas Frequentes
A aula “Blocos de Fatos do Caso e Corte da Saída” é grátis?
Sim — o texto completo de “Blocos de Fatos do Caso e Corte da Saída” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Claude Architect, atualize para CoddyKit PRO. O curso de Claude Architect inclui 4 aulas no total.
O que vou aprender em “Blocos de Fatos do Caso e Corte da Saída”?
Mantenha os fatos fora do resumo; corte resultados prolixos de ferramentas. Você pratica Claude Architect com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Claude Architect?
Nenhuma experiência prévia é necessária. Claude Architect no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Blocos de Fatos do Caso e Corte da Saída”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Claude Architect?
Sim. Cada aula de Claude Architect inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Todo o Histórico é Necessário
- Riscos da Sumarização Progressiva
- Efeito de Perda no Meio
- Blocos de Fatos do Caso e Corte da Saída