Always-loaded is for rules the agent could break on any task

Line 41 of a payments company's CLAUDE.md reads: During a release freeze, do not merge to main without written approval from the release captain. It was added after a genuinely bad week in which two changes went out during a freeze and one of them had to be rolled back at two in the morning. Nobody on that team would call the rule unimportant. Over the following month the file was loaded into 214 agent sessions, and in 209 of them the agent was fixing a flaky test, renaming a column, writing a migration, chasing a memory leak, or doing one of the hundred other things that have no relationship to merging during a freeze. The rule was correct in all 214 sessions and relevant in five.

The file that line lives in is the team's agent configuration file, of the kind topic 12.7 described: a markdown file committed to the repository — CLAUDE.md for this team, AGENTS.md for others — that the coding agent reads in full at the start of every session, before it has been told what the task is. Reading it in full every time is what always-loaded means, and it is the property that makes the file's contents worth arguing about at all. The file exists because an agent begins each session with no memory of the last one, so without it somebody has to retype the build command, the test command and the rule about the analytics schema into every conversation, or accept that the agent will guess at them. What goes in is therefore a standing decision rather than a per-task one: a line added on a Monday is read by every session for as long as nobody removes it, on tasks nobody has thought of yet. You meet the file at the root of most repositories where a team uses a coding agent seriously, typically forty to two hundred lines long, with a commit history showing that it only ever grows.

That gap between correct and relevant is what decides whether something belongs in an always-loaded file. The test to apply is reach: could the agent violate this on almost any task it is given? An invariant — a rule about how the system is allowed to be wired, which has to hold whatever a particular change happens to be doing — such as the billing service never writes to the analytics schema passes, because almost any change to billing — a bug fix, a new endpoint, a refactor of the persistence layer, a performance patch — is a change that could quietly introduce the write. The freeze rule fails, because the agent can only violate it during a freeze, and a freeze is a narrow window that most sessions never touch.

Reach and importance are not the same measurement#

Importance is a property of the consequence: what happens if the rule is broken. Reach is a property of the surface: how many of the tasks you actually give the agent are ones where breaking it is possible. Teams reliably conflate them because the argument for adding a line is always phrased in terms of consequence — this cost us a rollback, this is a compliance requirement, this is how we lost a customer's trust — and consequence is the wrong axis for deciding the loading mechanism. High consequence tells you the rule needs to be enforced somewhere. It says nothing about whether the enforcement should be a sentence sitting in the context window of every session for the next two years.

Here is the same file's contents scored on reach rather than on importance. The counts come from sampling 200 consecutive agent sessions from the team's logs and asking, of each session's opening task description, whether the agent could plausibly have violated the entry while doing that work.

The 61 for the billing invariant is worth dwelling on, because it looks low next to 186 and 200, and someone in the review will use that to argue it should move out. Reach is not the same as a majority. The question is not does this fire on most sessions but is there a large class of ordinary work where the agent could break it without noticing, and 61 sessions of billing and shared-library work is exactly that class. The freeze rule's 5 is different in kind: those five sessions are identifiable in advance, because they are the sessions where somebody says the word "release". A rule whose applicability is announced by the request itself does not need to be present before the request arrives.

Estimating this does not require instrumentation. Most teams have the raw material sitting in shell history, in the agent's own session transcripts, or in the titles of the last fifty pull requests the agent contributed to. Pull the first user message from each recent session and read them as a list:

# Session transcripts land one JSONL file per session.
# Pull the first user turn from each and print it as a task list.
for f in ~/.claude/projects/*/[0-9a-f]*.jsonl; do
  jq -r 'select(.type=="user") | .message.content
         | if type=="array" then .[0].text else . end' "$f" 2>/dev/null \
  | head -1
done | sed 's/^/- /' | head -50

Reading fifty of those lines takes about ten minutes and settles arguments that otherwise run for a week. The list is boring in a useful way: fix the 500 on /v2/invoices when the customer has no default payment method, add a deleted_at index to subscriptions, why is the ingest worker OOMing after the 14:00 batch. Against a list like that, the freeze rule's irrelevance is not a matter of opinion, and neither is the seatbelt quality of *never commit .env*.

What the loaded line is competing with#

The reason low reach is a defect rather than a rounding error is that an always-loaded file is not free space. Topic 12.7 covered how these files get assembled and injected; the consequence for scoping is that everything in the file arrives before the agent has seen a single line of the code it has been asked to change, and it stays there for the whole session, competing for attention with the evidence the agent gathers along the way — file contents, test output, stack traces, the results of its own searches.

On a short session that competition is invisible. On a long one it is not. A debugging session that reads eleven files, runs the suite three times and pastes two stack traces will accumulate 40,000 to 70,000 tokens of task evidence, and every one of those tokens is directly about the problem. A freeze rule sitting in the prefix is not merely 28 tokens of waste; it is 28 tokens of confident, authoritative-sounding instruction that the model has no way to mark as inapplicable, sitting in the same window as the stack trace that actually explains the bug. Models are reasonably good at ignoring irrelevant instructions, which is precisely why the failure is hard to detect: nothing breaks, the file just gets longer, and the next person adds their own narrow rule with the same justification.

There is a second-order cost that shows up in review culture rather than in behaviour. Once a file contains a dozen entries that only apply to narrow situations, nobody can hold its contents in their head, so nobody can tell whether a proposed thirteenth entry contradicts the fourth. The file stops being read as a whole and starts being read as an append log, and at that point additions are approved on the merits of the sentence rather than on the merits of the file.

Apply the test before the wording argument#

The most common way this decision goes wrong is not that someone applies the reach test and gets the answer wrong. It is that nobody applies it at all, because the review immediately becomes an argument about phrasing. A pull request adds Always be careful with database migrations, someone objects that "be careful" is not actionable, three rounds of suggestions follow, and the entry merges as Migrations must be reversible; always include a down step and test it against a copy of staging. That is a better sentence. It is a better sentence in a file where it may not belong, and the twenty minutes spent improving it produced a strong feeling of diligence that makes rejecting it afterwards socially expensive.

Run the test first, in one line, out loud: how many of our last fifty tasks could have broken this? If the honest answer is four, the wording does not matter yet, because the entry is going somewhere else and its phrasing will be decided by whatever mechanism ends up carrying it. If the honest answer is thirty-eight, the wording argument is worth having and should be had properly, because a high-reach entry will be read thousands of times and ambiguity in it is expensive.

The migration example is a good illustration of how the test cuts across intuition. Migrations must be reversible sounds like a narrow rule about a narrow activity, and be careful with the payments code sounds like a broad rule about important code. The first has real reach in a repository where a third of tasks touch the schema, and it is specific enough that the agent can act on it. The second has reach on paper and none in practice, because there is no behaviour that "be careful" changes; the agent cannot be more careful, only more specific, and the entry does not say about what.

Where the test stops being useful#

Reach is a filter, not a decision procedure, and it is worth being precise about the three things it does not tell you.

It does not tell you the entry is true. A rule with reach on 190 of 200 sessions and a mistake in it is far more damaging than a narrow rule, because the agent will apply the mistake everywhere, consistently, and cite the file when asked why. Wide reach raises the cost of being wrong rather than lowering it, so an entry that clears the reach test earns more scrutiny of its content, not less.

It does not tell you the entry changes behaviour. A high-reach line that instructs the agent to do what it already does by default costs tokens on every session and buys nothing measurable. Write clear, maintainable code has perfect reach and no effect. Distinguishing entries that move behaviour from entries that merely describe good intentions requires measurement rather than judgement, and that measurement is chapter 4's subject.

And it does not tell you where the low-reach entries go. Rejecting the freeze rule from the always-loaded file is not the same as deciding what happens to it, and "elsewhere" is not one place. The freeze rule, the GraphQL regeneration command and a forty-line hotfix procedure all fail the reach test for the same reason and belong in three different destinations — and one of the four available destinations is nowhere at all, which is the hardest one to say out loud in a review. That sorting is what the next chapter does.