When 'Always' Means Always: The Implied Clause in Your Agent Rules
Last week I watched an agent read a file, then run the test suite. Edit a line, run the suite. Add an import, run the suite. Rename a variable, run the suite. Every single step — no matter how trivial, no matter whether it had anything to do with tests — ended with the full Pest run kicking off. It was maddening to watch, and it was slow, and it was entirely my fault.
I’d put one line in our AGENTS.md:
## Testing
- ALWAYS add `--tia` to `pest`.
--tia is the flag we wanted appended to our Pest runs — narrow the run to the tests a change actually touches instead of grinding the whole suite. Reasonable intent. Terrible rule.
Because read that line again, the way a computer reads it. Not “when you run Pest, add --tia.” Just: ALWAYS add --tia to pest. There’s no trigger. No condition. The most emphatic word in the sentence — ALWAYS — is a standing order with nothing scoping it. So the agent did the most literal possible thing: it treated “run pest --tia” as an action to perform always, i.e. after every step it took.
The clause I didn’t write
When a human engineer reads “always add --tia to pest,” they silently fill in the missing half of the sentence: “…on the occasions when you’re already running Pest.“ Nobody reads it as “run Pest constantly.” The implied condition is so obvious to us that we don’t even notice we’re supplying it.
That filling-in is pragmatics — the part of language that lives in shared context rather than in the words themselves. Humans are relentless at it. We hear “always wear your seatbelt” and don’t strap in on the sofa. We hear “always salt the pasta water” and don’t salt water we’re not boiling. The condition (when driving, when boiling pasta) is understood, so we drop it.
An agent doesn’t share that context, and it won’t invent the missing clause for you. It takes the sentence you actually wrote.
A rule with an implied condition is a rule with a bug. The human reader patches it silently every time. The agent runs it as written.
The peanut-butter-sandwich test
There’s a classic exercise for exactly this — you’ve probably seen the viral version, where a kid writes out the steps to make a peanut butter sandwich and a parent follows them with aggressive literalness. “Put the peanut butter on the bread” → jar, unopened, plopped on top of the loaf. The whole point is to make you feel how much you assumed: that the jar gets opened, that “bread” means a slice not the bag, that “on” means spread not balanced.
In autism care, the underlying idea has a name: task analysis — you break a skill into its smallest discrete steps precisely because a learner may not supply the connective tissue between them. What the sandwich game demonstrates so well is how much connective tissue we leave out without noticing, because we’re used to an audience that fills it in for free.
An agent is the literal parent in that game, every time. My --tia rule was a step in a task analysis with the condition left out, and the agent did the equivalent of putting the closed jar on the loaf: technically compliant, obviously not what I meant.
The sandwich game is funny because the person is pretending not to infer. Your agent isn’t pretending.
Why ‘always’ and ‘never’ are traps
The instinct, when an agent keeps getting something wrong, is to turn up the emphasis. It skipped the flag twice, so you write ALWAYS. It touched a file it shouldn’t have, so you write NEVER. Caps, bold, exclamation points — we reach for intensity when what the rule actually lacks is scope.
ALWAYS and NEVER are unconditional by construction. They’re quantifiers over everything, and unless you bound them with a trigger, “everything” is exactly what the agent applies them to. My rule said always, so it ran always. The word did precisely what it says on the tin. The failure wasn’t that the agent was too literal — being literal is its job. The failure was that I wrote an unconditional instruction for a conditional situation.
The tell, in hindsight, was over-triggering. When a behavior fires in situations that make no sense — tests running after a no-op file read — the rule that drives it almost always has a missing or too-broad condition. Over-triggering is to agent rules what a memory leak is to code: a symptom that points straight at the line.
The fix is a conditional, not louder caps
The repair isn’t to soften ALWAYS. It’s to give it something to hang on. Rewrite the rule so the trigger is explicit and the action is subordinate to it:
## Testing
- When you run the test suite, invoke it as `pest --tia`, never bare `pest`.
Now the sentence has both halves. When you run the test suite is the condition; invoke it as pest --tia is the action. The agent only reaches the action once it’s already decided to run tests — which is the only time the rule was ever meant to apply. The over-triggering stopped the moment I shipped that edit.
The general shape:
Bad: ALWAYS <do X>.
Good: When <trigger>, <do X>.
Almost every “always/never” rule in an AGENTS.md is secretly a “when” rule with the when deleted. Put it back. “Always run the linter” → “before committing, run the linter.” “Never use git add -A” is fine as-is, because that one really is unconditional — there’s no context in which you want it. That’s the test: if you can’t name a situation where the rule shouldn’t fire, NEVER is honest. If you can, it isn’t, and you owe the rule a trigger.
What this actually taught me
The narrow lesson is “scope your rules.” The wider one is more useful.
Every instruction you give an agent is being read by something that will not fill in your blanks. It has no model of what you obviously meant, because “obviously” is a fact about your context, not about the text. So the words carry the entire load. If a condition matters, it has to be in the sentence. If a scope is implied, it has to be made explicit. The agent is a perfectly literal reader, and the entire skill of writing rules for it is learning to write sentences that survive a literal reading.
Write your rules for a reader who supplies zero charity. If the words say “always,” it will do it always.
The upside is that this makes debugging your own instructions tractable. When an agent does something bizarre, resist the urge to conclude it’s dumb. Go find the line, and read it the way it read it — flatly, no implied clauses, every ALWAYS meaning always. Nine times out of ten the behavior is a faithful execution of exactly what you wrote. Mine was. The agent wasn’t misbehaving. It was doing what I said, and what I said was ALWAYS.