Context windows and durable work understanding solve different problems

Capacity does not establish applicability.

A coding task can fit all its available history into a model’s context window and still lack a clear answer to a crucial question: which part of that history should govern this change? Space and authority are different properties. A proposal and an accepted contract can both fit comfortably.

Anthropic’s context-window documentation describes the window as the material a model can reference while generating a response, including the response itself. Its context-engineering discussion describes selecting relevant material and retaining notes outside that window for later retrieval. These are useful mechanisms; neither makes a saved statement current merely by preserving it.

The engineering implication is to maintain an inspectable relationship between a claim, its source, its status, and its scope. This article calls that durable work understanding. It is a proposed way to organize evidence, not a claim that a model stores human understanding or that one product guarantees it.

Give capacity, retention, and selection distinct jobs.

More capacity is useful when the task genuinely needs more material together: for example, several current interface contracts and the implementation that connects them. Retention is useful when a later task needs evidence from earlier work. Selection is useful when only part of that evidence changes the next action.

A larger window can support careful selection too. There is no requirement to choose a smaller model input or a new retrieval system. Start with what is missing from the task, then choose the least complicated way to supply it.

Compare two preparations for a fictional retry change.

The task is to add retry support to a fictional orders client. An accepted decision requires the same request ID to recover the original order. A later discussion proposes a new response shape for another API version. A client fix now preserves identifiers across retries, but service overlap handling remains uninspected. No source resolves a reused ID with a different body.

One preparation includes every transcript and report but leaves these relationships unstated. Another includes the accepted requirement, the proposal’s scope, the client fix, and the unresolved service checks, with source links. The second makes the next questions explicit; this example does not establish that a model would answer it better or faster.

The full transcripts may still be necessary to resolve a disagreement. Keep them accessible. The point is to preserve the distinction between an adopted requirement, a possible change, and evidence from one test, whether the final input is short or long.

Use an applicability map before adding more history.

For each claim that could change the implementation, record what supports it and what remains unchecked. Include the date and the relevant service, caller, or version. A date helps locate an account; it does not by itself give that account authority.

This map is a planning artifact for the fictional task. It separates the demonstration contract from facts that an engineer must inspect in their actual system.

Task: retry order creation — fictional example
Requirement: same request ID recovers the accepted order
Source: accepted orders decision; scope: current API version
Exception: response can be lost after acceptance
Source: fictional incident account; check applicability to this caller
Proposed change: new response shape; not adopted for this version
Current evidence: inspect identifier lifetime and acceptance/recovery path
Completed: client identifier fix; inspect its test evidence
Pending: service overlap verification; other callers unknown
Unresolved: same ID with a different body
Next action: ask contract owner; preserve policy uncertainty in the plan
Refresh trigger: contract adoption, caller change, or contradictory evidence

Choose the smallest intervention that closes the gap.

If the accepted contract is already in a repository document, link it and check the implementation. If the missing fact is a pending decision, ask its owner; adding older context cannot establish an answer that has not been decided. If the material exists but is hard to locate, improve its index or retrieval path.

Ordinary files, version history, and the coding tool’s available instruction or note mechanisms may be sufficient. Check the tool’s current documentation before depending on persistence or automatic loading. A stored note that is never supplied to the next task cannot affect that task, and an automatically supplied note still needs an applicability check.

After a task, retain decisions, reasons, exceptions, source links, and unresolved work that will matter again. Remove completed status from the active brief while retaining its verification record. Give this maintenance an owner.

Test a specific handoff before buying a broader solution.

On one service, give a colleague an active change and the available evidence. Ask them to identify one accepted constraint, one proposal, one checked behavior, and one unknown. Record what they could establish and which source or owner they still needed.

A team lead can repeat this on a few comparable tasks using permitted sources and ordinary review controls. Measure preparation effort, missing-source questions, and whether reviewers can trace important claims. Include the maintenance time spent keeping the map current. Stop if the exercise adds ceremony without changing a decision or check.

This is a diagnostic trial, not a benchmark proving the effect of context length. A controlled model comparison would need to hold the task, model, instructions, and evaluation constant. No result here establishes correctness, delivery gains, customer demand, or superiority over another review tool.