There's a question that any honest builder of agent systems has to answer, and most don't ask out loud: what happens when the agent ignores the rule? Not maliciously, necessarily — an agent forgets, mis-reads its own state, or quietly takes the path of least resistance around a check it found inconvenient. If your whole governance story is "we told the agent the rules," then the answer to that question is "then the rule didn't happen," and your governance was theater.

We sat with that question and built our answer into the architecture. The short version: trust the agent to declare and cooperate where only it can — and verify on the server where the agent's cooperation can't be assumed. Neither half is enough alone. The composition is the design.

flowchart LR
    A[Agent] -->|soft: declares intent,
follows guidance| AUD[Audit-visible note
non-blocking]
    A -->|action| ENG[Engine gate at the chain]
    ENG -->|hard: rules met?| OK[Action lands]
    ENG -->|hard: deny verdict| NO[Blocked action
does not land]

Why you need both halves

The reason there are two layers, and not one, comes down to a single asymmetry our enforcement note names directly. The agent "is the only entity in the system with intent context." When an agent decides "I'm finished researching and moving to design," only the agent knows that. No server process can read that transition out of the air — it can't intuit a phase change from the agent's reasoning. As the note puts it, the engine "cannot evaluate context-dependent intents — it can only check structural properties of artifacts."

So for anything that hinges on intent, you have to let the agent declare it. There's no alternative. That's the soft layer: the agent invokes the system's surfaces, announces what it's doing, and is expected to follow the guidance it gets back.

But — and this is the other half — the note is equally blunt about the agent's limits: "the [agent] is stochastic. It forgets. It mis-states intent. It might be actively trying to route around a check. A system that trusts [agent] cooperation alone is one cooperative session away from silent governance failure."

That sentence is the whole motivation for the hard layer. "One cooperative session away from silent failure" means: the day the agent doesn't cooperate, a trust-only system has nothing left. So alongside the cooperative surfaces, the system runs server-side gates that fire whether or not the agent plays along. The note's formula for the whole thing is four words: "the [agent] declares; the engine verifies."

The soft layer and the hard layer, concretely

The soft layer is the agent cooperating with the system. It checks rules before it mutates. It loads the canonical body of a procedure and follows it. It declares a step finished and asks to advance. When a rule matches, its guidance surfaces and the agent is expected to honor it. The signal this layer produces is audit-visible but non-blocking — a recorded note that a rule applied.

The hard layer is the engine enforcing regardless. Our note lists where it fires: a gate runs at every attempt to write to the chain, evaluating whether the matched rules' conditions are met against the actual event — and on a serious enough rule, it blocks the write outright. Step-completions are validated against evidence that must actually exist on disk; no evidence, no advance. Inference calls themselves pass through a wrapper that evaluates policy and refuses on a deny verdict. And for one particular agent harness, there are pre-action hooks that catch path-aware violations the engine alone couldn't make. The signal this layer produces is the strong one: a deny, audit-visible and blocking. The note's line: "The blocked action does not land."

Five levels, so the seriousness is declared

What keeps this from being a blunt "allow or forbid" is that every rule declares how seriously it's enforced — one of five levels, from a quiet audit note up to a hard refusal at both layers. Our note lays them out: a level-1 rule just notes that it matched; level 2 surfaces guidance; level 3 records a deviation if the agent picks a different path but doesn't block; level 4 blocks when its conditions match; level 5 is the maximum — the engine refuses at both layers.

The point of the spectrum is that different rules genuinely want different ratios of trust to verification, and the note's worked examples make the spread vivid. Some rules are fundamentally soft: the "leave things better than you found them" rule depends on a judgment — "I hit a bug; is it in scope, or do I file it for later?" — that, as the note says, "is irreducibly context-bearing." No server can detect "you noticed a bug and silently moved on." Its value comes almost entirely from the agent reading it and applying judgment.

Other rules are fundamentally hard: a build-verification rule runs in a pre-commit hook that aborts the commit on failure, with — in the note's words — "no [agent] cooperation required." Surfacing it to the agent is a courtesy; the hook is what enforces it.

And the most interesting rules are genuinely both. The note's example is night-mode, where one cardinal rule is "never ask the user a question." The agent is supposed to load the procedure and follow it (soft) — but if it forgets, the engine projects the night-mode state into its checks and refuses the question-asking action at the gate (hard). The note's summary of that example is the thesis of the whole design: "the [agent] tries to follow the procedure (soft) AND the engine refuses violating actions (hard)."

The trap this design exists to avoid

There's a tempting shortcut that our note spends a whole section warning against, because the project actually fell into it once. The shortcut is a hardcoded gate that short-circuits before the real engine runs — a handful of rules, checked in fast custom code, that returns a verdict without going through the engine.

It seems efficient. It's a trap, for three reasons the note enumerates. It "silently drops every policy not in its handful" — the engine has well over a hundred rules; a four-rule shortcut means the rest can't fire on requests it intercepts. It "produces no chain event," so those denials leave no audit trail. And it "cannot use the engine's predicate vocabulary," so it falls back to crude substring-matching on text blobs, where false positives are guaranteed by construction. The fix wasn't to make the shortcut smarter. It was to delete it and route those rules' intent through the engine, so they compose, emit an audit record, and short-circuit cleanly — the hard enforcement living at the inference wrapper rather than buried in any one provider.

That episode is the whole philosophy in one bruise. You don't protect a system from a fallible agent by bolting a clever bypass in front of the rules. You protect it by making the rules real on the server — declared at the level of seriousness they deserve, fired whether or not the agent cooperates, and recorded either way.

So: what happens when the agent ignores the rule? For a soft rule, you get an honest audit note and the agent's judgment is what stands — by design, because only the agent had the context. For a hard rule, the action simply doesn't land, agent cooperation or not. That's the honest answer. Trust the agent where only the agent can judge. Verify at the gate everywhere else. And never pretend a rule you only told the agent about is a rule the system actually enforces.

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