Operate a Proven Workflow With Bounded AI Authority

Operate is the last stage for a reason. Automation should begin with work you understand, not work you hope an agent will discover on your behalf.

This guide is for a one-person operator who has already delivered the same business workflow successfully and repeatedly. You can name its input, customer or business outcome, stable steps, common exceptions, and quality check. If you cannot, return to Deliver and learn the workflow manually.

Your output is an operating procedure that gives AI bounded, reversible responsibility while keeping consequential authority human.

Entry evidence

Before changing the workflow, assemble repetition evidence from prior runs:

the same trigger began each run;
the required inputs were known;
the core sequence stayed substantially stable;
the output passed a defined quality check;
the intended business or customer outcome was delivered;
exceptions were recorded; and
a human approved consequential decisions.

Do not automate from one lucky success. “Repeated” does not require an arbitrary universal count; it requires enough completed runs for you to distinguish the normal path from exceptions. Record the runs that support your judgment.

Decision

Choose one proven workflow where bounded assistance can reduce delay, omission, or repetitive effort without transferring responsibility.

Prefer a workflow with:

a clear trigger;
structured inputs;
a visible end state;
reversible intermediate steps;
a modest failure cost;
a reliable quality check; and
an available human escalation path.

Do not begin with refunds, legal commitments, irreversible deletion, sensitive disclosures, pricing promises, unsupervised customer communication, or broad access to private systems.

Example format — adapt this to a workflow you have already run manually: Prepare a weekly internal exception list from sanitized task receipts for human review. AI collects and formats bounded records. A person decides which exception matters and what action follows.

Action

Write the SOP before granting authority.

1. Name the workflow and outcome

Use a business sentence, not a tool sentence:

When [trigger] occurs, transform [approved inputs] into [business output] so that [customer or operating outcome] can happen, subject to [human approval].

If the description starts with installing or configuring a tool, you have not yet named the business workflow.

2. Define inputs and permissions

List each data source and the minimum access needed. Separate read, draft, write, send, approve, spend, publish, and delete permissions. Start with the least authority that can produce a useful draft or reversible action.

Document what the system is explicitly forbidden to read or change.

3. Encode the happy path

Write each step with:

input;
action;
expected output;
validation;
receipt; and
next step.

A receipt is visible evidence that the step completed: a status record, file hash, provider acceptance, bounded log entry, or review artifact. “No error appeared” is not a receipt.

4. Add cost and time bounds

Set maximum runtime, requests, items processed, and spend where applicable. Define what happens when a bound is reached. The correct default is stop and surface the exception, not continue indefinitely.

5. Define stop conditions

Stop before consequential action when:

an input is missing or outside the expected shape;
identity or permission cannot be confirmed;
the quality check fails;
the cost or time bound is reached;
an external provider returns an ambiguous result;
private information appears where it is not allowed; or
the workflow encounters an unclassified exception.

6. Retain human approval

Name the decision that remains human. Examples include publishing, sending a consequential message, accepting a scope change, spending money, issuing a refund, changing access, or deciding that an exception is safe.

The approval must be based on visible evidence, not a summary that hides the underlying state.

7. Design escalation and recovery

For every stop condition, state where the exception appears, what evidence is included, who decides, and how the workflow resumes or rolls back. Test recovery deliberately with synthetic inputs before relying on it.

Recovery may mean retrying one bounded step, returning to the last verified state, switching to manual delivery, or stopping the workflow entirely.

Run supervised trials

Operate the SOP with human review at every meaningful boundary. Compare each run with the manual baseline:

Did the correct trigger start it?
Were only approved inputs used?
Did each step produce a receipt?
Were bounds respected?
Did exceptions stop safely?
Did the human approval occur before consequential action?
Did the business or customer outcome remain intact?

Record failures as design information. Do not hide them to make the automation appear mature.

What AI can help with

AI can classify bounded inputs, draft routine outputs, execute reversible steps, maintain state, monitor receipts, compare results with a checklist, and surface exceptions. It can also help turn repeated delivery notes into candidate SOP steps.

Its role should be specific enough that you can tell when it exceeded authority.

What AI must not decide

AI must not decide its own permissions, expand scope, reinterpret a customer promise, approve a consequential action, conceal a failed step, or treat missing evidence as success. It must not convert access into authority merely because a tool technically permits the action.

The human operator owns outcome definition, permission grants, approvals, exception judgment, and shutdown.

Completion signal

Operate is complete for this workflow when repeated supervised runs show:

the proven business workflow still creates its intended outcome;
every material step has visible evidence;
permissions and costs remain bounded;
consequential actions require human approval;
exceptions escalate clearly; and
a tested recovery path returns the work to a known state or stops safely.

Only then consider reducing review on low-risk reversible steps. Keep the proof visible. Autonomy without receipts is not an operation; it is an assumption.