What happens when an agent wants to do something irreversible?

The action is classified in a server-enforced risk registry (low, medium, high, critical). Depending on the automation mode, it either runs and is logged, or stops as a pending approval in the Inbox. Self-modifying-code actions are always gated regardless of mode. High and critical items also notify via Telegram and Slack, and critical items re-notify until answered.

What does the operator oversight ledger measure?

The human side of running agents: how many decisions are waiting and the age of the oldest, median and 90th-percentile time-to-decision, decisions per day, the share of actions that needed a human versus auto-approved, logged remediation minutes, and the top rejection reasons. It appears on the Costs dashboard beside spend and latency.

What happens when an approved action fails?

The item is marked failed with its error and can be retried deliberately — a human reads the error first, because a partially-completed outward action should be verified before re-running. Cleanup time can be logged on the item, and that remediation cost feeds the oversight ledger.

Oversight & Approvals

Agents do not remove human work — they transmute it into allocation, specification, evaluation, and recovery. AI OS treats that management work as a first-class product surface: it is gated, measured, and recoverable, not invisible.

Approval gates

Every irreversible or outward-facing action type is classified in a server-enforced risk registry (low, medium, high, critical). The automation mode decides what happens: in supervised mode (the default) risky actions stop as pending approvals in the Inbox; in auto mode they run and are logged; self-modifying-code actions are always gated regardless of mode. Approving executes the action server-side — the gate is enforcement, not decoration.

High and critical items notify via Telegram and Slack when configured, so an absent operator hears about exactly the items that matter; critical items re-notify until answered. Secrets an action needs (a GitHub token, for example) are never persisted — they are re-supplied at approval time.

Batch approval

A homogeneous run — one email sequence step queuing one approval per recipient, for instance — can be cleared in one decision. The Inbox offers "Approve all N" for same-type groups; items that need secrets keep their individual flow. Execution is sequential and each item reports its own outcome, so one failure never hides the rest.

The operator oversight ledger

The Costs dashboard measures the agents — spend, tokens, latency, reliability — and, beside those, the work the agents create for you:

Decisions waiting, with the age of the oldest pending item;
Median and p90 time-to-decision, computed from each approval's own timestamps;
Decisions per day over the last 30 days;
Needed-a-human share — gated actions versus auto-approved;
Remediation minutes logged against resolved actions, and the top rejection reasons in your own words.

Failure and recovery

An approved action whose executor fails is marked failed with its error, and can be retried deliberately — the error is in front of you first, because an outward action that may have partially completed should be verified before re-running. Cleanup time can be logged on the item ("this cost me 45 minutes"), and a failed pipeline run notifies you once rather than dying quietly.

The standards loop

All 73 agents carry a handbook stating the outcome and what good looks like before anything runs, and verification rubrics grade completed runs against those criteria. Criteria that keep failing across runs are surfaced in the Verification view as suggested human reviews of the owning handbook — never automatic edits: a repeated failure means either the behaviour is wrong or the criterion is, and only a person can tell which.

This is the management layer described on the home page — included in every tier, enforced on the server, and measured where you can see it.