Episode Six completes Foundations by connecting context, uncertainty, the traceable origin of claims, escalation, and enforcement into one controlled agent workflow rather than treating them as isolated vocabulary. A model such as Claude can reason only over information that is present, readable, and relevant in the request it is handling now. The context window is the bounded amount of instructions, conversation, evidence, and tool results available to the model during that request. Even when that window is large, capacity is not the same as attention, because important facts can become harder to use when surrounded by repeated drafts, unrelated records, and stale plans. Extra material also consumes processing space and cost, so sending everything merely because it fits is not a sound context strategy.

A good context strategy preserves the current task, authoritative facts, workflow state, material decisions, unresolved questions, and the source trail needed for the next action. An authoritative fact is a fact the system is entitled to rely on for that decision, such as a verified account status or the applicable approved policy, rather than an unsupported statement generated in conversation. Workflow state means the durable record of where the process has reached, including completed checks, pending actions, human decisions, and conditions that still block progress. Durable application state is information stored outside the model conversation so it survives when earlier conversation is shortened, a failed step is attempted again, work passes to another worker, or a particular request ends.

Bulky source material can remain in that durable storage and be brought back only when the present task needs it. Harbour Resolution is our fictional running example, a made-up organisation used to explore how an agent might support case work without pretending that any described deployment is real. Suppose a hypothetical Harbour case contains hundreds of messages, several calls, changing policy documents, and multiple transaction files. A case handler might see a button that sends the whole record to Claude, and the tempting mistake would be to assume that more context must produce a more reliable answer. The better design first indexes the material, meaning it records searchable descriptions and references that help the system locate relevant sources without treating those descriptions as the sources themselves.

Retrieval is the process of selecting source material that appears relevant to the immediate task and placing that material into the model's usable context. For a disputed transaction, retrieval might bring in the identified transaction, the customer's relevant message, the policy that applied at the transaction time, and the latest verified account state. A compact case record outside the conversation can separately retain the parties, chronology, contested facts, authoritative sources, previous human decisions, and open evidence gaps. The conversation is then a temporary working surface, while the case record and original evidence remain the sources to which consequential claims must return. This approach has a limitation: poor indexing or a badly framed search can omit crucial evidence, so selective retrieval still needs testing, traceable references, and a route for requesting more material.

The lost-in-the-middle problem is the practical tendency for important information to be overlooked when it is buried among large amounts of less relevant context, even though it technically fits. A thick paper folder is a useful analogy because a key note can disappear between routine pages, although a model's attention is not literally a person scanning paper. Stable high-priority instructions should be stated clearly, related evidence should be grouped, sources should be labelled, and the immediate question should be unmistakable. Critical instructions should not be hidden inside a customer attachment or surrounded by contradictory leftovers from earlier drafts. Retrieval quality often matters more than filling every available space, because the goal is to supply the right evidence for the present decision rather than the largest possible pile.

Prompt caching tackles a different kind of repetition by reusing earlier processing for an unchanged beginning of a later request, when the platform supports it and the cached material is still available. In our fictional case service, many requests might start with the same stable instructions and reference guide, followed by the particular case information needed now. Reusing that already-processed beginning can reduce repeated work, waiting and cost, although savings depend on reuse rather than simply switching caching on. Caching does not enlarge the context window, establish that the material is true, or replace retrieval and the durable case record. Long-running agents create another problem as tool results, abandoned approaches, repeated messages, and superseded plans accumulate across many steps.

Context editing means removing or replacing material that is no longer needed for the next decision while deliberately preserving facts and references that still matter. For example, an old draft can usually disappear after a validated replacement exists, but a failed identity check or unresolved policy contradiction must not be edited away merely because it is inconvenient. Compaction means summarising earlier conversation so work can continue within a bounded context window; in supported long-running Claude workflows, server-side compaction means that the platform handles that summarisation. A compacted summary is still a working representation rather than the authoritative record, because summarisation can omit qualifications, identifiers, dissenting evidence, or the reason behind a decision.

Consequential facts should therefore carry stable identifiers, which are persistent labels for records such as a transaction, message, policy version, or human decision. A summary saying that a customer disputed a charge is much weaker than one preserving the transaction identifier, relevant date, amount, source message references, and unresolved contradiction. Rehydration means using those stable references to fetch the original details again when a later step needs verification or more nuance. Repeatedly summarising an already compressed summary can compound small losses, much like making a copy from a copy, although the real danger here is lost meaning rather than visual blur. The safer pattern is to check consequential summaries against durable state and original evidence before relying on them for a new high-impact action.

A handoff to a specialised subagent, meaning a separate model-driven worker assigned a narrower task, or to a human reviewer creates the same information-loss risk as compaction. A useful handoff explicitly separates established facts, evidence references, assumptions, unknowns, attempted checks, and the exact decision now required. A vague note such as the customer seems right invites the next worker to inherit an impression, while a referenced account of the contradiction lets that worker evaluate the evidence. Context can also be complete enough for linguistic understanding but incomplete for safe operation. In a hypothetical payroll office, an employee writes cancel it after discussing a bank transfer, a benefits deduction, and a leave request in the same thread.

The system may understand every word while still lacking the operational fact that identifies what it is allowed to cancel. Guessing the most recent noun would feel efficient, but a targeted clarification such as asking which named item should be cancelled preserves the ambiguity instead of disguising it. Clarification has a trade-off because it adds delay and effort, yet that friction can be appropriate when different interpretations create materially different consequences. Authentication means checking who a person is, while authorization means checking what that verified person is permitted to view, decide, or change. Even after the employee is authenticated, the payroll workflow must still determine whether that employee is authorized to cancel the selected item.

Confirmation means establishing that a person understands or intends a proposed step, while authorized approval means that an empowered person permits that step under the applicable rules. A customer confirming that a transfer is the one they meant does not automatically constitute authorized approval to reverse it. When ambiguity, missing authority, or unresolved risk prevents safe continuation, the workflow should escalate rather than quietly choosing a convenient interpretation. A good escalation states what is known, what remains uncertain, what checks were attempted, what risk blocks continuation, and what specific decision the human must make. The human response should be stored as durable workflow state so the agent can resume from that decision instead of reconstructing the issue from memory.

Escalation criteria can combine deterministic rules, which are fixed conditions evaluated by application code, with model judgement, which interprets meaning and circumstances but can be wrong. Application code should force escalation for prohibited actions, missing authentication, applicable regulatory thresholds, and failed control checks because these are mandatory boundaries rather than conversational preferences. Claude can contribute by identifying semantic ambiguity, conflicting evidence, unusual circumstances, or signs that a customer may be distressed. A prompt can tell the model to escalate at a mandatory threshold, but prompt guidance is not enforcement because the model may misunderstand, omit, or inconsistently apply it. The stronger design places the threshold in deterministic code and lets the prompt explain how the model should describe the resulting escalation.

Tool failures need the same honesty as human uncertainty. In a hypothetical service desk, a policy lookup fails because its source cannot be reached, and the tempting shortcut is to answer that no relevant policy exists. That answer would turn missing evidence into a false finding, so the better response records that the source could not be checked and routes the case according to the risk of proceeding without it. This may delay resolution, but delay is different from manufacturing certainty. Structured output adds another important distinction between syntax and truth. JSON, which stands for JavaScript Object Notation, is a structured text format for exchanging data between software systems.

Syntax concerns whether that text follows the format's rules, while a schema specifies the fields and kinds of values the application expects. Schema validation checks the output against those requirements, but neither correct formatting nor the right fields establishes whether the claims are accurate and supported. A draft can be perfectly structured yet contain the wrong account, an invented policy conclusion, or an unauthorized recommendation. Validation should therefore check both form and applicable business constraints, and consequential claims should still be tied back to evidence. A confidence score generated by a model is a statement about its apparent certainty, not automatically a calibrated probability of being correct.

Calibration is the process of comparing reported confidence with observed accuracy on representative examples, meaning examples that reflect the kinds of cases the workflow actually encounters. Confidence bands are ranges such as lower, middle, and higher confidence that can be evaluated against real outcomes without pretending that every individual number is precise. In a hypothetical finance workflow, a reviewer sees a very high confidence score beside a payment recommendation and may be tempted to treat that number as permission to approve automatically. The better design first tests whether similar high-confidence recommendations are actually reliable on representative data, then keeps approval rules tied to impact and authority.

Low-confidence cases can be directed to human review, but reviewing only those cases misses confidently wrong patterns. Stratified sampling means deliberately reviewing examples from several defined groups, such as low, middle, and high confidence, so monitoring is not limited to visibly uncertain outputs. Sampling high-confidence results does not guarantee detection of every problem, and it consumes review capacity, but it can reveal systematic errors hidden behind confident language. Human review should follow risk as well as uncertainty, because uncertainty concerns how doubtful an output is while risk also considers the harm if that output is wrong. A low-impact spelling correction might need no special review, while a high-impact payment recommendation may require authorized approval even when the model sounds certain.

Provenance is the recorded origin of a claim, including the source document, tool observation, human decision, or reasoning step from which it came. Evidence is information directly supported by a source or observation, while inference is a conclusion drawn from evidence and must be labelled so it is not mistaken for an observed fact. For example, a message stating that a customer reported a duplicate charge is evidence of the report, while concluding that the merchant charged twice remains an inference until transaction evidence supports it. Every material claim, meaning any claim that could affect a significant decision, should be traceable through stable references to its provenance.

For changing information, the record should retain the source date and effective date, because retrieval time alone does not establish which rule governed an earlier event. The source date describes when the source was created or issued, while the effective date describes when its rule or status began to apply. In a hypothetical procurement team, a reviewer sees a policy file uploaded yesterday and is tempted to treat it as newer and therefore authoritative. The file may actually contain an older policy that was superseded, so the better design compares ownership, approval status, effective period, and applicability before choosing a version. That process cannot always resolve the conflict automatically, because authority may depend on organisational facts that are missing or disputed.

When sources genuinely disagree, the system should preserve the disagreement, explain how it affects the decision, seek an authoritative resolution, and avoid writing a smooth but unsupported consensus. The full Harbour Resolution flow begins with a user request linked to an authenticated identity and continues through an orchestrator, which is application logic that coordinates model calls, tools, state, and control checks. A tool catalogue is the controlled list of operations available to the model, including each tool's purpose and required inputs, rather than unrestricted access to every service. Read-only services permit information to be viewed without changing the underlying system, so they can reduce the consequences of a mistaken call even though they do not make retrieved information automatically correct.

The model receives the relevant request, selected evidence, tool descriptions, and tool-result history, then produces a structured draft rather than directly treating generated text as a completed action. Application validation checks required fields, identifiers, permitted values, policy conditions, and other deterministic constraints before the draft can move forward. If the action is consequential, an authorized approver reviews the evidence and recommendation, and the workflow records the decision rather than confusing a conversational yes with formal permission. An audit trail is the durable chronological record of requests, retrieved sources, tool calls, control results, model drafts, human decisions, and final actions needed to reconstruct what happened.

Within this loop, interpretation, summarisation, retrieval choices, and recommendations remain probabilistic, meaning they can vary or be mistaken, while application code can enforce defined rules by checking identity, permissions, mandatory thresholds, required JSON fields and values, and blocking execution until required controls pass. Prompts shape model behaviour, but application controls enforce boundaries; valid syntax shows structural conformity, but evidence supports truth; authentication establishes identity, but authorization establishes permission; and confirmation establishes intent, but authorized approval permits action. Reliable architecture does not promise perfect attention, complete retrieval, calibrated certainty, compliance, or correctness, but it makes missing evidence, disagreement, failure, state, authority, and the risk remaining after controls visible enough to manage.

Foundations comes together when context, tools, prompts, provenance, escalation, validation, approval, and deterministic controls operate as one coherent loop whose limitations remain explicit.