A Rule You Have to Remember Gets Skipped
- My session instructions asked for an end-of-stage summary and never for a plan first, so every engagement had a 0% plan rate.
- The tool meant to catch that was never called and returned success every time, so I rebuilt it to fail and tied it to a stop hook.
- In my test, a ban on em dashes that lived only in the prompt cut them from six across five answers to two, so a check in code now catches what the prompt misses.
- Helper agents start with none of the session's instructions, so my content rules now live in one file installed in every workspace and compared byte for byte.
- A missing writing skill now stops a run instead of printing a warning, because a warning is ignored by definition.
I run many client projects at the same time, and AI agents do much of the work under my direction, inside a system I built called HALO. One rule in its design was skipped on every engagement, because the file the agents read for their instructions never asked for it. Another, a ban written into the instructions, worked only part of the time. This post covers both, and what I moved into code because of them.
I have built for the web since 1994. I also sell this kind of work, so read this as one practitioner's record of his own system as of 2026-10-08. It makes no claim about anyone else's.
My working test for any rule: if it only works while someone remembers it, it will fail at the moment that person is busiest. So for each rule I ask where it can run without anyone remembering it, and I build it there. That means a hook (a small program that runs at a set moment), a gate (a point that refuses to let work pass) or a module (a piece of code that does one job). A paragraph doing a hook's job is a gap.
The takeaway
When AI agents do the work, a rule in a document or a prompt is a request to them. The control is the code that can refuse work that breaks the rule.
Why did my plan-first rule fail on every project?
Until 2026-08-10, the file that tells each session what to do asked only for a summary at the end of a stage. It did not ask for the plan first. As a result, every one of my engagements had a 0% plan rate: none had a written plan before work started.
That file is the router file, the set of instructions a session reads to know what to do. A session is one agent working through a task, and a stage is one step of that task.
In HALO, every piece of work is meant to start with a written plan that a person can reject before the work begins. That rule was part of the design, but it was missing from the router file, the one place every session looks for its instructions. A rule can be settled in the design and still never reach the agents doing the work.
A summary comes after the stage is done. It tells a reviewer what happened. The plan is the part that comes first, and it was the part the router file left out.
What happens when nothing calls the check?
It reports success on work that broke the rule. I had a tool that checks whether each stage followed the plan-then-summary cycle: a plan before the work, a summary after it. The tool existed, and nothing called it. Across all six workspaces it reported zero cycle records and returned success every time, including one proposal run that went through ten stages and left eleven summaries and no plans.
A green result from a check that never runs looks the same as a green result from a check that ran and passed. From the outside, the two are identical.
On 2026-08-10, the same day the router file stopped asking only for a summary, I changed the check so that it can fail, and I tied it to a stop hook, which runs at the moment a session tries to close a stage. The hook runs the check, and if the stage has no plan, it refuses to let the stage end. Now a session cannot finish a stage that has no plan.
I also test the check itself, because a check that cannot fail only gives a green light.
How much does a rule in the prompt actually do?
A rule in the prompt cuts a problem down. It does not remove it. A prompt is the written instruction a model reads before it answers, and my rules about what a model may write started there. One was a ban on em dashes, the long dash.
In my test, that line in the instructions cut em dashes from six across five answers to two. Two is not zero. The ban was a rule, and I don't treat it as a preference, so I added a check in code that catches what the prompt misses. That check reads what the model wrote after the fact, so it doesn't depend on the model keeping the ban in mind. I wrote that lesson down on 2026-09-24.
The writer model gets the same treatment, and it is a separate model from the one that checks its work, for reasons I lay out in why I keep the writer away from the judge. On 2026-10-06 I made the writer receive the full humanizer skill on every run. The skill is a written list of the patterns that make text read as machine-written. If the skill is missing, the run now stops. Before, it printed a warning, and a warning is ignored by definition.
Why don't helper agents follow the rules I gave the main session?
A helper agent starts clean and inherits none of the session's instructions. A spawned helper is a second agent that the main session starts to handle part of a job. Whatever I told the main session, the helper never received.
So a rule that lives only in the message I send a helper is a rule the next helper never sees. Every handoff would have to repeat every rule, and a rule left out of one message is simply absent for that helper.
On 2026-08-28 I moved the content rules into one file. That file is installed into every workspace and compared byte for byte, meaning every character of each copy is checked against the original. Drift is what happens when copies of the same rules stop matching. A local edit counts as drift: the system reports it and overwrites it, so no workspace keeps a private version of the rules.
Keeping rules identical is one problem. Carrying what one project teaches to the others is a different one, and I cover it in how a lesson from one project reaches the rest.
How should you judge agent-written work before you trust it?
Ask to see a rule refuse something. When a rule runs in code, it shows up the moment it blocks work, and you can ask to watch that happen.
Here is a step you can take with any vendor or internal team that uses agents. Write down the rules your business cannot afford to have skipped, such as who approves work or which claims you are allowed to make in public. Next to each, have them name what enforces it and show you one case where it stopped work. Any rule whose answer is a document or a prompt is still a request to the agents, so treat the work it governs as unchecked.
Then ask whether that enforcement reaches every agent on the job, including helpers the main agent starts, and every copy of the rules. A check that covers the main session and nothing else leaves the rest of the work outside it.
These records show where my written rules failed and where I moved them. They don't show that every rule I care about now runs in code. The HALO manifesto lays out how the system works and which problems I have fixed so far.
Common questions
Should I stop writing instructions for my AI agents?
Keep writing them. A check can only test a rule that someone has defined, and the written instruction is where that definition lives. Write the rule down first, then decide whether it also needs code behind it.
What should I do when a rule I care about only lives in a document?
Review that part of the work by hand until the rule runs somewhere. Then ask whoever builds the system to move it into a check, starting with the rule whose failure would cost you the most.
What is HALO, and how do you work with companies?
HALO is a system I built and run for my own client work, and this post describes what it does today. I work with companies as a consultant or fractionally, never as a full-time hire.
Sources
If you want agent work whose important rules run as checks and gates, let's talk about building it.