# Keep Context in the Right World
# Book: Context From First Principles
# Chapter URL: https://programmer.ie/books/context/21-chapter/
# Prose fingerprint (sha256, normalized): 744a323193f2373513c1a426546478768790a34eec011e3e7da9e2732639679f
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

The task belongs to Project A: backend PostgreSQL, test command pytest, migration complete. Project B lives beside it: backend SQLite, test command npm test, migration pending. The agent’s context holds both projects’ configs, READMEs and migration notes. Every item is authoritative in its own project, current, accurately represented, accessible to the runtime and similar enough to the query that retrieval surfaced all of it.
The agent runs npm test in Project A, watches it fail for reasons unrelated to Project A’s code, and then debugs the backend mismatch by reasoning about SQLite, quoting Project B’s migration state as though it constrained Project A. No attacker exists, no stale data entered, and each source retained its authority within its own project. The failure is not that the items were intrinsically wrong or that a source’s authority was globally violated. The agent treated information valid in Project B as applicable to Project A without a justified cross-scope rule. The scenario is illustrative, not an observed trace.
Correct information from the wrong world is wrong Context.
“Wrong” means wrong for this computation. Project B’s config is not globally false. The question this chapter owns is:
Which world must an item describe, belong to, or be valid within before it is eligible to influence this computation?
It owns scope identity, compatibility, isolation, transfer, shared applicability, unknown scope and wrong-world contamination. It does not own relevance (Chapter 14), authority (Chapter 19), freshness (Chapter 20), access control, representation (Chapter 18), ranking (Chapter 22) or assembly (Chapter 23).
What a world is A world here is operational and not mystical: a declared set of bindings that identifies the state or domain to which a computation’s claims and actions must apply. Possible dimensions include project, repository, workspace or worktree, branch or revision, deployment environment, tenant, user, task, agent, experiment run and namespace. These are examples rather than a universal schema; some identify the object of reasoning, others the execution setting or its principal. They are not necessarily a hierarchy, and not every dimension needs to govern every item. A computation might carry project A, worktree feature-17, task migration-review and reviewer agent simultaneously, with the compatibility policy stating which bindings matter for each candidate:
scope dimensions ≠ universal hierarchy agent identity ≠ world identity Sometimes task state is project-local, sometimes an organisation contract spans projects, sometimes a tenant boundary dominates, and sometimes an agent works across several projects. A computation can also intentionally span more than one world, for instance a comparison of Projects A and B:
one computation ≠ exactly one world Scope is relational, not merely a label attached to an item. Conceptually the question is scope_compatible(candidate bindings, computation bindings, applicability and transfer rules), notation for reasoning rather than a schema. Two things must remain distinct: bindings state the origin or applicability asserted for the candidate and the world requested by the computation; compatibility rules determine whether that candidate may contribute in that role. Equal project identifiers may be insufficient if worktree state matters, and unequal identifiers may be acceptable for an explicitly shared contract or cross-project comparison. The rule is externally specified, and its inputs need evidence and a stated policy version. The book introduces no scope algebra before experiments establish a need for one.
A related distinction is between belonging and applying. An item may belong to Project B and may still be considered in Project A under an explicit transfer, and an organisation contract belongs to shared scope and applies in both projects. Scope also often works by restoring an omitted argument to a proposition:
backend = PostgreSQL, backend = SQLite (apparent contradiction) backend(A) = PostgreSQL, backend(B) = SQLite (no contradiction) What scope is not Scope is separate from four neighbours, and each pair is independent:
relevant-looking ≠ in scope authoritative ≠ in scope fresh ≠ in scope accessible ≠ in scope in scope ≠ accessible Two projects sharing language, frameworks and file names can be near-identical in embedding space while belonging nowhere near each other, so a semantically perfect match can describe another project. Project B’s decision record governs Project B and nothing in Project A, with no demotion of the record. Project A’s old config is in scope and temporally invalid, and Project B’s current config is fresh and out of scope. Provenance can supply evidence for scope, and it is still not scope: a shared standard originates in a standards repository and applies to Projects A and B. Object identity is not scope identity either, since one immutable artifact can participate in several scopes without being duplicated to manufacture them.
Access control asks what a process is permitted to read, write or execute; scope compatibility asks whether information from a source is applicable to the computation at hand. A neighbouring repository can be readable yet inapplicable, and a shared contract can be applicable yet inaccessible without permission. The two controls may both be required, but passing a context-scope check must never substitute for access control or tenant isolation. This chapter studies correctness under non-adversarial wrong-world contamination, not a security boundary against malicious or unauthorised access. Isolation follows the same caution:
Context isolation ≠ filesystem isolation Context isolation ≠ security isolation A model not being shown Project B differs from the process being unable to read it.
Scope also does not decide relevance or inclusion. Project A’s whole history may clear the scope boundary while a budgeted bundle admits three items:
scope-compatible ≠ relevant ≠ admitted ≠ selected Exclusion is computation-relative, and out of scope here is not deletion and not invalid globally.
Where bindings come from A scope label is not a trusted binding. A README saying it applies globally does not make it global, and payload declarations gain nothing from being made. Bindings can come from the runtime, an adapter, an authenticated identity, an explicit transfer record, a payload declaration or a model inference, or be unknown, and the evidence class matters:
scope label ≠ trusted scope binding path resemblance ≠ project identity deterministically derived ≠ semantically correct Where the runtime can attest repository, session or worktree identity, the system should preserve that evidence rather than ask the model to guess from content. Deterministic derivation improves reproducibility and audit, not correctness by itself: an adapter can bind the wrong worktree or silently inherit an obsolete session value. Paths are locators rather than sufficient identities; aliases, renames and parallel worktrees can make the same path string refer to different state. Opaque workspace or repository identifiers are useful where available, provided the runtime can relate them to their attested origin and version.
Unknown scope stays a first-class state:
unknown ≠ global unknown ≠ shared unknown ≠ local unknown ≠ safe Unknown stays unknown until a policy decides how to handle the uncertainty; a policy outcome does not retroactively establish the missing binding. A conservative project-specific action may reject or defer the candidate, while exploratory search may display it as explicitly unscoped evidence that cannot silently become a project fact. The applicable risk and omission cost should be stated. Missing scope must not be silently interpreted as global applicability, and an UNKNOWN rejection must be counted separately from a demonstrated mismatch.
Project scope, and what it does not cover Project scope is the cheap first boundary and not the world:
project root ≠ the world same repository ≠ same world same path ≠ same object Within one repository, main, feature branches, release lines and parallel worktrees can refer to different working states. Production at v4 and staging at v5 may both be current for their respective environments: a question about production excludes a staging-only assertion, while a comparison intentionally needs both. Environment identity and temporal standpoint can be orthogonal even if a system encodes them in one revision identifier. A branch-versus-branch distinction often changes the target world; C1 versus C5 on the same branch primarily changes which temporal state is requested. OpenAI’s worktree documentation describes separate checkouts that let parallel chats work without modifying one another’s files. That is filesystem isolation, not proof of context isolation: retrieval, memory or shared tools can still supply information from another worktree.
Tasks subdivide projects. A benchmarking task records a working hypothesis that SQLite outperforms PostgreSQL, while the release task carries the standing decision that PostgreSQL is the backend. A project-wide pool leaks the hypothesis into release reasoning, where it reads as doubt about a settled decision. Neither item is wrong in its own task and each is contamination in the other, so project membership does not imply task admission. A project-wide item may be scope-compatible with project-local tasks under an explicit inheritance rule, and:
scope inheritance ≠ semantic inheritance parent-scope membership ≠ automatic child admission Inspect this in the Context Viewer The viewer scene for this chapter checks candidates against the Project A computation: native items eligible, Project B material excluded despite its relevance, the shared contract admitted, one unknown deferred. Open the scene and read each binding decision. What to examine: why the SQLite and npm-test items fail here while succeeding in their own world, and what the explicit transfer record — and only it — permits across. Relevant is not in-scope; unknown is never silently shared.
In-scope is not relevant, authoritative, fresh or accessible. Constructed illustration. Open the scope scene in the Context Viewer
Shared scope and transfer Shared scope is a source or item whose declared applicability intentionally spans more than one computation scope, such as an organisation coding standard or API contract. Shared is not universal: an item used by several projects may apply only to a named set, and global should be explicit and rare. A shared contract still needs version and authority (scope ≠ freshness, scope ≠ authority), since it can be in scope, superseded and non-governing for a decision.
Transfer is an explicitly authorised use of a source-scoped item in a target computation across a declared boundary. The record should preserve the origin scope, source identity, reason for transfer, target computation, applicable version and status, and any separate authority or permission determination; this chapter does not prescribe a schema. For example, Project B’s incident report can be consulted as an analogy while remaining evidence about B, not evidence that A has the same failure. Transfer establishes eligibility to consider a claim in the target computation, not equivalence of worlds, factual transferability or a right to act on the source’s instructions:
transfer ≠ origin rewrite transferred ≠ native transfer ≠ authority promotion transfer ≠ freshness renewal transferred ≠ relevant here transferred ≠ admitted A Project B artifact read in Project A remains Project B evidence, and the model should know it is being considered here and not that it is Project A state. Transfer changes scope eligibility only. Promotion is different: changing an item’s standing scope so it becomes a reusable candidate in a broader world. Promotion is hypothesised to be rarer than transfer, and it carries the risk that incidental task state becomes permanent project background. Scope membership is also not permanent identity: a hypothesis becomes an accepted decision, a branch merges, an artifact is copied, and whether the item moves or a new item is created with lineage is left open.
Several neighbours cross scope without carrying it:
reference in scope ≠ referent in scope tool capability scope ≠ result scope memory retrieved ≠ memory in scope derived item ≠ scope-free item A summary derived entirely from Project B does not become unscoped when its details are compressed, and a synthesis across A and B has multi-scope provenance. Where scope changes the meaning of a proposition, scope qualifiers are preservation obligations (Chapter 18): the two backends must not collapse into backend = {PostgreSQL, SQLite} without project association.
Subagents and bounded handoff The useful question is what crosses from one scoped computation to another, and this is not a multi-agent chapter. OpenCode’s documentation describes subagents as child sessions that can have their own prompts, models and permissions, with navigation to the parent. That is implementation evidence and shows nothing about Context isolation. Anthropic’s engineering essays describe separate context windows, condensed returns and file-backed artifacts, as patterns and not proof of general superiority.
A child receiving only its subtask objective, the relevant shared project constraint and its own migration evidence cannot be directly influenced by a sibling item it never sees. That is a reduction of one exposure pathway, not a guarantee that its inputs are sufficient or that no contamination reaches it indirectly through tools or later handoff. Child-session identity is not scope identity: one child may compare projects, while two children may operate in the same task scope. Restricting handoff reduces opportunities for contamination and raises the risk of missing necessary dependencies:
less contamination ≠ sufficient context handoff ≠ scope promotion handoff ≠ authority promotion handoff ≠ freshness renewal Too much sharing can introduce wrong-world evidence; too little can strand dependencies. Bounded handoff is therefore a tested trade-off, not an unconditional recommendation. Record distinct stages: a required candidate not generated, generated but rejected because scope was unknown, rejected by an incorrect compatibility rule, admitted with an incorrect binding, unavailable because a shared or transfer rule was missing, or admitted correctly but used as if it described the target world. Admission-level contamination means an incompatible item entered the bundle; behavioural contamination requires a demonstrable wrong-world effect. Over-isolation means a required applicable item was excluded. Each rejection record should retain the item identity, attested bindings, active computation bindings, policy version and reason without exposing unnecessary private paths.
The evidence None of these sources tested this book’s fixtures.
Source Type Population/system Verified claim Chapter use Does not establish Sibling Memory project, stored run (not independent evidence) Non-independent experiment 68-unit, three-project corpus, fixed budget, 11 tasks Restricting candidates to the project took admission-level cross-project leakage from 0.2124 to 0 with must-include recall unchanged at 0.7727 and precision higher; on a similar-project fixture, leakage went from 0.6667 to 0 Project scoping can remove admitted wrong-project items without losing recall on a controlled corpus Behavioural effect, production scale, or that Context’s architecture works Zhang et al., SILO-BENCH (ACL 2026) Peer-reviewed benchmark 30 tasks, 6 agent scales, 3 frontier models Agents holding fragments communicate actively and fail to turn it into effective distributed computation; the hardest tier had zero success beyond 50 agents Too little sharing can strand dependencies Anything about coding agents Patel, DACS (arXiv, April 2026) Single-author preprint Synthetic scenarios, LLM-as-judge A registry-plus-focus design reduced cross-agent contamination on the author’s synthetic scenarios A neighbouring mechanism That the design works, or validation of this architecture OpenAI worktree documentation Product documentation Codex Worktrees let parallel chats run in separate checkouts of one project, with handoff to a local checkout Filesystem isolation exists in practice Context isolation OpenCode agents documentation Product documentation OpenCode Subagents run as child sessions with configurable prompts, models and permissions Implementation pattern Context isolation Anthropic multi-agent research system and context-engineering essays Vendor engineering Anthropic’s systems Separate windows, condensed returns and filesystem artifacts Bounded-handoff pattern General superiority The WithContext MCP server is dropped: it only shows that someone built project-folder scoping. Leakage in the Memory run means admission of an out-of-scope item, and behavioural use is separate:
out-of-scope admitted ≠ out-of-scope used ≠ unauthorised access Ecological gate The observer corpus is empty. Its capture schema includes session, agent, provider and model identities, request kind, messages, tools and timing, but not verified project, task, parent-child or worktree identities. Capturing a session identifier is not evidence of the computation’s scope: observable ≠ observed ≠ correctly bound. Before adding rich scope machinery, real traces should measure concurrent projects and worktrees, cross-project candidate exposure, same-name collisions, attested versus inferred bindings, the UNKNOWN rate, admission-level leakage and separately tested behavioural effects, shared-artifact use, explicit transfers, task-local leakage, subagent handoffs, omission failures, derivation mistakes and metadata cost. Classifying genuine traces would require an independent scope reference or reviewed labels; heuristics derived from paths or vocabulary cannot also serve as ground truth. If one repository, one worktree and one task dominate, a multidimensional policy may have little opportunity to improve outcomes:
cross-scope contamination is possible ≠ its production prevalence is known
Proposed experiments Nothing here has been run. Candidate contents and representations, authority, freshness, source versions, relevance scores, budget, model, decoding, task, computation scope and order are frozen, so scope handling is the intended variable.
Experiment A: scope enforcement. Does explicit compatibility checking reduce admission of wrong-world information without excluding required cross-boundary evidence? Fixtures span distinct projects, environments and tasks, and include shared, transferred, unknown and multi-world candidates. Before conditions run, freeze the source-state identities, the target worlds, the accepted sharing and transfer rules, and item-level applicability labels independent of the tested policy. Each condition receives the same candidate universe, representations, source metadata and task; only the declared scope policy and any labels it is allowed to use vary. To isolate scope from budget competition, first evaluate compatibility decisions for all candidates, then evaluate equal-budget assembled bundles and behaviour. A rule that happens to remove a large irrelevant item can change position and interference as well as scope, so those consequences are outcomes, not proof of the intended mechanism. Fixtures:
a cross-project collision (same filenames, issue number and vocabulary, conflicting valid facts); same project, different environment (main against a feature worktree); a legitimate shared artifact, so blocking everything non-native fails; an explicit transfer of one Project B artifact needed in Project A; an unknown-scope candidate; a task-local collision within one project; a multi-world comparison of Projects A and B, where a single-active-project policy must fail. Conditions, applied only where meaningful: no scope gate (global pool), visible origin labels without exclusion, project-only compatibility, project-plus-environment compatibility, project-plus-environment-plus-task compatibility, explicit shared applicability, explicit transfer, and an oracle policy grounded in the fixture’s frozen rules. Each policy’s treatment of UNKNOWN is specified in advance; otherwise a rejection policy can appear more precise simply by abstaining. Report item and token counts for incompatible admissions, required applicable items rejected, unknown decisions, preservation of shared and transferred evidence, and policy errors separately from wrong-world commands, paths, backend assumptions, tests and task success. Record metadata and transfer-token costs, steps and matched-budget effects. The labels-only condition tests whether model-visible warnings suffice in the tested fixture, whereas the gate condition removes ineligible material; neither establishes an access-control guarantee.
Outcomes that count: labels match exclusion on behaviour; project-only removes contamination and the richer dimensions are not built; project-only fails on branch collisions and environment scope is earned; task scope adds nothing; shared scope causes more mistakes than explicit transfer; unknown handling causes substantial omission; or filtering changes the context and not the behaviour.
Experiment B: isolated child context. When one task is divided among scoped child computations, does bounded handoff reduce wrong-world influence without withholding information needed for the parent outcome? Freeze the parent task, decomposition, child objectives, environment observations and ground-truth obligations before comparing conditions. The fixture includes a misleading sibling item, one shared constraint required by every child, a result that must cross back to the parent, parent-only state that should remain private to its task and a required fact whose omission is consequential. Conditions are one shared context, objective-only children, bounded children with shared constraints, parent-selected handoff, artifact/reference handoff, parent-mediated transfer and an oracle sufficient handoff. Match the decomposition and tool opportunities, and report child and parent success separately: a correct child output can still be misintegrated by its parent. Measure sibling-item admission and behavioural influence separately, missing required evidence, failed resolution of handed-off references, handoff and expansion tokens, coordination calls, duplicated context and total cost. An improvement cannot be attributed to isolation alone if conditions also change the model’s tools or decomposition.
Simplification criteria and falsifiers. If project-only compatibility matches richer policies on wrong-world behaviour, required-evidence coverage and total cost across representative collisions, environment and task dimensions have not earned implementation complexity for that workload. If model-visible labels match exclusion on those same measured outcomes, hard exclusion has no demonstrated behavioural advantage there, though neither result establishes a security boundary. If explicit transfers cover legitimate crossings with acceptable effort and omission, shared or federated machinery is premature. If child isolation fails to reduce behavioural contamination or creates greater task loss through omissions, the tested handoff strategy has not earned adoption. These are workload- and policy-relative findings, not proofs that other scope dimensions or enforcement mechanisms are unnecessary.
What the compiler is given The candidate builder derives a scope eligibility verdict, and the current compiler enforces rather than verifies it. The implementation compares a candidate’s declared single scope string with the request’s single active scope string. A missing or empty declaration is rejected, equality is eligible and inequality is rejected, each with a reason. The compiler gates ineligible candidates before ranking or budget competition; in a deterministic fixture it rejects a wrong-project configuration despite relevance 0.99. This demonstrates gate enforcement against supplied strings, not correct scope attribution, shared applicability, multi-world reasoning or an observed production effect.
Current UNKNOWN handling rejects the candidate; this is a conservative implementation choice, not a finding that unknown means incompatible. A boolean verdict with a reason may suffice at the compiler boundary if an upstream policy has already evaluated the task’s relevant worlds, verified bindings, shared applicability and transfers. Today it has not: the single-string comparison cannot express multiple target worlds, shared scope or a transfer record, and it does not attest the candidate’s scope declaration. The conceptual model therefore exceeds the implemented derivation. Its richer form is a proposed policy to test, not a capability the current compiler possesses.
The handoff Scope is the relationship between the worlds an item belongs or applies to and the worlds a computation is allowed to reason within. It narrows eligibility before allocation, shared applicability and transfer provide controlled crossings without rewriting origin, and every boundary must be tested for omission as well as contamination. The engineering goal is the simplest scope policy that removes wrong-world influence while preserving the cross-boundary dependencies the computation needs.
Authority, freshness and scope have now each become a judgement attached to a candidate, and scope-compatible ≠ selected. The candidates that survive are eligible, and they still compete for one budget, depend on one another, come in several forms and include some that must be present. Given every candidate that is allowed to speak, which exact set should receive the finite context budget, and how should the constraints interact? That is Chapter 22.
References Sibling Memory project (unpublished manuscript; runs in the public project-memory repository). Project-scoping run checked against stored results in this pass: cross-project leakage 0.2124 to 0 with must-include recall 0.7727 unchanged; 0.6667 to 0 on the similar-project fixture. Non-independent, and it motivates the fixtures here. Zhang, Y., Liu, F., Shan, Y., et al. “SILO-BENCH: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems.” ACL 2026 (San Diego, pp. 29379–29398). https://aclanthology.org/2026.acl-long.1354/ Patel, N. “Dynamic Attentional Context Scoping: Agent-Triggered Focus Sessions for Isolated Per-Agent Steering in Multi-Agent LLM Orchestration.” Preprint, arXiv:2604.07911 v1, April 2026. Single-author, synthetic scenarios. https://arxiv.org/abs/2604.07911 OpenAI. “Worktrees.” Product documentation, verified September 2026. https://learn.chatgpt.com/docs/environments/git-worktrees OpenCode. “Agents.” Product documentation, verified September 2026. https://opencode.ai/docs/agents/ Anthropic Applied AI team. “Effective context engineering for AI agents.” Engineering essay, 29 September 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., Ford, D. “How we built our multi-agent research system.” Anthropic engineering essay, 13 June 2025. https://www.anthropic.com/engineering/multi-agent-research-system