Weeks 11–12. Prerequisite: Modules 1–7 and Part 0, §§0.2, 0.3.

8.0 Module map and objectives

Modules 1–7 built a harness for a single context window. This module addresses the problem that arises when the task does not fit: tasks whose trajectories exceed the model’s effective context, require state that must survive across windows, or decompose into subtasks that would crowd each other out if run in one context.

The formal core is Module 1’s result that the context $c_t=\phi(h_t)$ is a lossy belief surrogate (Module 1, §1.5). When the task is long, the loss becomes the dominant problem: the model forgets what it learned three windows ago, repeats work, contradicts its earlier decisions, or loses the thread of a plan. The harness must supply what the model cannot: durable state, structured handoffs, and a decomposition that keeps each window’s context coherent.

The module has five parts and one lab.

By the end of the module you will be able to do eight things:

1. Diagnose whether a task will exceed the effective context, and estimate the number of windows it will require.
2. Specify a progress-file protocol and a structured handoff artefact, with the fields that make them sufficient for the next window.
3. Choose between the initialiser pattern, the worker pattern, and a single-window loop, using the task’s structure and the cost model.
4. Decide when subagent delegation beats a shared context, and compute the coordination overhead.
5. Design an AGENTS.md-style instruction file that survives progressive disclosure and resists instruction rot.
6. Represent a plan as a task graph, a checklist, or a spec, and justify the choice against the task’s dependency structure.
7. Build a skill library with a curation policy, and state the evidence status of the Voyager result.
8. Measure a handoff protocol’s completion rate, regression rate, and token cost, with confidence intervals.

Everything is self-contained. Where Part 0 or a prior module is used, the result is restated.

PART A — THE LONG-HORIZON PROBLEM

8.1 What makes a task long

8.1.1 The three lengths

A task has three lengths, and they are not the same.

Definition 8.1.1 (Task lengths).

• Nominal length $L_{\text{nom}}$: the number of tokens the full trajectory would occupy if the entire history were retained.
• Effective length $L_{\text{eff}}(\epsilon)$: the maximum context length at which the model’s performance on the task is within $\epsilon$ of its performance at a short reference (Module 3, Definition 3.2.2).
• Window length $W$: the harness’s configured context budget (the trimming threshold, or the compaction target).

A task is long if $L_{\text{nom}}>W$. A task is effectively long if $L_{\text{nom}}>L_{\text{eff}}(\epsilon)$ — which is the more common and more dangerous case, because the harness may be configuring a window that is larger than the model can usefully attend to.

8.1.2 The window count

The number of windows a task requires is approximately

where $W_{\text{useful}}=\min(W, L_{\text{eff}}(\epsilon))$ is the useful window size. The distinction matters: if the harness configures $W=128\text{k}$ but the model’s $L_{\text{eff}}=32\text{k}$, the useful window is 32k, and the task requires four times as many windows as the nominal configuration suggests.

Worked example. A repository-editing task with $L_{\text{nom}}=500\text{k}$ tokens (the full history: files read, tests run, edits made, errors observed). The harness configures $W=128\text{k}$. The model’s effective length on this task is $L_{\text{eff}}(0.05)=48\text{k}$ (measured, Module 3). Then $W_{\text{useful}}=48\text{k}$, and $n_w\approx500/48\approx11$ windows. The task is an eleven-window task, not a four-window task, and the harness must supply the state that survives eleven handoffs.

8.1.3 Why long tasks are different

The difference is not merely quantitative. Three qualitative changes occur as $n_w$ grows.

Change 1 — Compounding loss. Each window’s context is a lossy projection of the history (Module 3, Proposition 3.3.2). Over $n_w$ windows, the losses compound: information dropped in window 1 is not available in window 11, and the model cannot recover it by re-reading the context, because the context does not contain it. The formal statement: the mutual information between the belief and the context, $I(b_t;c_t)$, is non-increasing across handoffs (by the data-processing inequality, applied at each handoff), and each handoff can strictly decrease it.

Change 2 — Consistency across windows. The model’s decisions in window $k$ must be consistent with its decisions in window $k-1$, but the model in window $k$ does not remember window $k-1$ except through the handoff. If the handoff is incomplete, the model can contradict itself: it can re-do a completed edit, undo a decision, or pursue a different plan. The inconsistency is not a model error; it is a handoff error, and the harness is responsible.

Change 3 — Verification across windows. The verification loop (Module 7, §7.10) must span the handoffs. A verifier that runs only at the end of a window cannot catch a regression introduced mid-window and carried forward. The harness must either verify at each handoff (expensive) or maintain a cross-window invariant (the plan, the progress file) that the verifier can check.

8.2 The formal statement

8.2.1 The long-horizon POMDP

The long-horizon problem is a POMDP problem with a specific structure: the observation function $\phi$ is applied at each handoff, and the belief that the model receives at window $k$ is $\phi(h_{\text{start}(k)})$, where $h_{\text{start}(k)}$ is the history at the start of the window. The model’s policy in window $k$ is

and the handoff is the function $\phi$ applied at the window boundary. The long-horizon problem is: design $\phi$ at the handoffs so that the model’s belief is sufficient for the task, subject to the window budget.

Definition 8.2.1 (Handoff). A handoff is a function

where $\mathcal{H}$ is the history, $\mathcal{P}$ is the plan (or progress representation), and $\mathcal{C}$ is the context for the next window. The handoff produces the context that the next window’s model will see.

The handoff is the long-horizon analogue of the context manager (Module 3, Definition 3.3.1): the context manager trims within a window; the handoff compresses across windows. The information loss is governed by the same bound (the data-processing inequality), and the design problem is the same: maximise $I(b_t;c_t)$ subject to the token budget.

8.2.2 The sufficiency condition

The handoff is sufficient if it preserves the information the next window needs. Formally:

Definition 8.2.2 (Handoff sufficiency). A handoff $\mathcal{H}$ is sufficient for a task distribution if, for every history $h$ and plan $p$, the belief $b$ recoverable from $\mathcal{H}(h,p)$ satisfies $D_{\mathrm{KL}}(b|\hat b)\le\epsilon$ for the tolerance $\epsilon$, where $\hat b$ is the belief recoverable from the full history and plan.

The condition is the long-horizon form of the compaction loss bound (Module 3, Corollary 3.3.3): the handoff’s loss is the divergence between the belief it preserves and the true belief, and the tolerance is the task’s tolerance for belief error.

8.2.3 The three failure modes

The handoff fails in three ways, and the failure modes correspond to the information it drops.

Failure mode 1 — Omission. The handoff does not include a fact the next window needs. The model in the next window acts on incomplete information, and the failure is invisible until the task fails. Example: the handoff includes the edits made but not the reason for them, so the next window’s model cannot judge whether an edit is still appropriate after an error.

Failure mode 2 — Corruption. The handoff includes the fact but distorts it. The model in the next window acts on wrong information. Example: the handoff summarises “the test failed with error X” as “the test failed,” losing the error’s identity, so the next window’s model cannot target the fix.

Failure mode 3 — Inconsistency. The handoff includes conflicting information: the plan says one thing, the progress file says another, the workspace state is a third. The model in the next window cannot determine which is authoritative. Example: the plan says “step 3: add the new function,” the progress file says “step 3: completed,” and the workspace does not contain the function (because the edit was rolled back, Module 7, §7.20). The model does not know whether to add the function or move to step 4.

The three modes are the long-horizon analogues of Module 3’s dropped and corrupted facts (§3.3.3), plus the inconsistency mode, which is specific to handoffs: within a window, the context is a single coherent artefact; across windows, the handoff must reconcile the plan, the progress, and the state, and the reconciliation can fail.

8.3 The cost of handoffs

8.3.1 The token cost

Each handoff costs tokens: the handoff artefact is written (into the next window’s context) and read (by the model). The artefact’s length is a design variable: a longer artefact is more complete but consumes more of the window’s budget.

Proposition 8.3.1 (Handoff budget trade-off). For a handoff artefact of length $\ell_h$ and a window of size $W$, the useful window is $W-\ell_h$. The handoff is worth its cost iff the information it preserves (the reduction in belief error) saves more than the work the reduced window can no longer do.

Argument. The artefact consumes $\ell_h$ of the window, leaving $W-\ell_h$ for the task. A longer artefact reduces the belief error (less omission, less corruption) but reduces the work capacity. The optimum is where the marginal reduction in belief error equals the marginal loss in work capacity. This is the same trade-off as Module 3’s compaction, with the artefact as the compaction policy. $\square$

8.3.2 The latency cost

Each handoff is a boundary: the window ends, the artefact is written, the next window begins. The latency of the handoff is the time to write and read the artefact, which is small if the artefact is a file and the model reads it in the next window’s context. The more significant latency is the restart cost: the next window’s model must re-orient (read the artefact, understand the state) before doing useful work. The re-orientation is a per-window overhead, and over $n_w$ windows it compounds.

8.3.3 The coordination cost

The handoff is a coordination point: the previous window’s model must produce an artefact that the next window’s model can use. If the model produces a poor artefact (incomplete, corrupted, inconsistent), the next window pays for it. The coordination cost is the quality of the artefact, which depends on the model’s ability to summarise its own work — a capability that varies across models (Module 14’s co-adaptation problem, previewed).

8.4 Concept check

Why is a 500k-token task with a 128k window not a four-window task?

Answer. Because the useful window is the minimum of the configured window and the model’s effective length. If the model’s effective length on the task is 48k, the useful window is 48k, and the task requires about eleven windows. The configured window is a ceiling, not a budget (Module 3, §3.2.4); the effective length is the budget, and it is measured, not assumed. A harness that plans for four windows will be unprepared for the eleven handoffs the task actually requires.

PART B — MULTI-CONTEXT-WINDOW EXECUTION

8.5 Progress files

8.5.1 The mechanism

A progress file is an external artefact — a file in the workspace or a store — that records the run’s state across windows. It is read at the start of each window and updated at the end. It is the simplest handoff mechanism: a structured record that the next window’s model reads.

8.5.2 The fields

The progress file’s fields are a design decision, and the decision determines the handoff’s sufficiency (Definition 8.2.2). A minimal field set:

• Task. The original instruction (unchanged across windows; a reference to the prompt).
• Plan. The current plan, as a sequence of steps with statuses (see §8.21).
• Completed steps. Which steps are done, with a one-line outcome each.
• Current step. Which step the run is on, and its sub-state.
• Discovered facts. What the run has learned about the environment (the file that contains the bug, the test that fails, the error message). These are the facts the next window needs and the workspace does not encode.
• Open questions. What the run has not resolved (the ambiguity it is stuck on).
• Decisions made. The choices the run has committed to (the plan’s rationale, the design decisions, the rejected alternatives), so the next window does not re-litigate them.
• Risks and constraints. What the next window must not do (the file it must not touch, the test it must not change, the constraint it must respect).
• References. Where the detailed content lives (the file paths, the line numbers, the traces), so the next window can retrieve it on demand (just-in-time, Module 3, §3.8).

The field set is the sufficiency condition in operational form: the file is sufficient if a model reading it, and nothing else, can continue the task correctly. The design test is to hand the file to a fresh model (a different instance, a different session) and see whether it can continue. If it cannot, a field is missing.

8.5.3 The update discipline

The progress file is only as good as its update. Two disciplines:

Update at every step, not just at the boundary. A progress file updated only at the handoff loses the intermediate state; a file updated at every step (or every few steps) records the trajectory, not just its endpoints. The update is a tool call (update_progress(field, value)) that the model makes, or a harness-side update that parses the model’s output.

Update is a verification point. The progress file’s update is a natural point for a verifier: does the file’s “completed” claim match the workspace’s state? Does the “current step” match the plan? The verification at the update catches the inconsistency mode (Failure mode 3) before it propagates.

8.5.4 The failure modes, revisited

The progress file can fail in all three modes.

Omission. A field is missing (no “decisions made” field), so the next window re-litigates a decision. Diagnosis: the next window’s model asks a question the file should have answered. Fix: add the field.

Corruption. A field is wrong (the “completed” status is stale, the “discovered facts” contain an error). Diagnosis: the next window’s model contradicts the file (it finds the step is not done). Fix: the update discipline (verify at the update) and the corruption check (the file’s claims against the workspace).

Inconsistency. Two fields conflict (the plan says step 3 is next, the completed list says step 3 is done). Diagnosis: the model cannot determine which is authoritative. Fix: a canonical order (the plan is authoritative, the completed list is derived from it) and a consistency check at the update.

8.6 Structured handoff artefacts

8.6.1 Beyond the progress file

The progress file is a flat record. A structured handoff artefact is a richer object: it includes not just the state but the reasoning that produced it, in a form the next window can use.

The distinction is the one Module 3 drew between summarisation and structured extraction (Module 3, §3.4): the progress file is a structured extraction of the state; the handoff artefact is a structured extraction of the state and the rationale. The rationale is what makes the artefact sufficient for the decisions the next window must make.

8.6.2 The additional fields

The structured artefact adds:

• Rationale. For each decision, why it was made, so the next window can judge whether it is still valid.
• Alternatives considered. The options the run rejected, so the next window does not re-explore them.
• Evidence. The trace references for the facts (which file, which line, which test run), so the next window can verify them.
• Confidence. The run’s confidence in each fact and decision, so the next window knows what to re-check.
• Open threads. The questions the run has not resolved, with the context that would resolve them.

The additional fields make the artefact longer (the handoff budget trade-off, Proposition 8.3.1), but they make it sufficient for the next window’s decisions, not just its state. The trade-off is real: a longer artefact preserves more but consumes more of the window.

8.6.3 The format

The artefact’s format is a design decision. Three options:

Free text. A narrative written by the model. Advantage: flexible, can capture nuance. Disadvantage: hard to parse, inconsistent across windows, easy to omit fields.

Structured schema. A JSON or YAML object with fixed fields. Advantage: parseable, consistent, the schema enforces the fields. Disadvantage: constrains the model, and the schema must be designed (a wrong schema omits a field, Module 3, §3.4.3).

Hybrid. A structured skeleton with free-text fields. Advantage: the skeleton enforces the critical fields; the free text captures the nuance. Disadvantage: the model must fill both, and the free text can still be omitted.

The hybrid is the common production choice, and it is the one the curriculum recommends: the skeleton is the sufficiency condition, and the free text is the richness.

8.7 The initialiser pattern

8.7.1 The pattern

The initialiser pattern uses two kinds of agent: an initialiser that runs once at the start, and a worker that runs repeatedly. The initialiser’s job is to set up the environment and the plan; the worker’s job is to execute the next step.

The pattern’s structure:

1. Initialiser. Reads the task, explores the environment, writes the plan and the progress file, sets up the workspace. Runs once.
2. Worker. Reads the plan and the progress file, executes the next step, updates the progress file, terminates. Runs repeatedly.

The pattern is the long-horizon analogue of the “plan then execute” decomposition, and it is a harness configuration, not a model capability.

8.7.2 Why it helps

The initialiser pattern helps because it separates the expensive exploration from the cheap execution. The initialiser’s context is large (it explores the environment); the worker’s context is small (it reads the plan and does one step). The separation means the worker’s context is not crowded by the initialiser’s exploration, which is the Module 3 distractor problem (§3.1.3) solved by decomposition.

Proposition 8.7.1 (The initialiser pattern reduces worker context). If the initialiser’s exploration occupies $E$ tokens and the worker’s step requires $S$ tokens, the single-agent run’s context is $E+S$ (plus the accumulated history), while the worker’s context is $S$ (plus the progress file). The reduction is $E$, which is the exploration’s cost, and the reduction is available at every worker step.

Argument. In the single-agent run, the exploration’s tokens are in the context at every step (unless compacted, Module 3). In the initialiser pattern, the exploration’s tokens are in the initialiser’s context only, and the worker sees the artefact (the plan and the progress file), which is shorter than the exploration. The reduction is the difference between the exploration’s length and the artefact’s length. $\square$

8.7.3 The costs

The pattern’s costs are the ones Module 2, §2.4.5 named for protocols: the initialiser is an extra component (a separate agent, a separate prompt, a separate handoff), and the handoff artefact is a coordination cost. The pattern is worth it when the exploration is expensive relative to the execution, which is the case for tasks that require understanding a large codebase before editing it.

8.7.4 The failure modes

The initialiser over-explores. It spends its entire budget exploring and produces no plan. Fix: a time or token budget on the initialiser, and a requirement that it produce a plan.

The worker under-reads. It skips the progress file and re-explores. Fix: the worker’s prompt must require reading the file, and the progress file’s content must be in the context (not just available).

The handoff is insufficient. The plan is not detailed enough for the worker, or the progress file omits a field. Fix: the sufficiency test (§8.5.2) — hand the artefact to a fresh worker and see whether it can continue.

8.8 The worker pattern (single-agent, multi-window)

8.8.1 The pattern

The worker pattern uses a single agent that runs across windows, with the harness managing the handoffs. The agent’s prompt is the same in each window; the progress file is the state that carries across.

The pattern’s structure:

1. Window $k$. The agent reads the progress file (and the task), executes steps until the window is full or a step boundary is reached, updates the progress file, terminates.
2. Handoff. The harness writes the progress file (or confirms its update) and starts window $k+1$.
3. Window $k+1$. The agent reads the progress file, continues.

The worker pattern is simpler than the initialiser pattern (one agent, one prompt) and is the right choice when the exploration is not separable from the execution — when the agent discovers what to do as it does it.

8.8.2 The choice between the patterns

The choice is the same as Module 1’s workflow-vs-agent decision (§1.7), applied to the long-horizon structure.

Use the initialiser pattern when:

• The exploration is expensive and can be completed before execution.
• The plan is stable (it does not change as the execution proceeds).
• The worker’s task is well-defined given the plan.

Use the worker pattern when:

• The exploration is interleaved with the execution (the agent discovers as it does).
• The plan changes as the execution proceeds.
• The task is exploratory (the next step depends on what the previous step found).

Use a single window when:

• The task fits in one window (the trivial case).
• The handoff cost exceeds the benefit.

The decision procedure is the Module 1 tree, applied at the long-horizon level.

8.9 The handoff protocol as a component

8.9.1 The classification

The handoff protocol is a mixed component in the Module 6 classification:

• The handoff mechanism (writing and reading the progress file) is irreducible: a long task requires state to survive the window boundary, regardless of the model’s capability. A perfect model with a finite context still needs the state externalised.
• The handoff’s content (the fields, the summarisation) is compensating: it exists because the model cannot hold the full history in its context, and a model with an unbounded effective context would not need it.

The distinction is the Module 6, §6.13.3 mixed-component case: the mechanism is permanent, the content is temporary. The implication: invest in the mechanism (a robust progress-file store, a reliable handoff), and watch the content for removal as effective contexts grow.

8.9.2 The handoff as a verifier

The handoff is a natural verification point. The harness can check:

• Consistency. The progress file’s “completed” claims match the workspace’s state.
• Sufficiency. The progress file contains the required fields (a schema check).
• Progress. The handoff’s state differs from the previous handoff’s (the run is not stuck).

The checks are the long-horizon analogue of Module 7’s verifiers, applied at the window boundary. A handoff that fails the checks is a handoff that will produce an inconsistent next window, and the failure should be caught before the next window starts.

8.10 Concept check

Why is the handoff protocol a mixed component, and what does that imply for its maintenance?

Answer. Because the mechanism (the state externalisation) is irreducible — a perfect model with a finite context still needs it — while the content (the summarisation, the fields) is compensating — a model with an unbounded effective context would not need it. The implication is that the mechanism should be invested in (a robust store, reliable handoffs, consistency checks) and the content should be watched for removal as effective contexts grow. The two halves have different maintenance obligations, and conflating them leads to either under-investing in the mechanism or over-investing in the content.

PART C — SUBAGENT DELEGATION

8.11 The delegation decision

8.11.1 What delegation is

Delegation is the pattern where the main agent (the orchestrator) spawns a subagent to perform a subtask, receives the subagent’s result, and continues. The subagent has its own context, its own tools, and its own loop; it is a separate agent, not a tool call.

The pattern is the multi-agent case of Module 18, but at a smaller scale: the subagent is a helper, not a peer, and the coordination is a simple parent-child relationship.

8.11.2 The decision criterion

Delegation is worth it when the subagent’s context isolation saves more than its coordination cost. Formally:

Proposition 8.11.1 (Delegation criterion). Delegate a subtask to a subagent iff

where $\Delta_{\text{isolation}}$ is the improvement from keeping the subtask’s context separate from the orchestrator’s, and $C_{\text{coord}}$ is the coordination cost (the spawning, the handoff, the result integration).

The isolation benefit has three sources:

• Context size. The subtask’s exploration would crowd the orchestrator’s context (Module 3’s distractor sensitivity), and isolating it keeps the orchestrator’s context clean.
• Context privacy. The subtask’s context contains information the orchestrator should not see (a large search result, a verbose log), and isolating it keeps the information out of the orchestrator’s window.
• Parallelism. Multiple subagents can run concurrently, reducing latency (if the subtasks are independent).

The coordination cost has three sources:

• Spawning. The subagent’s setup (a model call, a prompt, a context initialisation).
• Handoff. The subtask specification (what the subagent must do) and the result (what the subagent returns), both of which must be written and read.
• Integration. The orchestrator must incorporate the result into its own state, which may require summarisation or verification.

8.11.3 The cost model

A more precise model, using the token-cost framework of Part 0, §0.9:

where $C_{\text{subagent}}$ is the subagent’s own cost. The alternative (no delegation) costs $C_{\text{inline}}$, the cost of doing the subtask in the orchestrator’s context. Delegation is worth it iff

where $V$ is the value of the isolation benefit (the improvement in the orchestrator’s performance from the cleaner context). The inequality is the operational form of Proposition 8.11.1.

Worked example. A search subtask returns 50k tokens of results, of which 2k are relevant. Inline, the orchestrator’s context absorbs 50k tokens (the distractor cost, Module 3, §3.1.3), and the orchestrator’s performance degrades. Delegated, the subagent absorbs the 50k, returns a 2k summary, and the orchestrator sees only the 2k. The isolation benefit is the avoided degradation; the coordination cost is the spawn, the spec, the result, and the integration, which is small (a few thousand tokens). Delegation is worth it if the degradation from the 50k inline is larger than the coordination cost — which, for a model with a 128k effective context and a 50k distraction, it usually is.

8.12 When delegation beats shared context

8.12.1 The three cases

Delegation beats shared context in three cases, corresponding to the three isolation sources.

Case 1 — The subtask’s context would crowd the orchestrator. The subtask requires reading many files, running many tests, or processing a large result. The orchestrator needs the conclusion, not the exploration. Example: “find the function that raises this error” — the subagent searches, the orchestrator gets the function’s location.

Case 2 — The subtask’s context contains information the orchestrator should not see. The subtask handles sensitive data (credentials, personal information, a large log with secrets). The orchestrator should not have the data in its context, for security (Module 19) or for focus. Example: “check whether this API key is valid” — the subagent sees the key, the orchestrator sees only “valid” or “invalid.”

Case 3 — The subtasks are independent and parallelisable. The task decomposes into subtasks that do not depend on each other, and running them concurrently reduces latency. Example: “research these five companies” — five subagents run concurrently, the orchestrator integrates.

8.12.2 When shared context beats delegation

Shared context beats delegation when the coordination cost exceeds the isolation benefit. The common cases:

Case 1 — The subtask is small. The subtask’s context is a few tokens (a single tool call), and the coordination cost (a spawn, a spec, a result) exceeds the saving. Example: “read this file” — a tool call is cheaper than a subagent.

Case 2 — The subtask depends on the orchestrator’s context. The subtask needs the orchestrator’s accumulated state (the plan, the decisions, the discovered facts), and isolating it would require transferring the state, which costs more than sharing it. Example: “make the edit the plan calls for” — the edit depends on the plan and the decisions, which are in the orchestrator’s context.

Case 3 — The subtask’s result needs the orchestrator’s judgement. The result is ambiguous, and integrating it requires the orchestrator’s context to interpret. Example: “summarise this error” — the summary is only useful in the orchestrator’s context, and a subagent without that context would summarise the wrong thing.

8.12.3 The decision procedure

The procedure is a sequence of questions, biased toward the simpler option (consistent with the curriculum’s philosophy).

1. Is the subtask small (a few tool calls)? Yes → inline (shared context). No → 2.
2. Does the subtask depend on the orchestrator’s accumulated state? Yes → inline, unless the state can be transferred cheaply (then consider delegation). No → 3.
3. Would the subtask’s context crowd or contaminate the orchestrator’s? Yes → delegate. No → 4.
4. Are the subtasks independent and parallelisable, with a latency requirement? Yes → delegate (parallel). No → inline (or consider the initialiser pattern, §8.7).

The procedure’s bias is the same as Module 1’s: the simpler option (inline) is the default, and the burden of proof is on the more complex option (delegation). The bias is correct because delegation adds a component (the subagent), a protocol (the handoff), and a coordination cost, all of which must be justified.

8.13 The coordination costs in detail

8.13.1 The four costs

Spawning cost. The subagent’s setup: a model call to initialise it (or a fresh context), a prompt, a tool set. The cost is small per spawn but adds up over many subagents.

Specification cost. The orchestrator must describe the subtask to the subagent: what to do, what constraints, what output format. The specification is a token cost, and a vague specification produces a wrong result (the subagent does the wrong thing), which costs more.

Result cost. The subagent must return a result the orchestrator can use: a summary, a conclusion, a structured object. The result is a token cost, and a poorly formatted result is hard to integrate.

Integration cost. The orchestrator must incorporate the result into its state: update the plan, record the fact, decide the next step. The integration is a reasoning cost, and a result that does not fit the orchestrator’s schema costs more to integrate.

8.13.2 The coordination failure modes

The four costs correspond to four failure modes.

Spawn failure. The subagent does not start (a model error, a tool error). Detection: the subagent’s result is missing; the orchestrator must handle the absence.

Specification failure. The subagent misunderstands the subtask and does the wrong thing. Detection: the result does not match the specification (the orchestrator checks); the fix is a clearer specification or a re-delegation.

Result failure. The subagent returns a result that is wrong or unusable. Detection: the orchestrator verifies the result (a verifier on the result, Module 7); the fix is a re-delegation or an inline fallback.

Integration failure. The orchestrator cannot use the result (it does not fit the schema, or it contradicts the orchestrator’s state). Detection: the integration’s failure (the orchestrator stalls or contradicts itself); the fix is a result schema and a consistency check.

The four failure modes are the long-horizon analogue of Module 7’s verification-loop failures: the handoffs are verification points, and the failures are caught at the handoffs if the harness checks them.

8.14 The subagent as a component

8.14.1 The classification

The subagent is a mixed component:

• The delegation mechanism (spawning, handoff, result integration) is irreducible: a task that exceeds one context needs some decomposition, and the subagent is the mechanism for the isolation cases. A perfect model with a finite context still needs the mechanism.
• The subagent’s specific prompts and tools are compensating: they are tuned to the current model’s capabilities, and a stronger model might need less scaffolding.
• The parallelisation is tuning: it improves latency, and the deployment is acceptable (slower) without it.

The classification is the Module 6, §6.13.3 mixed case again, and the maintenance implication is the same: invest in the mechanism, watch the scaffolding, tune the parallelisation.

8.14.2 The subagent and the multi-agent question

The subagent is the small-scale case of the multi-agent system (Module 18). The Module 18 question — does a single well-harnessed agent beat the multi-agent design? — applies here in miniature: does a single well-harnessed agent with a good context manager beat the orchestrator-subagent design? The answer is the same: it depends on whether the isolation benefit exceeds the coordination cost (Proposition 8.11.1), and the default is the simpler design (single agent) until the evidence shows otherwise.

The subagent pattern is a special case of the multi-agent pattern, and it inherits the multi-agent literature’s caution: the coordination costs are real, the failure modes are many, and the benefit is task-specific. The subagent is worth it when the three isolation cases (§8.12.1) apply, and not otherwise.

8.15 Concept check

A subtask requires reading 50 files and extracting one fact. Should it be delegated or inline?

Answer. Delegated, if the 50 files would crowd the orchestrator’s context. The isolation benefit is the avoided distractor cost (Module 3, §3.1.3): the orchestrator does not need the 50 files, only the fact. The coordination cost is the subagent’s spawn, the specification (“read these 50 files and tell me the fact”), the result (the fact), and the integration (record the fact). The coordination cost is small relative to the isolation benefit, because the 50 files are large and the fact is small. The delegation is the right choice — unless the subtask depends on the orchestrator’s state (the fact must be interpreted in the orchestrator’s context), in which case the integration cost may exceed the isolation benefit.

PART D — REPOSITORY-LEVEL KNOWLEDGE

8.16 Instruction files

8.16.1 What they are

An instruction file is a document in the repository (typically AGENTS.md, CLAUDE.md, or a similar name) that tells the agent how to work in the repository: the conventions, the commands, the constraints, the structure. It is read at the start of each window and is part of the context.

The file is the repository-level analogue of the Module 2 skills file (§2.4.4): a document that describes a procedure or a context, read by the agent on demand or at the start.

8.16.2 The content

A good instruction file has five sections, each answering a question the agent would otherwise have to discover.

What the repository is. A one-paragraph description: what the project does, what the main modules are, what the entry points are.

How to build and test. The commands: the build command, the test command, the lint command, the format command. The agent should not have to guess these.

The conventions. The code style, the commit message format, the branch naming, the review process. The agent should follow the conventions without being told each time.

The constraints. What the agent must not do: the files it must not touch, the commands it must not run, the dependencies it must not add. These are the guide/sensor split (Module 9, §9.2) applied to repository knowledge: the constraints are guides (they prevent the error), and they are supplemented by the policy engine’s sensors (Module 7, §7.14).

The structure. Where the important things are: the test directory, the configuration files, the documentation. The agent should be able to find things.

8.16.3 The sufficiency condition

The instruction file is sufficient if a fresh agent, reading it and the task, can start work without exploring. The test is the same as the progress file’s (§8.5.2): hand the file to a fresh agent and see whether it can begin. If it cannot, a section is missing.

8.17 Progressive disclosure

8.17.1 The mechanism

Progressive disclosure is the principle that the agent sees a summary of the instruction file first, and the full content only when it decides the file is relevant. The summary is a sentence or two (the file’s description); the full content is loaded on demand.

The mechanism is the Module 2, §2.4.4 progressive disclosure applied to repository knowledge: the context carries an index, not the full content. The index is cheap (a few tokens per file), and the full content is loaded only for the files the agent needs.

8.17.2 The benefit

The benefit is the context budget: a repository with a hundred instruction files would consume the entire context if all were loaded; with progressive disclosure, only the relevant ones are loaded. The benefit is the Module 3, §3.8 just-in-time loading applied to instruction files.

8.17.3 The cost

The cost is the retrieval decision: the agent must decide which files are relevant, and the decision can be wrong (it loads the wrong file, or it does not load a file it needs). The decision is the same as Module 3’s retrieval decision (§3.8), and the same criterion applies: JIT is worth it when the relevant file depends on what the agent discovers, and the file is large.

8.18 Instruction rot

8.18.1 The problem

Instruction rot is the accumulation of stale, contradictory, or irrelevant instructions in the instruction file. The file grows over time as engineers add instructions, and it is rarely pruned. The result is a file that is long (consuming context), stale (containing instructions that no longer apply), and contradictory (containing instructions that conflict).

The rot is the Module 3, §3.7.3 evolving-playbook curation problem, applied to the instruction file. The file is a form of memory, and memory that is not curated becomes a liability.

8.18.2 The symptoms

Four symptoms, each a diagnostic.

Length. The file is longer than a fresh agent can read in one window. Diagnosis: the file has accumulated too much; it needs pruning.

Staleness. The file contains instructions that no longer apply (a deprecated command, an obsolete convention). Diagnosis: the file has not been updated with the repository; it needs a review.

Contradiction. The file contains instructions that conflict (one section says “use tabs,” another says “use spaces”). Diagnosis: the file has accumulated instructions from different eras; it needs reconciliation.

Irrelevance. The file contains instructions the agent does not need (a history of the project, a long explanation of a design decision). Diagnosis: the file has become a general document; it needs a separation of the instructions from the documentation.

8.18.3 The curation

The curation is a periodic review: the file is reviewed, the stale instructions are removed, the contradictory ones are reconciled, the irrelevant ones are moved to documentation. The review is the same as the Module 3 playbook curation, and it has the same difficulty: detecting which instructions are helping requires measuring their effect, which requires controlled comparison.

A practical curation policy:

• Review quarterly. The file is reviewed at a fixed cadence, not when someone notices a problem.
• Measure the effect. The file’s instructions are tested: an instruction is kept if the agent’s behaviour with it is better than without it (a Module 5 comparison). An instruction that does not improve behaviour is removed.
• Separate instructions from documentation. The file contains only what the agent needs to act; the rest is in the repository’s documentation, which the agent reads on demand (progressive disclosure).
• Record the decisions. The file’s history (the git log) is the record; the review is a commit with a rationale.

8.19 Repository-level knowledge as a component

8.19.1 The classification

The instruction file is a compensating component: it exists because the agent cannot discover the repository’s conventions and constraints from the code alone, and a model with better code understanding (or a better retrieval mechanism) would need less of it. The file is the scaffolding that the model needs now.

The progressive disclosure mechanism is tuning: it improves the context efficiency, and the deployment is acceptable (with a larger context) without it.

The curation is irreducible: the file’s maintenance is required regardless of the model, because the file’s content is a property of the repository, not the model — the conventions and constraints are real, and they must be recorded somewhere. (A perfect model might infer them, but the record is still required for audit and for humans.)

8.19.2 The measurement

The instruction file’s effect is measurable: compare the agent’s behaviour with and without the file, on the same task set, with the Module 5 discipline. The measurement is the file’s removal test (Module 6, §6.14.3), and it is the input to the curation policy.

Worked example. A repository has an AGENTS.md of 4,000 tokens. The measurement: run the agent on 50 tasks with the file and 50 without (paired, same tasks), and compare success and token cost. If the file improves success by 8 points and costs 4,000 tokens per run, the file is worth it (the success gain exceeds the cost). If it improves success by 1 point, the file is a candidate for pruning. The measurement is the file’s justification, and the pruning is the removal of the parts that do not contribute.

8.20 Concept check

Why is instruction rot a curation problem rather than a writing problem?

Answer. Because the rot accumulates over time, as the repository changes and the file is not updated. A well-written file rots if it is not maintained; a poorly written file that is maintained can stay useful. The problem is not the initial writing (which is a one-time cost) but the ongoing review (which is a recurring cost), and the review is the hard part because it requires measuring which instructions are helping — a controlled comparison that is expensive and rarely done. The curation policy (§8.18.3) is the mechanism that makes the review routine, and the measurement is what distinguishes a curated file from a rotted one.

PART E — PLANNING REPRESENTATIONS AND SKILLS

8.21 Planning representations

8.21.1 The three representations

A planning representation is the structure in which the agent’s plan is held. Three are common.

Task graph. A directed acyclic graph (DAG) where nodes are tasks and edges are dependencies. The plan is the graph; execution is a topological traversal. Strength: expresses dependencies precisely, supports parallelism (independent branches run concurrently), supports re-planning (a failed node’s dependents are re-planned). Weakness: the graph must be constructed (a design cost), and a wrong graph (a missing dependency) produces a wrong plan.

Checklist. A linear list of items, each with a status (todo, in progress, done). The plan is the list; execution is sequential. Strength: simple, robust (the order is the list’s order, so the agent always knows the next step), supports the progress file directly (the checklist is the progress file’s plan field). Weakness: no dependencies, no parallelism; the order is fixed even when it should not be.

Spec. A document that specifies the desired outcome, the constraints, and the acceptance criteria, without prescribing the steps. The plan is the spec; execution is the agent’s choice of steps. Strength: maximally flexible (the agent chooses the steps), supports the verifier (the acceptance criteria are the verifier’s specification). Weakness: the agent must derive the steps, which is a reasoning burden; the spec can be ambiguous.

8.21.2 The choice

The choice is a function of the task’s dependency structure and the verifier’s strength.

Use a task graph when:

• The task has genuine dependencies (step B requires step A’s output).
• The dependencies are known at planning time (the graph is constructible).
• The task benefits from parallelism (independent branches).

Use a checklist when:

• The task is sequential (the steps are ordered).
• The dependencies are implicit in the order (step 2 assumes step 1).
• The plan is simple enough that a graph is overkill.

Use a spec when:

• The task’s steps are not known at planning time (the agent must discover them).
• The task has a strong verifier (the acceptance criteria are the spec’s check).
• The task benefits from the agent’s judgement (the spec constrains the outcome, not the steps).

The three representations are not mutually exclusive: a plan can have a spec (the outcome), a checklist (the steps), and a graph (the dependencies), with each serving a different purpose. The hybrid is common: the spec is the task’s definition, the graph is the plan, the checklist is the progress file.

8.21.3 The representation and the verification

The representation determines the verifier’s structure. A task graph’s verifier is per-node (each node’s output is checked); a checklist’s verifier is per-item; a spec’s verifier is at the end (the acceptance criteria). The representation should be chosen with the verifier in mind: a representation whose verification points are natural is easier to verify.

8.22 Spec-driven development

8.22.1 The pattern

Spec-driven development writes the spec first, then the implementation. The spec is the artefact: it states the desired behaviour, the interface, the constraints, and the acceptance criteria. The implementation is generated to satisfy the spec, and the spec is the verifier’s reference.

The pattern is the Module 4, §4.4 self-correction applied to the task level: the spec is the external signal (the verifier), and the implementation is the output that the spec checks.

8.22.2 The benefit

The benefit is the verifier’s strength: a spec with explicit acceptance criteria is a strong verifier (Module 7, §7.8), and a strong verifier supports autonomy (Part 0, §0.5). The spec is the way to make a task verifiable when the task’s output is not directly checkable.

8.22.3 The cost

The cost is the spec’s construction: writing a spec is a design activity, and a bad spec is worse than no spec (it constrains the implementation wrongly). The spec’s quality is the bottleneck, and it is a human activity (or a model activity with human review).

8.22.4 The connection to the curriculum

Spec-driven development is the planning representation that the curriculum’s mastery criteria favour: “every autonomy increase is paired with a named verifier” (mastery criterion 2) is, in practice, a spec. The spec is the verifier’s specification, and the development is the implementation’s generation.

8.23 Skills as procedural memory

8.23.1 The Voyager result

Voyager (Wang et al., arXiv:2305.16291, evidence tier R: independently reproduced) is a Minecraft agent that builds a skill library: a growing collection of executable code snippets (skills) that the agent can reuse. The agent discovers a skill (a sequence of actions that achieves a subgoal), writes it as code, stores it in the library, and retrieves it when a similar subgoal arises.

The result: the skill library improves the agent’s performance over time, because the agent does not re-discover the same skill; it retrieves and reuses it. The library is a form of procedural memory: memory of how to do things, as distinct from memory of facts.

8.23.2 The mechanism

The skill library has three parts.

Discovery. The agent explores, and when it achieves a subgoal, it records the sequence of actions that achieved it. The discovery is the expensive part (it requires exploration).

Abstraction. The recorded sequence is generalised into a reusable skill: the specific values are replaced with parameters, and the preconditions are stated. The abstraction is the model’s job, and its quality determines the skill’s reusability.

Retrieval. When a similar subgoal arises, the agent retrieves the skill (by description similarity) and executes it. The retrieval is the cheap part (it avoids re-discovery).

8.23.3 The connection to the harness

The skill library is a harness component: the harness provides the store (the library), the retrieval mechanism (the similarity search), and the execution environment (the skills run as code). The model provides the discovery and the abstraction.

The library is the procedural analogue of the instruction file (Module 8, §8.16): the instruction file is declarative memory (facts and conventions), the skill library is procedural memory (how to do things). Both are curated (the rot problem, §8.18), and both are compensating components (they exist because the model cannot re-derive the knowledge each time).

8.23.4 The curation problem

The skill library has the same curation problem as the instruction file: the skills accumulate, and stale or contradictory skills become a liability. The Voyager result is on a task where the skills are stable (Minecraft’s mechanics do not change), and the curation is less of a problem; on a task where the environment changes (a codebase, a service), the skills rot.

The curation policy for a skill library:

• Test the skills. A skill is kept if it still works (a test on the skill’s effect) and if it is used (a usage count). A skill that does not work or is not used is removed.
• Version the skills. A skill is versioned with the environment it was discovered in; a skill from an old environment is re-tested before use.
• Review the abstractions. A skill’s abstraction may be wrong (it generalises a specific case wrongly); the review checks the abstraction against the current environment.

8.24 The skill library as a component

8.24.1 The classification

The skill library is a compensating component: it exists because the model cannot re-derive the skills each time (the discovery is expensive), and a model with better in-context learning (or a larger context) would need less of it. The library’s specific skills are compensating; the library’s mechanism (the store, the retrieval) is tuning (it improves efficiency, and the deployment is acceptable without it, just slower).

The classification is the same pattern as the instruction file (§8.19.1): the content is compensating, the mechanism is tuning, and the curation is irreducible (the record must be maintained).

8.24.2 The evidence status

The Voyager result is R (independently reproduced), which is strong evidence for the skill-library mechanism on Minecraft-like tasks. The transfer to other domains (coding, research, customer service) is a hypothesis, not established: the result’s domain is one where skills are stable, and the transfer’s success depends on the domain’s stability (the curation problem, §8.23.4).

The curriculum’s posture: the Voyager result is a strong prior for the skill-library mechanism, and the transfer is a hypothesis to be tested on the learner’s task. The lab’s structured extraction (Module 3) is a simpler version of the same idea, and the learner’s measurement is the test.

8.25 Concept check

Why is the skill library a compensating component while its curation is irreducible?

Answer. The library’s content (the skills) is compensating because it exists to avoid re-discovery, and a model with better in-context learning would need less of it — the skills are a workaround for the model’s inability to re-derive them cheaply. The curation is irreducible because the record of what works must be maintained regardless of the model: the environment changes, the skills rot, and someone (the harness, the human) must review and update the record. A perfect model might re-derive the skills, but the record — for audit, for humans, for reproducibility — is still required. The distinction is the Module 6 counterfactual test: the content passes the “perfect model wouldn’t need it” test (compensating); the curation fails it (irreducible, because the record is a deployment requirement).

LAB 8 — LONG-HORIZON HANDOFF PROTOCOLS

8.26.1 Task specification

Choose a task that requires more than five context windows to complete. The task must:

1. Have a deterministic verifier (a test suite, a schema check, a golden output).
2. Have a long trajectory (the full history exceeds five times the useful window).
3. Have enough instances for comparison (at least 20, ideally 30).

The canonical choice is a repository-editing task that requires reading many files, running many tests, and making many edits. If the task is shorter, choose a larger repository or a more complex task.

8.26.2 The three handoff protocols

Protocol A — Progress file only. A structured progress file (§8.5) with the minimal fields: task, plan (checklist), completed steps, current step, discovered facts. The agent reads it at the start of each window and updates it at the end.

Protocol B — Progress file plus structured artefact. The progress file plus the additional fields of §8.6: rationale, alternatives considered, evidence references, confidence, open threads. The artefact is the progress file with the reasoning.

Protocol C — Initialiser plus worker. An initialiser that explores and writes the plan and the artefact, and a worker that reads the artefact and executes one step per window. The initialiser runs once; the worker runs per window.

8.26.3 The metrics

8.26.4 The hypotheses

State before running:

• H1. Protocol B has the highest completion rate, because its artefact preserves the reasoning the next window needs.
• H2. Protocol A has the lowest token cost, because its progress file is shortest.
• H3. Protocol C has the fewest handoffs, because its initialiser does the exploration once and the worker’s windows are shorter.
• H4. The omission rate is highest for Protocol A (the minimal fields omit the rationale), and the corruption rate is highest for Protocol B (the richer artefact has more fields to corrupt).
• H5. The inconsistency rate is highest for Protocol C (the initialiser’s plan and the worker’s progress can diverge).

8.26.5 Acceptance criteria

8.26.6 What good looks like

A good lab report has five properties.

It measures the failure modes, not just the completion rate. The completion rate is a summary; the omission/corruption/inconsistency rates are the diagnosis. A report that says “Protocol B completed 72%” without saying why the other 28% failed has missed the point.

It applies the sufficiency test. The fresh-agent test is the direct measure of whether the artefact is sufficient. A report that infers sufficiency from the completion rate (the agent completed, so the artefact was sufficient) has confounded the artefact with the agent’s ability to recover from an insufficient artefact.

It reports the handoff budget. The artefact’s length is a cost, and the cost is justified by its content (Proposition 8.3.1). A report that says “Protocol B is best” without saying “at a 40% token premium” has missed the trade-off.

It analyses the failures by mode. Each failure is traced to a mode (omission, corruption, inconsistency), and the mode is traced to a field (the missing rationale, the stale fact, the conflicting status). The analysis is the diagnostic that leads to the fix.

It states the revision condition. Under what observation would you change the protocol? A larger effective context, a different task distribution, a different model — each would change the answer, and the memo should say which.

MODULE 8 CHEAT SHEET

EXERCISES WITH SOLUTIONS

E8.1. A task has $L_{\text{nom}}=300\text{k}$ tokens, $W=128\text{k}$, and the model’s $L_{\text{eff}}(0.05)=40\text{k}$. How many windows does the task require? What would you measure before designing the handoff?

S8.1. $W_{\text{useful}}=\min(128\text{k},40\text{k})=40\text{k}$, so $n_w\approx300/40=7.5$, i.e. 8 windows. Before designing the handoff, measure: (1) the per-window token cost of the artefact (the handoff budget); (2) the failure modes’ rates on a sample (which fields are missing, wrong, or conflicting); (3) the sufficiency test (a fresh agent’s ability to continue from the artefact). The measurement is the input to the field design; the field design without the measurement is a guess.

E8.2. A subtask requires reading 20 files (40k tokens) and returning one fact. The orchestrator’s context is 60k of 128k. Should it be delegated?

S8.2. The isolation benefit: the 40k of files would crowd the orchestrator (60k + 40k = 100k of 128k, leaving 28k for the rest of the task), and the 40k is mostly irrelevant (only the fact matters). The coordination cost: a spawn (small), a specification (“read these files, find the fact”), a result (the fact, small), an integration (record the fact, small). The isolation benefit (avoiding the 40k crowding) exceeds the coordination cost (a few thousand tokens). Delegate, unless the fact needs the orchestrator’s context to interpret (in which case the integration cost rises and the decision may flip).

E8.3. A progress file has the fields “task, plan, completed, current” but no “discovered facts” or “decisions made.” The next window’s agent re-reads a file it already read and re-litigates a decision. What are the failure modes, and what fields are missing?

S8.3. The re-reading is an omission: the “discovered facts” field is missing, so the agent does not know what it already found. The re-litigation is also an omission: the “decisions made” field is missing, so the agent does not know what it already decided. The fix: add both fields. The diagnosis: the next window’s agent’s behaviour (re-reading, re-litigating) is the signal that the artefact is insufficient, and the sufficiency test (a fresh agent’s continuation) is the measurement.

E8.4. An instruction file is 10,000 tokens, and the measurement shows that it improves success by 2 points. The token cost is 10,000 per run. Is it worth it?

S8.4. It depends on the cost of a failure and the value of a success. If a success is worth $V$ and the token cost is $c_{\text{tok}}$, the file is worth it iff $0.02V>10{,}000\,c_{\text{tok}}$. At a token price of 3 per million, the token cost is 0.03 per run, so the file is worth it iff $0.02V>0.03$, i.e. $V>1.5$. For most tasks, a success is worth much more than 1.5, so the file is worth it — but the 2-point improvement is small, and the file is a candidate for pruning (the removal test). The parts of the file that contribute the 2 points should be identified, and the parts that do not should be removed (the curation policy).

E8.5. A task graph has a missing dependency: step C uses step A’s output, but the graph does not have an edge A→C. What happens, and how would you detect it?

S8.5. The traversal can run C before A, so C uses an output that does not exist yet (or a stale output from a previous run). The failure is a dependency violation, and it manifests as C failing (the output is missing) or C succeeding with the wrong input (the output is stale). Detection: (1) the verifier checks C’s output against the expected input (a type or value check); (2) the traversal records the inputs each node used, and a mismatch is a violation; (3) a static check of the graph against the task’s data dependencies (if they are known). The fix: add the edge. The lesson: the graph is a model of the task’s dependencies, and a wrong model produces a wrong plan; the graph’s construction is a design activity that must be verified.

E8.6. A skill library has 200 skills, and the agent uses 20 of them. What is the curation problem, and what would you do?

S8.6. The problem is unused skills: 180 skills are in the library but not used, and they consume retrieval and review effort (the similarity search scans them, the review must maintain them). The curation: (1) measure each skill’s usage (a usage count); (2) archive the unused skills (move them to an archive, not delete them, so they can be recovered); (3) review the archived skills periodically (they may become useful when the environment changes); (4) test the used skills periodically (they may rot). The lesson: the library’s size is not its value; its used size is, and the curation is the discipline that keeps the used size manageable.

E8.7. A colleague proposes the initialiser pattern for a task where the plan changes as the execution proceeds. What is the problem, and what would you recommend?

S8.7. The initialiser pattern assumes the plan is stable: the initialiser writes the plan, and the worker executes it. If the plan changes as the execution proceeds (the task is exploratory), the initialiser’s plan is stale by the time the worker uses it, and the worker either follows a wrong plan (rigid commitment) or ignores the plan (the initialiser is wasted). The recommendation: use the worker pattern (a single agent, multi-window, with the progress file updated at each step), which allows the plan to change as the agent discovers. The initialiser pattern is for tasks where the exploration can be completed before the execution; the worker pattern is for tasks where they are interleaved (the Module 1, §1.7 decision, at the long-horizon level).

E8.8. A subagent returns a 500-token summary of a 50k-token search. The orchestrator cannot use the summary because it does not fit the orchestrator’s schema. What is the failure mode, and what is the fix?

S8.8. The failure mode is integration failure (§8.13.2): the result does not fit the orchestrator’s schema, so the orchestrator cannot incorporate it. The fix: (1) specify the result’s format in the subagent’s specification (a schema for the result, with the fields the orchestrator needs); (2) have the orchestrator verify the result against the schema before using it (a result verifier); (3) if the result does not fit, re-delegate with a clearer specification or fall back to inline. The lesson: the specification must include the result’s format, not just the task’s content; the result is an interface, and the interface must be specified.

EXIT TEST FOR MODULE 8

You are ready for Module 9 when you can, without notes:

1. Define the three task lengths and compute the window count from the useful window.
2. Explain the three qualitative changes of long tasks (compounding loss, cross-window consistency, cross-window verification).
3. Define the handoff, state the sufficiency condition, and name the three failure modes.
4. State the handoff budget trade-off and apply it to an artefact.
5. Design a progress file’s fields and apply the sufficiency test.
6. Distinguish the initialiser and worker patterns, and choose between them by the task’s structure.
7. State the handoff classification (mechanism irreducible, content compensating) and the maintenance implication.
8. State the delegation criterion and the four coordination costs.
9. Apply the delegation decision procedure to a subtask.
10. Name the four delegation failure modes and their detections.
11. Design an instruction file’s five sections and apply the sufficiency test.
12. Explain progressive disclosure, instruction rot, and the curation policy.
13. State the three planning representations and choose among them by the task’s dependency structure.
14. Explain spec-driven development and its connection to the verifier.
15. State the Voyager result, its evidence status, and the transfer caveat.
16. Classify the skill library’s content, mechanism, and curation.

End of Module 8. Say “next” to receive Module 9 in full.