Morgan runs AP at Larkspur Promotional, a fictional supplier, and has spent three weeks watching an AI workflow propose invoice matches that nobody acts on. On Thursday a colleague walks past Morgan's desk and says, with real warmth, "The invoice thing is basically approved, right? Finance loved the demo." Morgan asks who in finance. The colleague thinks it was someone in the meeting. Possibly the person who left early.
By Friday, "basically approved" has been repeated in two standups and a hallway, and a third person has asked when it starts posting bills. Nobody has read a single proposed match except Morgan. Nobody has agreed what "posting bills" would require. The workflow has been promoted entirely by word of mouth, which is the one approval route that never shows up in an audit log.
Move an AI workflow from drafts to live actions only when a named owner has checked representative cases, critical fields, exception routing, permissions, and a recovery plan. Expand one bounded action at a time. A workflow that writes good summaries has not shown it can post a bill or promise a ship date.
This checklist turns Morgan's hallway phrase into decisions that have names attached to them. It treats a safe stop as part of a working rollout, and it treats missing information as something to resolve rather than a reason for the workflow to improvise.
The three stages, and what moves a workflow between them
Trelium's documentation on human review describes three kinds of work inside a workflow: steps the agent does alone, steps the agent prepares for a person to approve, and steps a person does by hand. It recommends starting with approvals around most steps and loosening them only after the agent has handled real exceptions well. A rollout is the process of moving individual steps between those groups on purpose, with evidence.
Drafts only
The workflow reads source documents and proposes an action. Nothing it produces changes a business record. A person compares each proposal with the evidence and records whether it was right.
Approved actions
The workflow prepares a specific action and waits. A reviewer approves, rejects, or asks for details, and only an approved action runs. Consequential steps such as money, customer promises, inventory, and production stay here.
Limited autonomy
One narrow, low consequence action runs without a per item approval, inside written limits. Everything outside those limits still goes to review or to a person.
Each move between stages is a separate decision with its own owner and evidence. Passing stage one for invoice matching doesn't authorize stage three for bill posting, even if it's the same workflow and the same week.
Write the boundary before anyone tests anything
Write down what the agent may read, what it may prepare, and what it may change. Name the systems, records, and transaction types involved. For Morgan's invoice workflow, the first boundary allows reading an approved AP inbox and PO records and preparing a proposed match. It excludes posting bills, changing bank details, and writing to suppliers.
That boundary matters even if the software could do more. What a tool can do and what it's authorized to do are separate questions, and the second one belongs to people.
Name the business owner who can approve a wider scope, and include the IT or finance owner when an action touches their systems or controls. A good test result should never quietly turn into permission for a new category of work. That's how "basically approved" happens.
Run a comparison stage first
Run representative inputs through the workflow while its output can't affect production. Compare each result with an answer someone has checked independently.
Pick cases by what it costs to get them wrong, not by how common they are. Include ordinary invoices, incomplete ones, duplicate messages, revised documents, extra charges, unfamiliar supplier names, and a system that times out.
Record each mistake precisely. "Failed invoice" tells you nothing. "Matched the product lines but left out the freight charge" tells you which rule needs work. Don't turn a small, clean sample into an accuracy claim either. Report how many cases you ran, what kinds they were, and which parts of the workflow you actually checked.
Make review a real control, not a rubber stamp
A reviewer needs the source document, the relevant record, the differences found, and any uncertainty the workflow ran into. Without those, approval is a guess with a button attached.
The review step should let a person reject or correct a proposal without accidentally triggering the live action. Trelium's human review documentation shows a run waiting in Slack with Approve, Reject, and Ask for details, and shows an acknowledgment draft that stays unsent until someone acts. Creating a draft and releasing it are different actions, and your rollout plan should treat them that way. If the order or invoice changes after approval, the approval should be checked again before anything runs.
Measure how long review takes, not just how often proposals get approved. If a reviewer has to redo the whole task to decide whether the draft is safe, the workflow needs clearer evidence or a narrower job. Reviewers should also see the cases where the workflow correctly declined to act, because a safe stop on missing information is a valid result.
Agree on launch criteria before the launch meeting
Write down what must be true before the first live action, and get the owner to agree before anyone sees the final numbers. Criteria agreed after the results tend to bend toward the results.
Suggested criteria include correct handling of critical fields, dependable exception routing, complete run records, and a person who knows how to stop the workflow. Set thresholds by risk. A formatting slip in an internal summary and a wrong quantity entering production are different outcomes, so count them separately.
The NIST AI Risk Management Framework treats risk management as ongoing work across a system's life. In rollout terms, that means ownership and evaluation get defined before launch and stay in place afterward.
Add the practical checks people forget. The correct account is connected. Production differs from the test environment only in ways you've written down. The team receiving exceptions knows where they'll arrive and who picks them up.
A sample promotion record
Here's what Morgan's promotion record might look like for moving one step from stage two to stage three. It's an example of the shape, not a universal threshold or a claim that a small test proves production reliability.
| Item | What Morgan writes down |
|---|---|
| Step being promoted | Filing a checked invoice PDF to the matching PO record. Bill posting stays in approved actions. |
| Decision owner | AP manager, with the finance systems owner signing off on the record access. |
| Input classes tested | Clean matches, extra freight lines, revised invoices, duplicates, missing PO numbers, a supplier timeout. |
| Critical checks | Correct PO, correct supplier, no duplicate attachment, nothing filed when the match is uncertain. |
| Known limitations | One supplier's scanned invoices are still unreliable. Those stay in review. |
| Return to review if | A new invoice format appears, the integration changes, or an unexplained error occurs. |
| Stop procedure | Who disables the step, what happens to queued items, and how partially filed records are checked. |
Notice what stays behind. An invoice with a clean product match and an unexplained freight line remains in review. A posting timeout means checking the destination before any retry. Neither one counts as a successful autonomous completion.
Expand a narrow slice, then wait
A first live release can cover one transaction type, one supplier format, or one low consequence action. Morgan's workflow might file checked attachments on its own while still needing approval for every accounting entry. That's real progress without handing over every permission at once.
Agree on how long to observe and what evidence would justify the next step. Use real workload, including the conditions that usually cause exceptions. A date on the calendar doesn't prove readiness, and if volume is low, a quiet week is weak evidence.
The human review documentation puts the standard plainly: a step with no approval should be one you've already seen the agent get right many times. If you can't point to those cases, the step isn't ready to lose its approval.
Practice stopping before you need to
Before launch, walk through the stop procedure with the people who'd use it. Find out what happens to queued work, to actions already underway, and to records left half finished.
Keep a manual fallback the team can use during an outage. Record enough detail to tell whether an action completed before anyone replays it, so recovery doesn't create a duplicate order or send the same customer update twice.
Decide which events send a step back to review: a new document format, a changed integration, an unexplained error, or a revised business rule. Reducing the agent's responsibilities should be an ordinary adjustment, not a sign the project failed.
Rollout checklist
- The boundary lists what the workflow may read, prepare, and change, and what it may not.
- Each stage move has a named decision owner, plus IT or finance where their systems are involved.
- Comparison cases cover clean, incomplete, duplicate, revised, and failing inputs.
- Mistakes are recorded by the field or decision that went wrong.
- Reviewers see the source, the record, the differences, and any uncertainty.
- Rejecting or correcting a draft can't trigger the live action.
- Go-live criteria were written and agreed before the results came in.
- Critical errors are counted separately from cosmetic ones.
- The first live slice is narrow, and everything else stays in review.
- The stop procedure has been walked through, including queued and half finished work.
- Events that send a step back to review are written down.
Frequently asked questions
How long should an AI workflow stay in draft only mode?
Until the owner has seen enough representative work, including the cases that usually cause exceptions, to judge the specific step being promoted. There's no fixed number of days that makes a workflow safe. Low volume workflows may need longer to see enough variety.
What should a reviewer see before approving an AI agent's action?
The source document, the record the action will change, the differences the workflow found, and anything it was unsure about. If the reviewer has to rebuild the task from scratch to decide, the workflow needs to present clearer evidence or take on a narrower job.
Which steps should never run without human approval?
That's a business decision, but steps involving money, customer promises, inventory, and production are the usual starting candidates for approval. Trelium's human review documentation lists those as areas where a person makes the call. Loosen an approval only after seeing the agent handle that exact step well many times.
Does a successful pilot mean the workflow is ready for full autonomy?
No. A pilot shows the tested steps worked on the tested cases. Each additional action needs its own boundary, owner, and evidence, and higher consequence actions usually stay in approval longer.
What counts as a reason to pull a step back into review?
A new document format, a changed integration, an unexplained error, or a revised business rule are common triggers. Write the list down before launch so pulling back is routine rather than a debate.
No fixed number makes this safe
No sample size or accuracy percentage makes every workflow safe. The right release boundary depends on what a mistake costs, how varied the work is, how much review capacity you have, and whether you can actually stop and recover.
Morgan's Monday
On Monday Morgan sends a one page record to the AP manager and the finance systems owner. It names the step being promoted (filing checked attachments), the cases tested, the supplier whose scans still fail, and the three events that would pull the step back. The AP manager reads all of it, asks one question about duplicates, and signs.
Bill posting stays in approved actions. The colleague who said "basically approved" asks when it'll start posting bills, and Morgan sends a link to the record. It turns out "basically approved" was always a question. Now it has an answer with a name on it.
Anindo Neel Dutta
Member of GTM Staff
Get started
Ready to see Trelium in action?
Schedule a 30-minute conversation about the workflow you want Trelium to handle.
Book a Demo→
