Distractor Interference

The last two lessons were about irrelevant context. This one is worse: context that is relevant, and still hurts.

Why this, for you: this is the trap behind every "comprehensive" instruction file. You add a related rule to be thorough — and lower compliance on the rule that actually applies. Once you see why proximity causes interference, you'll prune instruction files instead of padding them.

The instinct: cover all cases. Make the instruction file comprehensive so nothing is missed. Include every rule that might be relevant. It feels like a safety net. It is a distractor field.

1 What it looks like

A prompt for writing integration tests includes instructions on unit-testing conventions, component-testing patterns, and end-to-end structure — all accurate, all in the same domain, only one applicable. The model attends to all three. The applicable instruction now competes with two related-but-wrong ones, and compliance on it is lower than if they were absent.

Semantically related but inapplicable instructions actively reduce compliance with the instruction that applies. Proximity in meaning creates interference, not safety.

2 Why it happens

Shi et al. (2023) showed model reasoning accuracy drops sharply when irrelevant but domain-coherent content is added to the prompt. The same finite-attention pressure from the infinite context applies to instruction sets: a rule accurate-in-general but inapplicable-here is not neutral — it draws attention away from the rule that matters, and the effect scales with every inapplicable line you add.

3 The fix

The test for inclusion is not "is this correct?" — it's "does this improve output on this specific task?" Load task-scoped, prune the rest.

# organise by TASK, not by domain — load only what applies load on invoke skill content arrives only when the agent uses it prune before load drop the accurate-but-inapplicable rules modular files "integration-test-writing" ≠ "unit-test-writing" test by removal compliance low? remove unrelated rules, watch it rise

If removing unrelated instructions improves compliance, you've just confirmed distractor interference and found your fix in the same move.

When pruning goes too far

Over-pruning has its own failure mode. Strip adjacent instructions too aggressively and you under-inform the model on edge cases; mis-classify the task and you load the wrong set entirely — a broad fallback is a partial safety net. Genuinely cross-domain tasks need both files; cutting one causes real failures, not interference. The pattern works best for well-defined, bounded tasks.

↪ Your win: relevance is not the bar

"Related" is not "applicable" — adjacent rules compete for attention.
Inclusion test: does it improve output on this task, not "is it correct?"
Organise instruction files by task, load on demand, prune the inapplicable.
Test by removal — compliance rising after a cut confirms the diagnosis.
Don't over-prune: cross-domain tasks and edge cases need their adjacent rules.

Retrieval practice — recall, don't peek

Question 1A related-but-inapplicable instruction is…

Question 2The right test for including a rule is…

Question 3You should organise instruction files by…

Question 4Over-pruning's main risk is that you…

Question 5 · spaced recall from Lesson 02The kitchen-sink session is fixed by…

Ask me anything. Want the "test by removal" loop written as a procedure, or how task-scoped loading also shrinks prompt-injection surface? Next, Part 2 opens with The Yes-Man Agent — the first of the behavioral failure modes.