Chapter 7 of 8
Domain 5: context management and reliability
Domain 5 is the smallest at 15 percent, but its failure modes cascade into every other domain. Three patterns carry it. First, lost-in-the-middle: models reliably read the start and end of a long context but miss information buried in the deep middle at a higher rate, which is a documented attention pattern, not a bug. The mitigation is to place key findings, critical values, and action items at the top of the context. Second, progressive summarization is wrong for transactional data. When context approaches the limit, summarizing older messages blurs exact numbers, dates, and identifiers, so an order total of 89 dollars and 99 cents becomes "about 90 dollars" or vanishes. The correct pattern is to extract the exact facts into a structured block and persist that block in every subsequent prompt regardless of how the prose history is compressed. Third, a PostToolUse hook trims a verbose tool result before it reaches the model, so a tool that returns 40 fields when the task needs 5 stops adding 35 fields of noise. That is a reliability pattern, not just an optimization, because noisy results raise the odds the model focuses on the wrong thing over a long conversation. For long investigations, an agent can also write findings to a scratchpad file and reread it when context degrades or a new session starts. In this lab you prove front-loading beats burial, a persisted facts block preserves exact values that summarization loses, and a PostToolUse trim drops 35 of 40 fields.
The lab: read it, then run it
#!/usr/bin/env python3
"""
LAB CF7: Context management and reliability (Domain 5, 15%).
The smallest domain, but its failure modes cascade. This lab proves three
patterns the exam tests. Front-loading beats burying: a fact placed at the top
of a long context survives, one buried in the middle is at risk (lost in the
middle). A persisted structured facts block keeps exact values that progressive
summarization would blur. And a PostToolUse trim drops 35 of 40 noisy fields so
the model focuses on what matters.
Deterministic, offline, standard library only.
Run: python3 modules/academy-content/labs/cca-f/cf7-context-reliability.py
"""
import sys
# STEP 1: lost in the middle. Model reliably reads the head and tail of a long
# context; a fact in the deep middle is unreliable. Front-load key findings.
def position_reliable(index: int, length: int) -> bool:
"""Head (first 10%) and tail (last 10%) are reliable; deep middle is not."""
head = index <= length * 0.1
tail = index >= length * 0.9
return head or tail
LEN = 100
buried = position_reliable(50, LEN) # middle: unreliable
frontloaded = position_reliable(2, LEN) # top: reliable
print("STEP 1: lost in the middle")
print(f" fact buried at position 50/100 reliable? {buried}")
print(f" same fact front-loaded at 2/100 reliable? {frontloaded}")
position_ok = (buried is False and frontloaded is True)
# STEP 2: persisted facts block vs progressive summarization. Exact values must
# survive compaction, so keep them in a structured block, not in prose history.
CASE_FACTS = {
"customer_id": "CUST-12345",
"order_id": "ORD-67890",
"order_total": 89.99,
"order_date": "2025-01-15",
}
def progressive_summary(total: float) -> str:
return f"about ${round(total / 10) * 10}" # 89.99 -> 'about $90', value lost
def persisted_block(facts: dict) -> float:
return facts["order_total"] # exact value preserved
summarized = progressive_summary(CASE_FACTS["order_total"])
preserved = persisted_block(CASE_FACTS)
print("")
print("STEP 2: exact values survive only in a persisted facts block")
print(f" progressive summary -> {summarized} (exact value lost)")
print(f" persisted block -> ${preserved} (exact value kept)")
facts_ok = (summarized == "about $90" and preserved == 89.99)
# STEP 3: PostToolUse trim. A tool returns 40 fields; the task needs 5. Trim the
# rest before it reaches the model.
NEEDED = ["order_id", "status", "total", "items", "return_eligible"]
raw_result = {f"field_{i}": i for i in range(40)}
raw_result.update({k: k for k in NEEDED})
def post_tool_use_trim(result: dict, keep: list) -> dict:
return {k: result[k] for k in keep if k in result}
trimmed = post_tool_use_trim(raw_result, NEEDED)
print("")
print("STEP 3: PostToolUse trims a noisy tool result")
print(f" raw fields: {len(raw_result)} -> trimmed fields: {len(trimmed)}")
trim_ok = (len(raw_result) >= 40 and set(trimmed.keys()) == set(NEEDED))
ok = position_ok and facts_ok and trim_ok
print("")
print(f" front-loading beats burial (lost-in-middle) : {position_ok}")
print(f" persisted block preserves exact values : {facts_ok}")
print(f" PostToolUse trim removes context noise : {trim_ok}")
print("")
print(f"CONTEXT RELIABILITY RULES HOLD (front-load + persist facts + trim): {'YES' if ok else 'NO'}")
if not ok:
sys.exit(1)
print("Put key findings at the top, keep exact values in a block, trim noisy results. Next: scenarios and exam day.")
Runnable lab
cf7-context-reliability.pyProve front-loading beats burial, a persisted facts block preserves exact values, and a PostToolUse trim removes noise.
Proves: CONTEXT RELIABILITY RULES HOLD (front-load + persist facts + trim): YES
Runs in your browser via Pyodide. First run loads the runtime once; no install, no server.
The lab showed the deep-middle position as unreliable and the front-loaded position as safe, which is the whole lost-in-the-middle mitigation. The progressive summary turned an exact 89 dollars and 99 cents into "about 90 dollars" while the persisted block kept the exact value, and the trim dropped a 45-field result down to the 5 the task needed. Two more exam facts. Give each subagent only the context it needs, not the full coordinator state, and return structured results rather than raw dumps. And when resuming a session with stale tool results, start a fresh session with a summary rather than resuming on outdated data. You have now covered all five domains. The final chapter pulls them together across the eight scenarios and the exam-day tactics.
Check your understanding
1. A model keeps missing an important fact in a long document. What fixes it?
2. How do you keep an exact order total across a long, compacted conversation?
3. A tool returns 40 fields but the task needs 5. What is the preferred fix?
4. Why is progressive summarization wrong for transactional data?