How does an agentic operating system handle human approvals?

A held action is drafted in full and parked for a named person, who sees the proposal, the facts the agent relied on and the bound that caused the hold. They approve, edit or reject. On approval the platform checks again, because things may have changed while the action waited, and only then performs it. Every step is filed.

When does an action get held?

When the bounds allow the action to be prepared but not performed by the agent alone. Common triggers:

• The agent's depth for that capability is 2: it drafts and a person sends.
• The action exceeds one of the customer's limits, such as an amount or a daily total.
• The action relies on a fact from outside that cannot authorise it on its own, such as a new bank account in an email.
• The action is irreversible and the agent is not certified to depth 4 for it.

A held verdict is different from a refusal. A refusal means the action is outside the agent's bounds entirely; nothing is drafted for approval. A hold means the action is in scope but needs a person.

What does the approver see?

The quality of approvals depends on what the approver is shown. A good held item includes:

Approvers can edit before approving: change an amount, reword a letter. The record keeps both the agent's draft and the approved version.

What controls make approvals meaningful?

The approver must be entitled. The platform checks that the approver holds authority for that action and amount, just as it checks the agent.

The approver must be separate. Someone who asked for the action, or whose own account it affects, cannot approve it.

Re-check on release. Between drafting and approval, a balance may change or a certificate lapse. The platform evaluates the bounds again at release; if they now fail, the approval does not go through and the approver is told why.

Held items expire. An approval queue full of week-old payments is a risk. Items have deadlines and escalate when they pass.

Watch for rubber-stamping. Track how long approvers spend and how often they edit or reject. A queue where everything is approved in seconds is a queue where the control has stopped working.

What does this look like in practice?

Take an insurer's claims agent certified to depth 3 for settling small property claims within a limit. A claim comes in above the limit. The agent drafts a settlement and the platform holds it, naming the amount limit as the deciding bound.

A claims handler with authority at that level opens the item. They see the drafted settlement, the policy record, the loss adjuster's signed report, and the claimant's own photos marked as declared. They notice the adjuster's report predates a second claim for the same property, reduce the settlement and approve. At release, the platform re-checks; the policy is still in force and the handler's authority covers the reduced figure. The settlement goes. The record shows the draft, the edit, the approver and the re-check.

Why should approvals live in the platform, not each workflow?

If every workflow builds its own approval step, each will show different information, apply different authority rules and record outcomes differently. One approval mechanism in the platform gives consistency and one record. It also means every decision can be reconstructed the same way regardless of which agent or workflow raised it.

This is one of the clearest differences between an operating system and a framework; see agent framework or agentic operating system. The test questions are in the agentic operating system requirements checklist, and the full design is in the governed agentic operating system guide.