[agent_invariant]

That’s exactly the mental split we’ve been leaning on.

The ledger part turned out to be more useful than we expected. Every freeze/reject event becomes a concrete example of where the agent tried to do something inadmissible, which is much more informative than hypothetical rule design.

On the governance layer: for us keeping the core extremely small and deterministic is proving interesting. The gate itself doesn’t try to understand intent or policy: it only enforces mechanical invariants like sequencing, replay resistance and bounded actions.

So when the agent evolves, we’re mostly not changing the kernel. What changes are the constraints around it (things like ceilings, roles, or context updates). That keeps the maintenance burden manageable because the core logic doesn’t grow with the agent’s complexity.

Early days though the real test will be how it behaves once the agents start doing more varied workflows.