Governed autonomy

Autonomy is a contract, not a switch

The question is never whether the AI can act. It is which actions, in which domain, up to what value, at what risk, reversible or not, within what window, on whose authority.

5 min readGoverned autonomy

Most products present AI autonomy as a toggle. On, and the assistant acts. Off, and it suggests. The toggle is easy to build and easy to explain, and it is the wrong shape for the decision it is asking you to make.

Nobody wants to answer "should the AI act". Everyone can answer "may it send this class of email to this segment, under this value ceiling, during business hours, reversibly, on my authority, until the end of the quarter". The second question is a contract. The first is a leap.

What you’ll learn

  • The seven dimensions authority actually varies along
  • Why a grant needs an expiry and a signature
  • What the never-autonomous list is for
  • How to write your first contract in twenty minutes

Seven dimensions, not one

Authority can be scoped by action, domain, value, risk, reversibility, time, and owner. Each one is a lever you would want independently, and collapsing them into a single switch throws away the ability to say the useful thing.

Action. Which verbs. Sending, scheduling, publishing, purchasing, modifying, deleting. Verb-level scoping is the difference between "may draft" and "may send", and that is usually the whole conversation.

Domain. Where. Marketing but not finance. This customer segment but not that one. Internal systems but not customer-facing ones.

Value. Up to what amount. A spend ceiling per action and per period, because a hundred small actions is a large action.

Risk. Up to what risk class. Risk is not the same as value — a low-cost action that touches a regulated process outranks an expensive but routine one.

Reversibility. Whether the action can be undone, and whether irreversibility alone requires a human. This single dimension does more safety work than any other, because it maps directly onto how bad a mistake can get.

Time. When, and until when. Quiet hours, business hours, and — critically — an expiry on the grant itself.

Owner. Whose authority is being exercised, which is what makes the audit trail meaningful rather than decorative.

Every consequential action is governed by an authority contract and is auditable. The contract is the object; the levels people talk about are just common presets over it.

Important: A system offering autonomy without an approval path, a record of what was done, and a way to undo is not offering autonomy. It is offering hope with a progress bar.

Grants expire, and that is the point

The subtle failure in delegation is not granting too much. It is granting once and never revisiting.

Autonomy grants are first-class signed, expiring, renewable records. Renewal is one click citing current metrics, and it is never automatic. Running missions finish under the grant they started with, while new actions require the current level.

Three properties fall out of that and each earns its complexity.

Signed. A grant names who gave it. Not "the system was configured this way" but "this person authorised this scope on this date".

Expiring. A grant that never lapses accumulates. Six months after a scope was widened for a one-off campaign, nobody remembers it is still open. Expiry converts that from a permanent risk into a scheduled decision.

Renewable with evidence. Renewal shows the current metrics for that scope — what it did, what got rejected, what was escalated — so the renewal decision is informed rather than reflexive. One click, but an informed click.

The "running missions finish under their starting grant" rule is there for a practical reason. Tightening a scope mid-flight would otherwise strand half-completed work in an unresolvable state, and stranded work is where the genuinely bad outcomes live.

The never list

Alongside what is permitted, a contract states what is permanently excluded. The never-autonomous list renders permanently, visible, not buried in a settings page.

This list is short and specific to each company. Common entries: terminating anyone, changing a price without human sign-off, signing anything, communicating with a regulator, moving money above a threshold to a new destination.

Writing the never list is uncomfortable in a productive way. It forces the conversation about which decisions are yours by definition rather than by current convenience, and that conversation is much better had in advance than during an incident.

Writing your first contract

Twenty minutes, on paper, before you configure anything.

Pick one domain where AI already drafts things and a person always sends them.
List the verbs in that domain. Circle the ones that are reversible within an hour.
For the circled verbs, write a value ceiling and a rate limit. Both, not either — rate limits catch what value ceilings miss.
Write the time window. Include quiet hours, and mean them.
Write three entries for the never list in this domain.
Set an expiry. Six weeks is usually right for a first grant, long enough to learn something and short enough to be a real decision.

You now have a contract that is more specific than most production configurations, and you wrote it before anything was at stake.

You choose how autonomous. The mechanism — contracts, grants, the never list, and the graduated halts behind them — is on autonomy, and the incident classes and published responses that sit behind it are on trust. If you want the presets rather than the primitives, the L0 to L7 ladder is the map.

The switch asks you to trust. The contract asks you to be specific. Specific is easier, and it survives the day something goes wrong.

Governed autonomyDeliver

Brainis Team

Notes on the company loop — company state, decisions, governed autonomy and verified work — from the people building Brainis and running on it.

Bring Brainis the company you want to build.

Start from an idea. Connect what exists. Either way, leave with the next move — and a system that delivers it.