On this page
Automation is often measured by how much of a process it removes from human hands. For routine work that is a reasonable goal. For work where a wrong action is expensive, public or hard to reverse, it is the wrong measure. A more useful question is whether each decision in the workflow is made by the right kind of actor: deterministic software, an AI model, or a person.
What deterministic automation does well
Rules-based software is excellent at work that can be fully specified. Scheduling a job at a given time, retrying a failed request with backoff, moving a record from one state to another when a condition is met, validating that a field has the right format — these are tasks where software is faster, cheaper and more consistent than any person.
The strength of deterministic automation is that it is predictable. Given the same input and state it does the same thing, and when it fails it can usually say exactly why. That predictability is what makes it safe to run unattended.
Where AI is useful
AI models are useful where the input is unstructured or the output is open-ended: drafting text from a brief, classifying incoming messages, summarising a document, extracting fields from a free-form email. These are tasks that rules handle poorly.
The same property that makes models useful also limits where they can act on their own. Their output is plausible rather than guaranteed. A draft can be well written and wrong. A classification can be confident and mistaken. That is acceptable when the output is a suggestion. It is a problem when the output is an action.
Where human judgment matters
Some decisions depend on context the system does not have: whether a message is appropriate for this customer this week, whether a payment looks unusual for reasons outside the data, whether a public post fits the organisation's current position. Others carry consequences that justify a second look even when the system is probably right.
A practical test is to ask, for each action in a workflow:
- Can it be undone cheaply if it is wrong?
- Is it visible to people outside the team?
- Does it move money, change access, or commit the organisation to something?
- Would a mistake be hard to explain afterwards?
If the answer to any of these is yes, the action is a candidate for an explicit human decision point.
Approval boundaries
An approval boundary is a place in the workflow where execution stops until a person decides. The important design choice is what exactly the person is approving.
Approving "the task" is weak. The content may change after approval, a model may regenerate it, or a later step may alter it. A stronger pattern is to approve a specific revision: this exact text, this exact recipient list, this exact amount. If anything about the revision changes, the approval no longer applies and the workflow has to stop again.
This sounds strict, but it is what makes approval meaningful. Without it, the person approving is signing off on something they have not actually seen.
Useful options at an approval boundary are usually few and explicit: approve, edit, regenerate, or skip. Each should be recorded, and each should leave the workflow in a clear state.
Auditability
When an automated workflow does something unexpected, the first question is what happened. An auditable workflow can answer it: which trigger started the run, which inputs it used, what the model produced, who approved which revision and when, and what was executed as a result.
This record is not only for incidents. It is how teams learn whether an automation is working. If people regularly edit or reject what the system proposes, that is information about the prompts, the rules or the data, and it is only visible if decisions are recorded.
Failure and retry behaviour
Human decision points change how failures should be handled. A retry that re-runs generation after approval may produce a different result from the one that was approved. A retry that re-sends a message may duplicate it.
A few rules keep this safe:
- Execution after approval uses the approved revision, never a regenerated one.
- Actions with external effects are idempotent where possible, or guarded so that a retry cannot repeat them.
- A workflow that cannot complete safely stops in a visible state rather than failing silently.
- Missed or delayed work is surfaced for a decision rather than executed late without anyone knowing.
The cost of the human step
Human-in-the-loop design is not free. Approvals add latency, and a queue that nobody reviews becomes a bottleneck. The answer is not to remove the boundary but to place it carefully: only where the consequences justify it, with enough context in front of the reviewer that the decision is quick, and with clear ownership of the queue.
Over time, some boundaries can move. If a category of action is approved without changes for long enough, and its consequences are low, it may be reasonable to let it run automatically. That should be a deliberate decision based on the audit record, not something that happens because the queue became inconvenient.
Conclusion
Automation maturity is not the absence of people from a process. It is a process in which routine work is handled by software, uncertain work is assisted by AI, and consequential decisions are made by someone who can see exactly what they are approving. A system that removes the human step from important decisions has not become more mature. It has only become less controlled.
- automation
- human in the loop
- approval workflows