Keep Context in the Right World

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, both READMEs, both migration notes — every item authoritative in its own world, fresh, accurately represented, and semantically similar enough that retrieval surfaced all of it. The agent runs npm test in Project A, watches it fail for reasons that have nothing to do with Project A’s code, and then debugs the backend mismatch by reasoning about SQLite — quoting Project B’s migration state as though it constrains Project A’s deployment. No attacker exists. No stale data entered. No authority was violated. The context was correct, current, and legitimate in every way except the one that mattered: half of it belonged to another world.

Correct information from the wrong world is wrong Context.

Membership, not importance

The durable definition:

Scope identifies the world, workspace, task, or compartment in which a context item is eligible to influence a computation.

Scope answers where information belongs. The current computation answers which world it operates in. Admission compares the two. Availability to the surrounding system implies nothing about membership: two config files may both be readable by the runtime while only one belongs to the task. Scope is therefore about eligibility, and four separations keep it clean. Semantically relevant-looking is not in scope — two projects sharing language, frameworks, file names, and architecture concepts can be near-identical in embedding space while belonging nowhere near each other. Authoritative is not in scope — Project B’s decision record governs Project B fully and Project A not at all, with no demotion implied. Fresh is not in scope — two main branches can both be current with different backends, and no temporal rule chooses between them. Accessible is not eligible: an agent with filesystem access to every project directory is not thereby entitled to reason from all of them, just as an item conceptually in scope may still be barred by runtime permissions. Work both directions so the independence is visible. A workspace readable in full still restricts the migration task to its own project’s candidates, because readability answers what the process may touch and scope answers what may influence this computation. Conversely a shared contract conceptually in scope for the task still requires its own access grant before any byte is read — membership never picks a lock. Access control asks what a process may touch; scope asks what may influence this computation. The chapter designs no permissions, tenants, or authentication; it asks only the eligibility question and leaves enforcement to systems built for it.

Isolation, on this framing, is a correctness mechanism before it is a security one. Wrong-project items cause wrong conventions, paths, dependencies, configurations, architecture assumptions, and unfinished-work states in fully trusted environments with no adversary present. Privacy follows as a consequence — user histories and credentials must not cross computations — but the primary experiment measures ordinary contamination, not exfiltration, so the chapter never becomes a security sequel wearing Chapter 19’s clothes.

Bindings, not a hierarchy

Scope dimensions refuse to form one neat tree. A computation may carry project A, the migration worktree, task fix-17, and a reviewer agent role simultaneously — orthogonal bindings, not levels of a ladder. The chapter prefers scope bindings to any universal global-to-agent hierarchy, and defines the computation side minimally: a computation has explicit scope bindings against which candidate eligibility is checked, in reader-facing language simply the world of this computation. Items carry their own bindings — project, environment, task, sometimes shared markers — with unknown left unknown and never defaulted to global. Missing scope must not mean everywhere; that default is how local assumptions contaminate unrelated tasks.

Bindings come from provenance and runtime identity wherever possible, under the same discipline Chapter 19 set for authority. A document announcing its own project membership or global scope gains nothing from the announcement; repository and workspace identity, source adapters, session and task metadata, runtime paths, authenticated tenants, and explicit transfer records decide, while payload labels travel as data the runtime may or may not trust. Deterministic identity precedes model inference everywhere the runtime already knows the answer: where the repository identifier says one project, resemblance to another is not consulted. Ordinary computation draws deterministic boundaries; model judgement handles only what unstructured imports leave genuinely ambiguous, and then marked as inferred.

The cheap boundary: project scope

Two projects with deliberately overlapping artefacts — READMEs, configs, migration notes, issue seventeens, architecture decisions sharing vocabulary but conflicting validly on backend, test command, migration state — make the fixture genuinely tempting to a global pool. The task names its world. Against that fixture the sibling Memory book already ran the controlled version this chapter consumes rather than repeats: on a 68-unit three-project corpus at a fixed token budget, restricting candidates to the project drove cross-project leakage from 0.212 to zero while must-include recall held exactly at 0.773 and precision rose; on a deliberately similar three-project fixture asking one question of all three, mean leakage fell from 0.667 to zero (frozen run ch10-20260920T163314Z-context-frames, eleven tasks, fixed reader). The consumed phenomenon is narrow and stated narrowly: project scoping eliminated cross-project leakage on that controlled corpus without reducing required-evidence recall at the project rung. No universal answer improvement, no production scale, no claim that labels solve every scope problem — and explicitly not the sibling’s ProjectFrame architecture, which this book does not copy.

Labels alone earn a separate measurement rather than an assumption. A prompt rendering both projects’ material with scope tags, asking the model to use only one world, is a legitimate condition — and a different one from never admitting the other world at all. The first asks the model to resist contamination with the contaminant present; the second removes it. Both are tested, because asking a model to ignore known-irrelevant content spends the very context the boundary was meant to save. Count it plainly: eight thousand tokens of Project B resident beside an instruction to disregard them costs the tokens, the positions they occupy, and whatever interference they exert despite the instruction — against zero tokens and zero interference for the boundary that never admitted them. If labels match removal on behaviour, the saving is real convenience; where they trail, the gap prices wishful governance.

The same project holds several worlds

Project scope is necessary and insufficient. Within one repository, main, feature branches, and release lines describe different states, and parallel worktrees hold deliberately divergent modifications — right project is not right environment, which matters most exactly where coding agents live. The fixture extends naturally: Project A on main against Project A on a feature branch, same paths, same names, conflicting states, with the task bound to one environment. Current Codex practice supplies the implementation case with its limits stated: built-in worktree support runs parallel chats in isolated repository copies with managed handoff between local and worktree checkouts. That is environment isolation in production form, and the chapter draws the boundary the docs imply but do not state — filesystem isolation and Context isolation are related but separate, since two chats in two worktrees can still each admit the other’s world through retrieval, memory, or shared tooling. Worktrees prevent file interference; scope policy prevents context interference.

Subagents generalise the same point across agent boundaries, and current systems converge on the shape. OpenCode’s present-day agent model runs subagents as child sessions with their own prompts, models, and permissions, navigable back to the parent — implementation evidence, fenced from the pinned V1 runtime that never observed it. Anthropic’s multi-agent research architecture isolates detailed local context in separate windows and returns condensed findings plus file-backed artifacts with lightweight references, explicitly to avoid repeated filtering loss through the coordinator. The transferable pattern is bounded handoff between scoped contexts, not any vendor’s orchestration. Sketch it on the release task: the migration-review child receives the subtask objective, the project’s backend decision and test conventions, and the migration evidence set — and nothing else. No documentation hypotheses, no packaging state, no parent deliberation. The child cannot be contaminated by what it never receives, and the parent’s later admission problem shrinks to one scoped report instead of three raw trajectories. But fresh or bounded child context is not automatically sufficient context: a child handed only its objective may lack the goal restatement, critical constraints, source identities, and project conventions the task needs. Isolation removes contamination by removing information, and omission failures are the price — the central counterweight the second experiment measures rather than asserts.

The counterweight has peer-reviewed form. SILO-BENCH, an ACL 2026 long paper, distributes fragments of algorithmic tasks across agent silos and finds a Communication-Reasoning Gap: agents communicate actively yet fail to convert interaction into effective distributed computation, with the hardest tier collapsing to zero success past fifty agents. The chapter imports the principle at its stated size, never the scale figures: too much sharing contaminates, too little sharing strands dependencies, and coordination does not automatically recover what boundaries hide. DACS, an April 2026 preprint, supplies the complementary mechanism from the other direction: an orchestrator holding lightweight per-agent registry summaries and expanding exactly one agent’s full state on demand, with reported steering accuracy far above flat-context baselines and contamination sharply reduced on synthetic scenarios. Single-author preprint, synthetic populations, author-reported figures — used narrowly for the asymmetric registry-plus-focus shape, never as settled architecture.

Narrower than project, wider when earned

Tasks subdivide projects. Release readiness, documentation rewriting, and migration benchmarking share one repository and almost no information needs; temporary hypotheses, scratch results, explorations, partial patches, and failed experiments are task-local state that should never become standing project candidates merely by existing inside the project. Trace one concrete collision to see why membership must be explicit: the benchmarking task records a working hypothesis that SQLite outperforms PostgreSQL on its synthetic workload, while the release task carries the standing decision that PostgreSQL is the backend. A project-wide pool lets the benchmark hypothesis leak into release reasoning, where it reads as doubt about a settled decision, and lets release constraints burden the benchmark, where they read as restrictions on an experiment designed to ignore them. Neither item is wrong in its own task. Each is contamination in the other. Chapter 14 already handles relevance; this chapter’s narrower point is membership — and the flow across scope levels runs asymmetrically. Project-wide constraints legitimately inherit downward into tasks, but task-local hypotheses must not bubble upward into project state without an explicit act. Promotion is rarer than readmission by hypothesis: a result needed once elsewhere travels by transfer or reference rather than graduating to permanent standing context, lest incidental state accumulate into the project’s permanent background.

Crossing itself is a first-class operation, not a policy failure. The Memory book result this chapter needs from the other repository arrives here by transfer, origin intact. The durable mechanism: identify the required external item, cross it explicitly, preserve its origin scope alongside the target, and admit it as transferred rather than native. Transfer never rewrites origin — a Project B artifact read in Project A remains Project B evidence — and never confers authority or currency, which stay with Chapters 19 and 20. Eligible for consideration here means exactly that, nothing more. Shared dependencies complete the picture without duplicating it: an organisation API contract or coding standard consumed by several projects deserves explicit shared scope rather than repeated one-off transfers or silent duplication, and the conveniently global default is refused — scope marked global must genuinely apply across its computations, because unmodelled scope is precisely how local assumptions travel. Consider the contract’s fourth version governing authentication across both projects: admitted once under shared scope with its version attached, it serves every computation that names it, while neither project’s local overrides leak outward through the shared item. Duplicate it per project instead and the copies drift; transfer it per task instead and the audit trail multiplies without need. Shared scope is the third mechanism alongside membership and transfer, chosen where the source genuinely serves several worlds at once.

What scope dissolves and what it costs

Two of the book’s standing puzzles dissolve on contact with scope. The PostgreSQL-versus-SQLite disagreement from Chapter 19 is not a conflict at all once provenance shows different project homes: simultaneously true in different worlds, no adjudication required — and the authority policy that would have arbitrated between them stands down correctly, having nothing to decide. The production-at-v4 versus staging-at-v5 tension from Chapter 20 is parallel current state, not staleness: different environment scopes, both valid now, with freshness policy validating against the task’s world rather than the newest one. In both cases the apparent disagreement was never about truth or time; it was about an omitted variable, and scope supplies it. Authority and freshness both turn scope-relative in the same move — a decision record governs inside its project, a commit describes its own worktree — which is why scope metadata must be known before either policy runs.

The economics run both directions and the experiment prices all of them. Isolation removes standing context, repeated unrelated history, and sibling chatter; explicit handoffs add summary and reference tokens, coordination calls, and artifact management. No prompt is declared cheaper in isolation — whole trajectories are measured, and constantly reshaped task scopes may disturb the stable prefixes Chapter 9 reuses, recorded without optimising scope for cache. Representation gains a small win along the way: a backend value with its project attached is unambiguous where the bare value collides, though metadata never substitutes for omitting what is irrelevant. Scope-eligible never means admitted — project membership passes eligibility while relevance, freshness, authority, budget, and representation still decide — which is what makes this chapter safe for Chapter 22 rather than a second admission system. The distinction matters in practice: Project A’s entire history may clear the scope boundary on a migration task while the budgeted bundle admits only the decision record, the current config, and the failing test output. Scope answers which worlds may speak; the remaining policies decide who gets the microphone. Collapsing the two would turn every in-scope project into a resident one, recreating at project scale the bloat Part II spent eight chapters removing. Deterministic mismatches filter before model reasoning wherever the runtime knows both bindings, with the reason preserved in the trace for later debugging; model judgement is spent nowhere a comparison could serve. A rejected candidate leaves a readable record rather than a silence: which item, which bindings it carried, which active world refused it, and which transfer or sharing rule was checked and found absent. Months later, when a task fails for want of evidence that existed somewhere in the system, that record answers in one lookup whether the evidence was missing, mis-scoped, or correctly excluded — the difference between a retrieval problem, a policy problem, and no problem at all.

Proposed experiments

Fixtures carry deterministic scope on every item, because the primary result must test enforcement rather than inference — the sibling book’s frame-inference warning (model-built frames nearly erasing the selection gain, stronger builders recovering it with repeatable misframes surviving) is consumed as the reason inference stays out of the headline conditions. Unknown scope, where it appears, resolves to exclude, defer, provenance-seeking, or explicitly marked unknown-scope admission by task risk, never to silent project assignment.

Experiment 1 — project and environment scope. Project A on main, Project A on a feature branch, Project B on main, with colliding paths, entity names, issue numbers, and terminology but conflicting valid facts per world; one legitimately shared dependency originating outside the target project so that block-everything-external fails honestly. The task names its world. Conditions: global pooled eligibility as baseline; pooled-plus-visible-labels testing soft separation; project-only eligibility; project-plus-environment; project-plus-environment-plus-task-local with explicit fixture task membership rather than a hidden reranker; scoped-plus-explicit-transfer admitting only the required shared artifact; oracle smallest sufficient scope from hidden fixture truth as ceiling — combined downward only where each distinct failure stays measurable. Authority, freshness, representation, content, model, and admitted-set ordering freeze throughout; every conflicting fact stays correct, authoritative, and fresh inside its own world, so only membership varies. Measurements: task success, required-evidence recall, cross-project, cross-environment, and cross-task leakage, wrong-world behavioural use, irrelevant and total tokens, transfer success against unnecessary cross-scope admissions — with leakage defined operationally as admission or behavioural use of untransferred out-of-scope items, reported as context leakage and behavioural contamination separately, wrong-world errors observed behaviourally through wrong commands, paths, and rules rather than token counts alone, and over-isolation scored as scope false rejection on the shared dependency.

Experiment 2 — subagent and task isolation. A parent release-readiness task with parallel migration, documentation, and packaging subtasks, each holding shared project constraints, subtask-specific evidence, one misleading sibling item, and one parent-needed result. Conditions: one shared giant context; fresh children with objectives only; fresh children plus bounded shared project context without sibling state; the same plus parent-mediated sibling communication; artifact and reference handoff; oracle minimum handoff. Children are scored on subtask success, sibling contamination, missing-constraint failures, and tokens; the parent on final success, handoff completeness, misattribution, duplicate work, cross-agent leakage, transferred tokens, and coordination steps. Handoff summaries inherit Chapters 11 and 15’s loss risks without re-running them — what matters here is the explicit boundary crossing with origin retained, child findings never flattened into anonymous parent fact. An optional inference challenger assigns one unlabelled artifact by deterministic path-or-provenance rules against content-only model guessing, testing whether provenance dominates guesswork; it stays subordinate by design.

Falsification prefers the boring outcome wherever earned. Labels alone eliminating contamination, repository and worktree isolation making filtering redundant, global pools behaving on realistic tasks, project-only scope capturing nearly all value, transfers costing more than shared admission, isolation causing more omission than it prevents contamination, one shared context winning outright, inference errors swallowing the benefit, upstream sources arriving perfectly scoped — each retires machinery, starting with the multidimensional engine the chapter refuses to build in advance. The standing rule closes the book’s longest-running argument: project root alone eliminating all tested leakage deletes everything fancier; trustworthy environment boundaries from existing systems are consumed, not duplicated; one explicit cross-scope artifact interface beats a federation layer until a measured failure says otherwise.

The laboratory implication is deliberately small: scope evidence on items, active bindings on the evaluated request, and a separate scope policy with eligibility rules, explicit shared scopes, and explicit transfer — no per-dimension item hierarchies, one common candidate interface throughout. Membership is stable on the item; allowability depends on active scope, transfer policy, and task, never on a scalar. Transfer audit trails answer origin, recipient, directness, authoriser, necessity, crossing representation, and attached identity. Crossings may copy, reference, summarise, or section-select under the representation rules already earned; the chapter requires only explicitness. Instrumentation gaps are recorded honestly: the pinned V1 observer sees sessions and message material but cannot reliably recover project, task, subagent, or worktree semantics, so no ecological leakage claim exists and future adapters will need opaque workspace, branch, session-relation, task, and transfer identities — never private paths in public exports. The corpus holds zero genuine sessions, and the chapter claims nothing about multi-repository frequencies, same-name collisions, surviving task state, subagent inheritance sizes, genuine transfer needs, or mid-session divergence. Fixtures prove the mechanism; later captures prove the workload. What remains, with authority, freshness, and world-membership all decided, is the question the whole book has been walking toward: given every surviving candidate with every constraint attached, what exact bundle should this computation receive.

References

• Memory book (sibling manuscript, ernanhughes/memory, in development; frozen runs are internal book evidence). Consumed: Ch10 project-scoping results (frozen run ch10-20260920T163314Z-context-frames; leakage 0.212 to zero with recall held; three-project fixture 0.667 to zero) with corpus and reader bounds; frame-inference warning as the reason inference stays out of primary fixtures. https://github.com/ernanhughes/memory
• Zhang, Y., Liu, F., Shan, Y., et al. “SILO-BENCH: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems.” Peer-reviewed, ACL 2026 long paper (San Diego, pp. 29379–29398). Fragment-only coordination with the Communication-Reasoning Gap and hardest-tier collapse. Used for the too-little-sharing principle at its stated size; scale figures never transferred. 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. Registry-plus-focus asymmetric isolation with reported contamination reductions on synthetic scenarios. Single-author preprint; narrow mechanism use only. https://arxiv.org/abs/2604.07911
• OpenAI. “Worktrees.” First-party product documentation, current pages, verified September 2026. Parallel chats in isolated repository copies with managed handoff. Used as environment-isolation implementation evidence; filesystem isolation explicitly distinguished from Context isolation. https://learn.chatgpt.com/docs/environments/git-worktrees
• OpenCode. “Agents.” First-party product documentation, current V2-line pages, verified September 2026. Primary and subagent types with child sessions, own prompts, models, and permissions. Cited as present-day implementation evidence; the pinned V1 runtime never observed it. https://opencode.ai/docs/agents/
• Anthropic Applied AI team. “Effective context engineering for AI agents.” First-party engineering essay, September 2025, verified September 2026. Subagent architectures with clean windows and distilled returns, used for the bounded-handoff pattern. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Hadfield, J., et al. “How we built our multi-agent research system.” First-party engineering essay, Anthropic, June 2025, verified September 2026. Separate windows with condensed findings and filesystem artifacts behind lightweight references. https://www.anthropic.com/engineering/multi-agent-research-system
• boxpositron. “WithContext MCP Server.” Third-party implementation, MIT licence, v3.0.7 at review, verified September 2026. Project-scoped folders against cross-contamination. Implementation evidence only; folder scoping never claimed sufficient. https://github.com/boxpositron/with-context-mcp