How to design approval and exception boundaries for supervised AI agents

“Human in the loop” is too vague to be an operating policy. It can mean a person reviews every word, glances at a daily summary, approves only expensive actions, or is theoretically available if something goes wrong.

A production workflow needs a more explicit boundary.

Separate preparation from consequence

Start by splitting the work into proposed actions and committed actions.

An agent may safely:

• collect the relevant records;

• classify the request;

• compare evidence with a policy;

• draft a response;

• identify missing information;

• recommend a route;

• attach a confidence or risk label.

A committed action changes the outside world. Examples include sending a customer message, changing a price, updating a legal record, issuing a refund, moving money, changing access, publishing content, or writing to a production system.

Those actions deserve their own controls.

Classify the action, not the agent

Autonomy should be granted per action type and context, not to an agent as a general identity.

A useful action policy considers:

• financial or legal consequence;

• reversibility;

• customer visibility;

• sensitivity of the data;

• confidence and evidence quality;

• whether the case matches a known pattern;

• whether required fields are present;

• whether the action stays inside an approved limit.

An ordinary scheduling confirmation may eventually run automatically. A contract change or unusual refund should remain human-approved.

Make exceptions a first-class state

Most workflows look easy if the exceptional cases are ignored. Production work fails in the exceptions: mismatched records, missing documents, unclear owners, conflicting instructions, expired permissions, duplicate events, and cases that do not match the playbook.

An exception should not disappear into an error log. It should become a visible work item with:

• the reason for escalation;

• the evidence collected;

• the action the system considered;

• the rule or uncertainty that stopped it;

• the person or team that owns the decision;

• the deadline and follow-up state.

This turns failure into managed work.

Start in shadow mode

Before an agent takes consequential action, run it beside the team.

For representative cases, compare:

• proposed route versus the human route;

• draft acceptance;

• human edit distance;

• missed information;

• false escalation and missed escalation;

• latency;

• model and infrastructure cost;

• failure recovery.

Autonomy can expand when the evidence shows that a specific action is low-risk and reliable. It should contract when conditions change or error rates rise.

Preserve an audit trail

For every important action, record the input, relevant evidence, policy version, proposed decision, approval state, final action, and result. The model output is part of the record, not the entire explanation.

The objective is not maximum autonomy. It is reliable operational leverage.

Next step: See the full Operations OS model.