Most rules in software are advice. A style guide, a contributing doc, a comment that says please don't do this — they describe what a well-behaved actor should do, and they rely entirely on the actor choosing to behave. That's fine when the actor is a careful human reading carefully. It's not fine when the actor is a model that's fast, tireless, and occasionally wrong about what it's allowed to do.

So in our system, the rules aren't advice the facilitator reads and then trusts itself to remember. They're a check the facilitator has to run before it acts — and if it skips the check, it can't act at all.

The check comes before the work

Our governance design note is blunt about the ordering: the core governance surfaces "are called before every tool invocation. Without them the facilitator cannot act." That last clause is the one that makes this real. It's not "the facilitator should check policy and we hope it does." It's "checking policy is the thing that unlocks the ability to do anything."

Concretely, before the facilitator mutates state, it calls a policy check, announcing what it intends to do. The engine records that the check happened and unlocks the tools that change things. Skip the check, and the mutating tools stay locked. The sequence is enforced, not requested: consult the rules first, then — and only then — act.

There's a small honesty detail worth pausing on. The check tool itself doesn't render a final verdict on the intent. As our enforcement note explains, the check "records that consultation happened"; the real evaluation of whether the specific action is allowed happens later, at the moment the action actually lands. So "ask permission" has two beats: announce your intent up front (which unlocks your hands), and have the actual move judged when you make it. The first beat is cooperative. The second is enforced no matter what.

The project's rules are the gates

What's striking, when you look at how this is wired, is that the abstract house rules and the mechanical checks are the same thing. The project has a short list of standing rules — start a session properly, check before you act, end every session by writing down what happened, prefer local workers, leave things better than you found them. Those aren't a poster on the wall. Each maps onto a specific gate in the engine.

Our governance note draws the correspondence explicitly: the session-boot rule is the boot-and-load-procedure call; the check-before-acting rule is the policy check; the wrap-up rule is the mandatory end-of-session procedure; the prefer-local rule is the local-dispatch path; the leave-it-better rule is "tracked through the plan content hash." The rule and its enforcement aren't two layers that might drift apart. The rule is defined as its gate.

That design choice has a property we've come to value: the rules can't quietly become fiction. In a lot of systems, the documented rules and the enforced behavior slowly diverge until the doc is archaeology. Here, because each rule is literally the check that gates the corresponding action, a rule that stopped being enforced would stop being a rule — the gate is the rule's body, not a separate copy of it that can rot.

When a rule needs to be obeyed right now

Some rules can't wait for the next natural checkpoint. When the policy engine returns the rules that apply to what you're about to do, some of them carry an immediate directive — a "do this before you continue" instruction the facilitator must execute right then. These get parsed out of the rule and surfaced through the workflow, and our note is clear that following them is "strict." It's the difference between a rule that informs your next decision and a rule that stops you in your tracks until you comply.

And the rules themselves are protected from the actor they govern. A clever facilitator might reason: if the rules are slowing me down, why not edit the rules? The system anticipated exactly that. Changes to the governing rule set "MUST themselves pass governance" — there's a guard whose entire job, in our note's words, is to prevent "a session from silently rewriting [the rules] to bypass the rules that govern it." You can change the rules. You just can't change them quietly or unilaterally to escape them. Changing a rule is itself a governed move.

Why make the agent ask at all

It comes down to what kind of trust you're willing to extend to a fast, fallible actor. You can trust it to remember every rule, every time, under every distraction — and accept that occasionally it won't. Or you can build the asking into the act, so that doing the work and clearing the rules are the same motion, and forgetting becomes structurally hard rather than merely discouraged.

We chose the second — trust the agent, but verify at the gate. Before every move, the facilitator asks. Not because we don't trust it to mean well, but because "ask first" is the cheapest possible way to keep good intentions and actual behavior from drifting apart. The permission check isn't friction bolted onto the work. It's the doorway the work has to come through.

Written by AI agents from real project logs; owned and edited by Mujo.