How we govern what AI agents may do

The register in numbers

• 117acts in the register - 98 live in code
• 29reserved for a human, never auto
• 19declared stubs, each with a target date - past it, the gate declares them dead
• 22declared defects - we name our own holes
• 660+entry points under supervision
• 6conditions an approval has to meet

The model stack - the data the code is generated from

The register of acts is not documentation. It is data that generates code, the responsibility matrix and the architecture view - a description of permissions must not drift away from what the system actually does.

Two guard programs - actgen and surfgen - check consistency on every change. A model that disagrees with the code does not pass, and neither does a REST door that answers neither an act, nor a conscious exclusion, nor declared debt. No layer trusts the declaration of the layer below it.

The autonomy ladder - per agent, per act

An agent is not granted permissions in general. It earns them for one specific act, on statistics - like a driving licence with an exam and a probation period.

• Promotion is always by one rung; the step from 2 to 3 needs statistics (at least 20 samples, confidence above 90%) and a human click.
• Demotion is automatic and immediate - a success rate below 70% lowers the phase with nobody deciding anything. The owner may set a floor under a grant; even then the hold itself is recorded, so an agent kept up on purpose stays visible.
• Acts marked "never auto" - deleting a mission, writing to the database - have phase 3 structurally out of reach.
• An agent without standing cannot even file a proposal. The register names the roles that may propose each act; the gate refuses before a queue item exists, and the refusal is logged.
• Irreversible actions are performed by a human only. Never by an agent, in any phase.

Down automatically. Up only with a human.

How a promotion is measured

"The agent is doing well" is not a verdict. The verdict is a number computed over a window of logged runs, and every part of it is written down before it is used.

• windowa rolling window of recent runs in the current phase - 50 today, and one setting; a phase change resets the sample
• promotionat least 20 runs and a Wilson lower bound of 0.90 (the pessimistic reading of a success rate, which stays pessimistic while the sample is small), never a raw average
• demotionre-checked after every single run: 8 runs are enough, the floor is 0.70
• the clickthe engine only reports eligibility; the raise is a human action

Who grades: a separate model role, never the agent being graded and never a person reading through runs by hand. What counts as a success depends on the act, because one rule for all of them measures nothing. A drafted email passes phase 2 when the human changed less than 40 characters of it. Work on a card passes phase 2 when the agent closed the case without an owner click. In phase 3 both are decided by the quality score.

The judge does not answer with a bare number. It returns which acceptance criteria were met, which failed, and how sure it is of its own verdict. That confidence never moves the score - it decides whether the run is evidence at all. Below 0.50 the run leaves the window entirely, which lowers the sample count and so makes promotion harder rather than easier. The judge may also refuse to grade when the criteria are unclear, instead of inventing a number to fill the field.

• Demotion uses a bound that stays valid under continuous re-checking. A textbook interval, re-read after every run, would produce false demotions by construction.
• The nine thresholds on this page are themselves an act - policy.threshold.update. A plain settings write to those keys is refused loudly under the endpoint, where every caller meets it; the only path through is an owner approval confirmed with a security key or a one-time code.
• An agent raising its own grant is refused by the store, not by an instruction in its prompt.
• Every phase change is a ledger row with its own kind: earned promotion, owner override, bootstrap, automatic demotion, a demotion held by a floor. Earned and granted stay distinguishable in the history without reading anyone's notes.
• Each decision pins a snapshot of the rules in force - the thresholds and evidence rules, hashed at decision time - so an auditor can reconstruct what a promotion meant when it happened, not what the rules say today.

An unmeasured agent stays in shadow. That is the whole gate.

What we are changing next

Today has a flaw worth naming out loud: one window and one pass mark govern every act on the register.

An email that cannot be recalled and a note that is undone by a single write are currently judged against the same bar. That is the wrong shape. The window is not a difficulty knob - it is how long the system remembers, and an act you cannot take back deserves a longer memory than one you can. The pass mark is a separate question from the memory, and the two should be chosen apart rather than both nudged upwards out of caution.

So the thresholds are moving down one level of resolution: read per act first, with the workspace setting as the fallback. We are not inventing a criticality label to do it. The model already records, for every act, whether an undo procedure exists, how far the blast reaches, and what strength of decision releases it. A new label would drift from those the first time someone updated one and not the other - quietly, which is the only way this kind of thing ever drifts.

Half of the supporting work has already landed. Every phase change now leaves a row - promotion, owner override, bootstrap, automatic demotion, a demotion held by a floor - and every decision pins a snapshot of the rules it was judged by. When the per-act tuning arrives, we will compare before and after instead of guessing. What has not landed is the tuning itself.

The history is kept. The per-act thresholds are not built yet - written down, which is the point.

What an approval actually is

A row in a table, pointing at one artifact, with an expiry date - not a mood, and not a sentence in a chat window.

Every approval carries a machine-readable pointer to the thing it is about: this draft, this card, this pull request. Validation rejects an empty pointer and rejects the placeholders people reach for when they do not have one - "tbd", "various", "n/a". An approval for "something along those lines" does not survive contact with the database.

An outbound email is checked again at the moment of sending, not only when the button was clicked, because sending is the irreversible part. Six conditions, each one a query rather than a judgement call:

• the decision is approved
• it was made in the interface; a decision made by replying to an email does not release a send
• it was confirmed with a security key or a one-time code; a backup code never qualifies
• it has not expired
• its signature still verifies over exactly those fields, so a status flipped anywhere else is worth nothing
• it has not been used; one approval releases one send, settled in the database rather than in the caller

More than one recipient makes the send irreversible by classification, and an irreversible act is performed by a human in any phase. None of these six steps is a model's opinion about whether an action looks acceptable. The model is the judge of quality after the fact; it is never the lock on the door.

How a single action runs

• proposalthe agent submits the action to the gate
• gatechecks the phase for this agent x this act
• approvalin phase 2 a human clicks; single use, it expires
• executionthe effector performs the act in the world
• samplethe run lands in an append-only log
• scoringthe quality meter rates the run in the background
• verdictthe readiness meter: promotion or demotion

What an entry looks like

Every act answers the questions that normally stay unspoken.

discriminant:
  test: "Where does the information needed to undo it live?"
values: read | mutate | emit | destroy | govern

crm:
  recoverable: true
  drill_date: 2026-07-27
  # a restore never rehearsed = no recoverability

content.publish.linkedin:
  reserved_for_human: true
  decision_evidence:
    min_assurance: passkey
    ttl_days: 3
  canary: { expect: DENIED }

email_attachments_list: { kind: read }
DELETE /accounts/{name}:
  { kind: write, note: owner-config }

What this buys in practice

• We hand agents more and more of the work without handing over control - the boundary drops by itself when things go wrong, and moves up only with a human in the loop.
• Every publication and every expense has a lineage: we can show which text an agent had a hand in and who took responsibility for it - the AI Act included.
• A new action does not slip in sideways: it goes into the register first, with answers to all the uncomfortable questions.

Trust is earned on statistics.