Key takeaways
- Judge a candidate process by whether you can describe its exceptions, not by how many hours it eats. If you cannot write down what happens when the case is odd, the automation will not handle the odd case either.
- Pay for model judgment only where the work is genuinely open-ended. Every step that still needs a model at run time is a step nobody managed to pin down, and it costs more and varies more than the deterministic code beside it.
- Decide before you build which actions keep a human approval permanently. Irreversible steps and decisions about individuals should be designed with a gate that stays, not one you intend to remove once you trust the system.
- Measure exception rate, approval latency and time-to-detect a wrong run. The share of work that ran untouched flatters a process that is quietly doing the wrong thing at speed.
- Start with one process that runs weekly or more, is owned by a single person, and is cheap to get wrong while you learn what good approvals feel like.
What AI workflow automation is, and where the category stops
A workflow is any work with three properties: something sets it off, a known sequence follows, and a condition says it is finished. Approving a supplier invoice is a workflow. So is answering a ticket, onboarding a customer, or producing the Monday report. Automating one means the sequence runs without a person doing each step by hand, and that much is decades old.
The AI part means one thing only: at least one step is carried out by a model exercising judgment rather than by a rule somebody wrote in advance. Reading a document with no fixed layout. Deciding which of six categories a messy request belongs to. Drafting a reply that fits this situation rather than the average one.
That removes the constraint which has always limited automation in operations: you no longer have to enumerate every case before you start. It introduces a different one. A step that exercises judgment does not behave identically every time, so you must decide which parts of your process may vary and which may not.
| Category | Best at | Where it runs out |
|---|---|---|
| Flow builders and integration platforms | Moving a known record between known systems on a known trigger, cheaply and predictably. | Every branch must be specified in advance. Work arriving in many shapes becomes a flowchart nobody can maintain. |
| Robotic process automation | Driving a legacy application that offers machines no usable interface, by imitating clicks. | It automates the interface, not the decision, and a person still handles every exception. |
| A chat assistant | Helping one person finish one task faster, while they sit there. | Nothing happens when nobody is watching. The procedure stays in somebody's head. |
| AI workflow automation | Recurring processes with messy inputs, where a step needs reading, classifying or drafting, and some actions must stop for a person. | Heavier than a rule-based flow. With no genuine judgment in the process, it is an expensive route to the same result. |
How the mechanism works: one process, three performers
Underneath the marketing, these systems all do the same four things: watch for a trigger, gather the inputs, execute the steps, record what happened. The question worth asking is not whether a product does that, but who performs each individual step, because that sets the cost, the variance and the auditability of the whole process. There are only three possible performers.
| Kind of step | Performed by | What it costs | What it looks like |
|---|---|---|---|
| A fixed rule | Deterministic code | Almost nothing per run, identical every time, testable before it touches real work. | Look up the account, apply the tier the contract says, write the record, file the document. |
| Genuine judgment | A model | Money and variance on every run, forever. Worth paying where the input is truly open-ended. | Read a free-text request and decide which of six categories it belongs to. |
| An accountable decision | A named person | Somebody's attention, permanently. That is the point: a human is answerable. | Releasing a payment, sending something irreversible to a customer, acting on a decision about an individual. |
Two consequences follow, and teams usually meet them late. The middle row should shrink over time rather than be celebrated: every step still needing a model in production is a step nobody managed to pin down. The bottom row does not shrink at all. A permanent gate is not a training wheel you remove once confidence grows; it exists because someone must be on the hook, and confidence in the software has no bearing on that. The human-in-the-loop guide works through how to choose those gates.
The four stages a process moves through: learn, approve, codify, run
The old way to build an automation was to specify it first: write out every step and branch, build it, then discover the six cases you forgot. The alternative is to let the process be performed first and specified second. This is the model all-agents is built on, described in general terms because the sequence is useful whichever tool you choose.
- 01Work arrivesTriggerA schedule fires, an email lands, a record changes. During learning these are handled strictly one at a time: each run teaches something the next should already know, and nobody wants to supervise two at once. Work arriving mid-run queues rather than dropping.
- 02Learn: the first runs are performed, not programmedAI judgmentThe process is carried out with a full agent's flexibility while you watch. The real output is not the completed work but the record of how it was completed: the actual inputs, the path taken, the shape of the data at each step, and every correction you made.
- 03Approve: nothing irreversible happens without youHuman approvalBefore anything leaves the building — an email sent, a payment made, a write to an external system — the run stops and asks. During learning this is unconditional, and it does two jobs at once: it protects you from a system that does not yet know the job, and it produces the corrections that teach it.
- 04Decide it is ready: a judgment, not a counterHuman approvalNo number of clean runs makes a process ready. Two are plenty for a single-branch process; twenty are not enough if the expensive branch has yet to appear. The test is coverage: have the awkward cases turned up, and is the procedure precise enough for a new colleague to follow?
- 05Codify: a walk-through, not a silent compileAI judgmentThe system walks the process with you, step by step, using real data from the runs it has seen. This is where tacit knowledge surfaces, because a concrete case jogs what you never thought to write down. Where the examples are ambiguous it asks rather than guesses. You pin the steps that must stay agentic and the gates that must always stop for a person, and all of it is written back into the procedure document.
- 06Run: deterministic by default, gates where you put themCodeThe trigger fires and the process runs: fast, cheap, the same every time, handling many triggers at once now that there are no lessons left to keep in order. A model is called only where judgment is genuinely needed. Every run is recorded, so a result you doubt can be inspected rather than argued about.
- 07When reality moves, the loop reopensHuman approvalA supplier changes a form, an assumption quietly expires. A small change should become a proposed patch you confirm, checked against the runs you already accepted so the fix cannot break what worked. A large one should send the process back to supervised learning, while the work that failed still gets done.
The pattern in each of those moments is the same: the system proposes, a person reviews concrete options and decides. When evaluating tools, interrogate that division of labour. Ask what happens on run 200 when something changes, and who gets told.
When it is worth it, and when a checklist or plain code wins
Google's site reliability engineers have a useful test for which work deserves automating. They call it toil: work that is manual, repetitive, automatable, produces no enduring value, and grows in direct proportion to how well the business is doing. That last property makes it urgent rather than merely annoying. Not all toil belongs in this category, though, and two rows below are the most valuable because they tell you to spend nothing.
| If your process looks like this | The right answer | Why |
|---|---|---|
| It runs weekly or more, the inputs vary, and a person reads each case before acting. | A strong candidate. | The reading is the judgment, and there is enough repetition to repay pinning down everything around it. |
| High volume, but the rules are already clean and unambiguous. | Plain deterministic automation, with no model in it. | You would be paying for judgment you do not need. A script is cheaper, faster and easier to test. |
| It runs a handful of times a year. | A written checklist, and nothing else. | Specifying the process costs more than the process consumes. Write it down properly and move on. |
| It changes shape every month because the business is still working out how it should go. | Wait, and keep it manual. | You would be codifying a moving target and rebuilding it each time the target moves. |
| It is frequent and painful, but two experienced colleagues would handle the same case differently. | Settle the procedure first, then automate the settled version. | Automation inherits the ambiguity and applies it at speed. Decide which colleague is right first. |
| It is frequent and ends in one irreversible act: a payment, a message to a customer, a decision about a person. | Automate everything up to that act, and gate the act itself permanently. | Nearly all the time is in the preparation. Approving a fully assembled case takes seconds, and accountability stays where it belongs. |
If your process failed on the ambiguity row, a better tool will not save it. Start with the procedure guide instead.
Six process shapes that fit, across different functions
These are process shapes, not case studies: patterns that recur across small operating teams regardless of industry. What they share is a trigger you can name, inputs that arrive somewhere predictable, and a few decisions that repeat with variation. What differs is the last column, and it matters more than any product comparison — the share that must stay with a person decides how much of your week you get back.
| Process shape | What sets it off | Where judgment is needed | What stays with a person |
|---|---|---|---|
| Invoice exceptions (finance) | An invoice arrives that does not match its purchase order or the goods received. | Which kind of mismatch this is: price change, partial delivery, duplicate, wrong legal entity. | Releasing payment, and accepting any difference above the agreed tolerance. |
| Support triage (customer support) | A ticket or email lands in a shared queue. | What the customer is really asking for when they describe a symptom rather than a problem, and how urgent it is. | Anything that commits the company: a refund, a credit, a promise about a date. |
| Customer onboarding (operations) | A contract is signed or a plan is upgraded. | What the signed terms mean for setup when they deviate from the standard package. | The first thing the customer sees, until the process has earned the right to send it. |
| Lead enrichment and routing (sales) | A form submission, or a new record in the CRM. | Whether two records describe the same company, and whether a vague job title matches a segment. | Very little once the data is reliable, which makes this a good first process. |
| Recurring reporting (any function) | The first working day of the month, or every Monday at nine. | The commentary: which movements are worth explaining and which are noise. | Anything that leaves the company, and any number quoted externally. |
| Vendor review (procurement) | A renewal approaches, or someone proposes a new supplier. | Reading the terms against current usage and summarising what changed since the last review. | The renew, renegotiate or cancel decision, and signing anything. |
The finance shapes are worked through end to end in the finance and accounting playbooks, and the triage shape in the customer support section.
One process through all four stages
Abstractions are easy to agree with, so here is the onboarding shape carried the whole way through. Every number is illustrative, built to show the arithmetic of the decision rather than to report anyone's result.
The process. A three-person operations team onboards each new customer by hand: create the workspace, set seats and billing plan from the order form, add the customer domain to the access list, file the signed document, book the kickoff, send the welcome email. Call it forty minutes per customer, six to ten times a week.
Learn (runs 1 to 7). The first run takes longer than doing it by hand, which is normal and worth budgeting for. Run 3 hits an order form with a mid-term seat increase the standard package does not cover; the operator corrects the arithmetic and the correction goes into the procedure. Run 5 turns out to be a reseller buying for an end client, a branch nobody had documented. Runs 6 and 7 exercise nothing new, which is itself a signal.
Approve. Across those runs the operator approves twenty-one irreversible actions: seven welcome emails, seven billing writes, seven calendar invitations. Two drafts are rejected and rewritten before they go out, and those two rejections teach more than the nineteen approvals.
The readiness call. Both awkward branches have appeared and been handled cleanly, and the procedure now covers them. That, not the number seven, is the reason to move on.
Codify (a forty-minute walk-through). The system walks the procedure using real data from those runs. It asks what happens when the order form and the signed contract disagree; the answer, never written down before, is that the process stops and asks. The kickoff step surfaces a rule the operator had forgotten she applies: enterprise customers are booked with their named account manager. She pins the welcome email as a permanent gate.
Run. Seat arithmetic, workspace creation, access-list changes and filing are now plain deterministic code. One step calls a model: reading a non-standard order form. One stops for a person: the welcome email, which arrives drafted and takes a minute to release. Two weeks later a supplier changes the form layout and a run fails. A patch is proposed, checked against the seven stored runs so it cannot break what worked, and confirmed.
What changed. Operator time per customer falls from roughly forty minutes to roughly one. The real cost was not the software: it was seven supervised runs and a forty-minute walk-through, spent by the person who knows the process. An evaluation that ignores that cost is not an evaluation.
Risks, governance, and how to tell whether it is working
Three risks account for most of what goes wrong, and none is the one people worry about during a demo. The first is automation bias: once a system is usually right, approvals become reflexes, and a gate always approved in three seconds is decoration rather than control. The EU AI Act treats this explicitly — its human oversight requirements for high-risk systems say the design must counter over-reliance on system output, and that overseers need competence, training and real authority to intervene. Well outside high-risk territory that is a sound standard: a gate is only real if the person can say no and sometimes does.
The second is silent drift, where a codified process keeps running after the world underneath it has changed, producing confident output that is subtly wrong. That is why failure handling belongs in the design rather than the incident review, and it is the subject of the reliability guide.
The third is diffuse accountability. While a person did the work, who was answerable never came up. Write down, per process, who owns it, who approves at each gate and who is told when it fails. The NIST AI Risk Management Framework organises this well: its GOVERN function runs across every stage and calls for policies that define and differentiate human roles and responsibilities where people and automated systems work together. The governance guide turns that into something a small team can operate.
Measurement is where programmes quietly go wrong, because the obvious metric — the share of work that ran untouched — flatters a process doing the wrong thing at speed. Measure these instead, and capture the manual baseline before you automate, because it is unrecoverable afterwards.
- Exception rate. The share of runs that could not finish without a person. A rising rate is the earliest honest signal that reality has moved away from your procedure.
- Time to detect a wrong run. From the bad result being produced to somebody noticing. Shrinking this is worth more than shrinking the error rate.
- Approval latency. How long approvals sit unanswered. A gate nobody attends to is a queue, not a control.
- Change rate at the gate. How often an approver edits or rejects rather than waving through. If effectively never, either the process is settled or the gate has stopped working, and you need to know which.
- Cost and elapsed time per run, against that baseline, including the supervised runs and the walk-through.
One last thing about targets. Google's reliability engineers put it bluntly: 100% is the wrong reliability target for basically everything. The useful question is not whether your automated process will ever be wrong — it will, exactly as the person doing it now is occasionally wrong. It is what failure rate the process tolerates, how a failure gets detected, and what happens next.
Limitations and when not to use this
- This page is about business operations: the recurring, procedural work a small team does across everyday tools. It is not about automating software delivery, data pipelines or infrastructure, where the tooling and the economics differ.
- Nothing here is legal, financial or employment advice. Where the page touches a regulated subject it cites the primary source, but what applies to you depends on your jurisdiction, your industry and the decision being made. Processes that decide something significant about an individual carry obligations this page does not enumerate.
- The approach assumes a process that repeats with variation. Work whose value is the relationship rather than the procedure — a negotiation, a difficult conversation, a judgment depending on context nobody wrote down — should not be automated, and being repetitive is not an argument that it should.
- The costs land before the benefits. Supervised runs and a proper walk-through need hours from the person who knows the process, usually the busiest on the team. If nobody can commit that time, the project stalls whichever product you choose.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 24 July 2026
- Embracing Risk — Google, Site Reliability Engineering Accessed 24 July 2026
- Article 14: Human oversight — EU Artificial Intelligence Act Accessed 24 July 2026
- AI Risk Management Framework — NIST Accessed 24 July 2026
Test your first process against the numbers
Take the one process you had in mind while reading, and check whether its volume and handling time actually justify automating it before you shortlist a single tool.
Test your first process against the numbersUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.