Context Management & Reliability

Long interactions degrade in predictable ways, and an architect's job is to curate what stays in the context window. Anthropic calls the core failure mode context rot: as token count grows, the model's ability to accurately recall any single fact drops, because transformer attention is spread across n² pairwise relationships. A related effect is lost in the middle - models reliably attend to the beginning and end of a long input but may omit findings buried in the middle.

The most common self-inflicted damage is progressive summarization that compresses exact values into vague prose. Numbers, percentages, dates, order numbers, statuses, and customer-stated expectations must survive verbatim. The fix is a separate, non-summarized layer: extract transactional facts into a persistent "case facts" block (and, for multi-issue sessions, structured per-issue records with order IDs, amounts, statuses) that is re-injected into every prompt, untouched by summarization of the chat history.

Tool results are the other context hog. A single order lookup may return 40+ fields when only ~5 are relevant; these accumulate and consume tokens disproportionate to their value. Trim verbose tool outputs to only the relevant fields before they enter context. Anthropic notes that clearing stale tool results is one of the safest, lightest forms of compaction.

To fight position effects, put a key-findings summary at the top of any aggregated input and organize details under explicit section headers so nothing important hides in the middle.

In multi-agent systems, downstream agents have limited context budgets, so upstream/subagents should return structured data - key facts, citations, relevance scores, and required metadata (dates, source locations, methodological context) - rather than verbose content and reasoning chains. This supports accurate downstream synthesis.

Finally, the API itself is stateless: you must pass the complete conversation history (or a faithful compacted equivalent plus the preserved facts block) in each request to maintain coherence. The Agent SDK and Claude Code manage this for you, but the principle stands: coherence comes from what you re-supply, not from the model remembering.

Good escalation design routes the right cases to humans without over- or under-escalating. The three legitimate escalation triggers are: (1) the customer explicitly asks for a human; (2) policy is ambiguous, silent, or the request needs a policy exception/gap decision - not merely that the case is technically complex; and (3) the agent cannot make meaningful progress. Note that 'complex' alone is not a trigger; capability and policy coverage are what matter.

Two unreliable proxies are explicitly tested. Sentiment-based escalation (escalating because the customer sounds angry) and self-reported confidence scores are poor stand-ins for actual case complexity - a frustrated customer may have a trivially resolvable issue, and a model's stated confidence does not track correctness. Don't gate escalation on either.

There is a key distinction between honoring an explicit demand and offering to help. If a customer explicitly demands a human, transfer immediately - do not first attempt investigation. If the customer is merely frustrated but the issue is within the agent's capability, acknowledge the frustration and offer to resolve it, escalating only if they reiterate the human request.

For policy ambiguity, escalate when the policy is silent on the specific ask. Classic example: policy covers price adjustments on your own site, but the customer wants a competitor price match the policy never addresses - that gap should escalate rather than be improvised.

For identity ambiguity, when a lookup returns multiple matching customers, do not pick one heuristically; ask for an additional identifier (email, order number, ZIP) to disambiguate.

The implementation lever is the system prompt: add explicit escalation criteria with few-shot examples demonstrating escalate-vs-resolve decisions. In the Agent SDK, the AskUserQuestion tool supports asking clarifying questions; Anthropic's broader guidance is to design agents to return to the human for judgement at blockers rather than guessing.

In multi-agent systems built on the orchestrator-worker (lead-coordinator) pattern, how subagents report failure determines whether the coordinator can recover intelligently. The core skill is structured error context: instead of a generic status, a failing subagent returns the failure type, what was attempted (the query/tool/parameters), any partial results already gathered, and potential alternative approaches. With that, the coordinator can retry, reroute, narrow scope, or proceed with partial coverage.

Two anti-patterns bookend the space. Silently suppressing errors - returning empty results as if the query succeeded - hides failure and corrupts downstream synthesis. Terminating the entire workflow on a single subagent failure is equally wrong: one unavailable source should not kill an otherwise-recoverable run. Anthropic's multi-agent system instead uses durable execution that can resume from where the error occurred, plus retry logic and checkpoints, and lets agents adapt when a tool is failing.

A critical distinction: an access failure (a timeout or unavailable tool) needs a retry/reroute decision, whereas a valid empty result (the query ran successfully and simply found no matches) is a legitimate finding. Collapsing both into a vague "search unavailable" destroys the information the coordinator needs to decide correctly.

Responsibility is layered: subagents implement local recovery for transient failures (retry a timeout, try a narrower query) and only propagate errors they cannot resolve, attaching what was attempted and any partial results. Generic statuses like "search unavailable" should be avoided precisely because they strip this context.

Finally, the synthesis output should carry coverage annotations - which findings are well-supported versus which topic areas have gaps due to unavailable sources - so the final answer is honest about its blind spots rather than presenting partial coverage as complete.

Exploring a large codebase is a marathon for context. In extended sessions you see context degradation: the model starts giving inconsistent answers and referencing "typical patterns" instead of the specific classes and files it discovered earlier - a symptom of context rot. Three techniques counteract it.

First, subagent delegation. A subagent runs in its own fresh context window, does verbose work (reading dozens of files), and returns only a small summary (the Claude Code visualization shows a subagent reading ~6,100 tokens of files and returning ~420 tokens). Spawn subagents for scoped questions - "find all test files," "trace the refund-flow dependencies" - so the main agent keeps high-level coordination clean and the verbose discovery never touches the main window. The Agent SDK exposes this via AgentDefinition (include Agent in allowedTools); Claude Code via .claude/agents.

Second, scratchpad / note files. Have agents write key findings to a file (a scratchpad, or CLAUDE.md / auto memory MEMORY.md) and reference it for later questions. This is durable external memory that survives context boundaries. Before moving from one exploration phase to the next, summarize key findings and inject the summary into the next phase's initial context.

Third, /compact reduces context usage mid-session by replacing the conversation with a structured summary; you can steer it (e.g., /compact focus on the refund flow). Note what survives: project-root CLAUDE.md is re-read and re-injected after compaction, but conversation-only facts are not - which is exactly why a scratchpad/CLAUDE.md matters.

For crash recovery, design structured state persistence: each agent exports its state to a known location, and the coordinator loads a manifest on resume and injects it into agent prompts, so the run continues from where it stopped instead of restarting. This mirrors Anthropic's use of checkpoints, durable execution, and a feature manifest in long-running agents.

Before you automate high-confidence extractions and pull back human review, you must prove the system is reliable where it matters - and aggregate metrics can lie. A headline like 97% overall accuracy can mask poor performance on a specific document type or a specific field. So the first skill is segmented validation: analyze accuracy by document type and by field and confirm consistent performance across every segment before reducing review. A model that is 99% on invoices but 70% on handwritten forms must not be treated as uniformly 97%.

Second, field-level confidence scores. Have the model output a confidence per extracted field, then calibrate review thresholds on a labeled validation set so a reported confidence maps to an actual error rate. Calibration is what makes "high confidence" a usable routing signal rather than a vibe.

Third, routing. Send to human review the extractions that most need it: low model confidence, and cases where the source documents are ambiguous or contradictory. This prioritizes scarce reviewer capacity on the riskiest items instead of spreading attention uniformly.

Fourth, even after automating, keep a safety net via stratified random sampling of high-confidence extractions. Ongoing sampling measures the real error rate in the auto-approved tier and detects novel error patterns (a new vendor template, a format change) that confidence scores haven't learned yet. Stratify the sample across document types and fields so rare-but-critical segments are actually represented - plain random sampling can miss them.

The through-line mirrors Anthropic's guidance on matching oversight to risk: automate the well-validated, calibrated, low-risk paths; route ambiguous/low-confidence/high-stakes items to humans; and continuously monitor with stratified sampling rather than trusting a single aggregate number.

When findings flow through multiple agents and summarization steps, the danger is that provenance is silently lost: summarizing compresses claims while dropping the claim-to-source mapping, so the final report asserts facts with no traceable origin. The fix is to require structured claim-source mappings at every hop - each claim carries its source URL or document name and a relevant excerpt - and to make the synthesis agent preserve and merge those mappings rather than flatten them. Anthropic's multi-agent system reflects this with a dedicated CitationAgent that attributes every claim to its source.

Handling uncertainty and conflict is the second pillar. When credible sources report conflicting statistics, do not arbitrarily pick one value. The analysis agent should complete its work with both values included and explicitly annotated (with source attribution), and let the coordinator decide how to reconcile before synthesis. The final report should structure findings into explicit sections distinguishing well-established from contested claims, preserving each source's original characterization and methodological context instead of homogenizing them.

Temporal data is a frequent false-conflict source. Require subagents to include publication or data-collection dates in structured outputs, so a 2023 figure and a 2026 figure are interpreted as a time series, not a contradiction. Without dates, temporal differences masquerade as disagreements.

Finally, render content types appropriately in synthesis: financial data as tables, news as prose, technical findings as structured lists. Forcing everything into one uniform format loses meaning and can obscure the structure that makes provenance and conflicts legible. The unifying idea: synthesis should carry forward sources, dates, conflicts, and methodological context as first-class structured data - never paraphrase them away.