Did your agent do what it was told?

You wrote the rule down. It loaded. The agent broke it anyway, and said nothing.

Somehow it's more annoying when agents do this than when people do – even though people break rules constantly. Someone follows the old SOP you retired last quarter. Someone reads "avoid" as "prefer" and does it anyway, with a reason. Someone fixes the one example you pointed at instead of the class it stood for. Someone does it the way they have always done it, and not the newer, better way they were asked to do it.

But unlike agents, the person who gets pulled up on it has a short, uncomfortable conversation, and the rule changes status. It stops being a line in a document and becomes a thing somebody minds about. They may not remember the wording. They will remember that it matters.

That is not memory and it is not comprehension. It is stake. People follow most rules because someone will notice if they don't, and that knowledge becomes its own type of unspoken enforcement. Nobody wrote that mechanism down, because nobody ever had to.

Agents have no stake. There is no conversation, no next time, and nobody the agent minds disappointing. No matter how intensely or frequently you express anger towards an agent, it won't affect its behaviour one jot. It won't follow a rule to avoid provoking your anger, for example.

So a rule can be loaded, correct, unambiguous and sitting in the context window, and still lose. And it's why the agent that followed your rule for the first 10 edits breaks it on the eleventh.

So every fix on this page is external: a lint, a pre-tool gate, a branch ruleset. You're not making the agent take the rule seriously. You're turning the rule into a condition that has to be met before the work can land.

What this register does

The instruction register names the 22 ways a rule fails between being written and being followed. Two can be refused outright. Twelve can be caught every time. Eight cannot be closed by anything available – and one whole stage of a rule's life closes nowhere at all. The register carries eight evidenced rows and 14 candidates; the hub's headline counts count evidenced rows only.

The register produces one working rule: write the check when you write the rule. A rule with no check is a wish, and this register tells you which wishes you are living on.

This is a technical page listing every row in the register and what it costs, what closes it (if anything). It sits under the hub. Its nearest neighbour is did it know what it needed to know? This register asks whether the agent obeyed. The context register asks whether what it obeyed with was true.

Many of the controls on this page are standard software engineering – rules files, lint, code review – and experienced engineers already run some of them.

What the register adds is the failure behind each control: which failures are prevented, which are only detected, and which ones nothing closes. This shows where your remaining gaps are.

The question this register asks

Did it do what it was told? The unit this register tests is a rule:

• "Never use em dashes."
• "Do not touch production."
• "Always write the down script with the migration."
• "Ask before creating a new file."

Each one has a life. It gets written in some form, it reaches the agent or it does not, it is read the way you meant it or another way, it survives the moment of action, and it either holds to the end of the session or decays. The register grades each failure by what it costs, by how silently it fails, and by whether anything can refuse it.

Most advice about this problem addresses only the first of five stages – how the rule gets written. Keep the rule file short. Remove contradictions. Put the important things at the top. All of that is true and it addresses six of these 22 rows. The rest happen after the file is perfect.

Underneath all of it sits one mechanical fact. An agent does not experience a rule as a constraint. A person meets a rule as a social fact – it comes with an author, an expectation and somebody who will mind.

An agent meets it as text in a context window, competing with every other token there: your request, the file it just read, its own prior output, and whatever its training says the conventional answer is. A rule is not a boundary the agent runs into. It is evidence the agent weighs. That is why a rule can be loaded, correct, unambiguous and present, and still lose.

Why re-stating the rule changes nothing

One property decides where this register's controls have to live. Failure class is a property of the mechanism, not of the rule.

Re-stating a rule, loading it automatically, re-injecting it after compaction – all of these change how often it is broken. None of them changes what happens when an agent ignores it.

That distinction is why three rows on this register that look like solved problems are not. Automatic rule-file loading, re-injection after compaction, and hierarchy inheritance into subagents are genuinely useful delivery controls, and all three read Class C (the class where nothing closes), because delivery is not enforcement. Only a mechanism that refuses the prohibited action counts as prevention.

The practical test is one question: if the agent decided to ignore this, what would stop it? If the answer is "the rule says not to", the row is Class C – survives: nothing catches it every time, so it reaches you, however well the rule is written.

This is also why the catch-point distribution reads the way it does. Six rows are catchable before the session starts, three before the change lands, three while the session is running – the only register of the six with a non-zero middle – and 10 only afterwards.

Severity here is cost multiplied by how silently the breach fails. Five of the 22 are S4 (it ships and nobody finds out) and 10 are S3 (real cost, discovered late). Two are S1: a rule conflict nobody declared a winner for, and an instruction that was simply ambiguous. Both are cheap because you find out immediately – the agent does something defensible that you did not want.

How this register works

The instruction register lists 22 failures and grades them against a base install: an agent, a rule file, a repository and a CI pipeline. It names the strongest mechanism available against each. Whether any of them is actually switched on is a separate question, and one you answer against your own configuration. The whole catalogue is published on GitHub – clone it or download the zip.

The rows were derived by working through the life of a rule, stage by stage, and asking at each stage what could break it. Every register in this framework is built that way rather than from an incident log, because selecting for "we have seen this go wrong" filters out the failures that never announce themselves.

Only three of the 22 failures are recorded here with dated incidents; 19 have no incident recorded. That number is low for a reason this register is unusually honest about: an instruction failure only becomes visible if something checks the rule, and the rows with no check are precisely the ones that leave no trace. Eight rows have no complete remedy. By construction, those are the eight least likely to appear in anybody's defect log.

The life of a rule: five stages and an assurance band

Rows are grouped by how far a rule has travelled when it fails.

1. Written – does the rule exist in a followable form? Whether it exists outside a chat, whether a machine could check it, whether two rules conflict, and whether a retired rule still loads. Six rows.
2. Loaded – did the rule reach the agent at all? Whether the file was read this session, whether its scope applied, and whether it survived compaction. Three rows.
3. Understood – was it read as it was meant? Whether a prohibition was read as a preference – including an example read as the limit – and whether the instruction was ambiguous. Two rows. Nothing closes any of them.
4. Followed – did it survive the moment of action? Whether a clear rule was simply broken, whether a trained default won, and whether the agent acted before it had the state. Five rows. The only two preventions on the register live here.
5. Held – did it stay followed to the end? Whether compliance decayed across a long session, whether children received the rule, and whether a settled decision stayed settled. Three rows.

Cutting across all five is an assurance band, Checked – would you find out if it had not been? Three rows. Not a sixth stage. Each asks whether a breach would ever reach you, which is different from whether it happened.

The three classes: prevented, detected and survives

Every row carries one of three classes. The class describes how complete the available remedy is, not how serious the failure is.

1. Prevented – the failure cannot occur (two rows). Both live at the moment of action. A pre-tool gate that refuses a write to a file the agent has not read. Server-side branch protection that refuses the push a local hook would have missed. Note what they have in common: each refuses a specific action, and neither is a rule about behaviour.
2. Detected – it occurs and something catches it every time (12 rows). Mostly ordinary linting and CI: a size budget on the rule file, a custom lint for a rule written as prose, a touched-file diff scoped to the ticket, a byte-diff proving the generated rule file matches its inputs, artefact gates that catch a compliance claim with nothing behind it.
3. Survives – nothing catches it every time, so it reaches you (eight rows). Declared precedence between conflicting rules. Whether the rule file was read at all this session. Whether it survived compaction. Whether a prohibition was read as a prohibition. Whether an example was the class or the case. Whether the instruction was ambiguous. Whether a subagent received the rule. Whether a settled decision stayed settled. And whether a violation invisible in the output would ever be found.

So the score is two prevented, 12 detected, eight surviving.

Vocabulary: this register reads its three classes as prevented, detected and survives. Five of the six registers use these words, and the class letter means the same thing everywhere – how complete the remedy is. [A note on vocabulary] on the hub covers the exception, and the three things still unreconciled across the framework.

Now the finding, which is structural. Stage 3 – understood – is none prevented, none detected, two surviving. Every other stage on every other register in this framework has at least one row with a complete remedy. This one has none.

This is not a tooling gap that better software will close. The three questions are: was the prohibition read as a prohibition, was the example the class or the case, and was the instruction ambiguous? Each requires knowing what you meant, and comparing it to what the agent understood. There is no artefact to diff, because the failure happens between the words and the reading. A check can find weak wording; it cannot find a strong rule that was read weakly.

And this is the stage where the human comparison is revealing. A person who misreads your brief can be asked what they thought you meant, and the answer is usually informative. An agent will give you a fluent account of its reasoning that may bear no relation to what actually drove the output. The readback works on people. On an agent it produces more text.

The second-order consequence shapes where effort goes. Stage 1 – the stage every guide addresses – has five of six rows detected. Rule-file hygiene is close to a solved problem. The stages after it are not. No amount of work on the rule file reaches them.