charles forson

How to keep one project's decisions from leaking into others

3 min read

Context engineering usually gets discussed as a packing problem: what do I put in the window, how do I keep it small, how do I retrieve the right chunk. The failure that actually cost me time was the opposite: something present in context that should never have applied where it did.

Here's what happened. On one project I'd concluded, for good reasons specific to that project's constraints, that we shouldn't build a particular dashboard. Reasonable call, correctly reasoned, written down. Later, on a completely unrelated piece of work, the agent surfaced that verdict and treated it as settled fact. "We decided not to build the dashboard." Except that decision was made under one project's constraints, and those constraints were not this project's. The conclusion had escaped its scope and was now steering a decision it had no standing to steer.

This is the real hazard in a system that shares knowledge across many projects, and it gets worse the better your retrieval is. Good retrieval surfaces relevant-looking prior conclusions everywhere. But a conclusion and the constraints that produced it travel separately. The sentence "we decided X" is portable. The three project-specific reasons that made X correct are not attached to it. So the verdict shows up in a new context wearing the authority of a settled decision, stripped of the conditions that were the entire basis for it.

The fix I use now is a single distinction: the map is global, the territory is scoped. The map is everything whose job is to be found from anywhere. Indexes, summaries, routers, the frontmatter that says what a file is about. That should surface across everything, because surfacing is the point of it. The territory is the conclusions. A build-versus-buy verdict, a tool choice, a "we decided not to." Those are binding only inside the scope they were decided for. Reading one from outside that scope makes it precedent, not instruction.

That word swap does the work. Precedent means: someone once decided this, under conditions you should go check, and if the conditions match you can lean on it. Instruction means: this is settled, act on it. Conflating the two is what let a scoped verdict act like a global rule. Now, when a conclusion surfaces from a scope that isn't the one I'm working in, the rule is to treat it as evidence rather than a decision, re-derive whether it actually applies here, and say so out loud: this verdict was scoped to that project, I'm re-checking before applying it. The other project's constraints are not this project's, and the burden is on me to prove they carry over, not to assume they do.

Mechanically I signal scope two ways. Location is the first: a conclusion living inside a project's own folder is scoped to that project by where it sits, and only the genuinely cross-cutting strategy lives at the top level where global rules belong. The second is an explicit scope field on shared research, defaulting to global but narrowable to a named project when a finding's conclusion really is bound to one project's situation even though the file sits in a shared corpus. The default matters: most findings are genuinely reusable, so global is the right default, and you narrow only when the conclusion truly depends on one project's constraints. Over-scoping everything defensively is its own failure, because then nothing is reusable and you've thrown away the point of a shared corpus.

The thing I'd want a hiring manager or a fellow practitioner to take from this: context engineering is not only about what you feed the model. It's about the metadata that governs whether a given piece of context is even allowed to apply to the task in front of it. A shared knowledge base without scope discipline doesn't get smarter as it grows. It gets more confidently wrong, because every project's local conclusions become ambient facts that leak sideways into decisions they were never reasoned for. The bigger the corpus, the more this bites. Keeping the map global and the territory scoped is what lets the thing scale without slowly poisoning itself.

Building the same things I write about — see what I'm working on in Projects, or get in touch.