Key takeaways
- Manual, assisted, and automated are operating models, not maturity levels.
- Manual work adapts cheaply to novelty but scales poorly and often hides state in personal queues.
- Automation improves consistency and visibility only when the process, controls, and evidence are designed with it.
- A hybrid process is often strongest: code moves the normal path while people own consequential judgment and exceptions.
- Compare correction cost and failure impact alongside time saved.
Compare three operating models, not two
| Dimension | Manual | Assisted | Automated |
|---|---|---|---|
| Novel cases | Adapts immediately if the operator understands them | Software prepares; person resolves | Must route outside the bounded path |
| Consistency | Varies by person, load, and interpretation | Stable checks with human judgment | Stable inside encoded rules and tested judgment |
| Capacity | Scales with trained attention | Removes preparation and coordination | Scales until dependency, exception, or control limits |
| Evidence | Often scattered unless deliberately recorded | System assembles; person confirms | Can record every state and effect if designed to |
| Change cost | Training and coordination | Instructions, tests, and interface | Versioning, tests, release, monitoring, and communication |
| Failure shape | Missed, inconsistent, or delayed work | Review burden or misplaced trust | Repeatable failure with potentially broad scope |
Choose by variability, consequence, and checkability
Keep work manual when legitimate cases differ so much that rules would be fiction, the policy is still moving, or the outcome cannot be checked promptly. Use assistance when inputs are messy but a person can verify a proposal. Automate a bounded path when inputs, rules, output, and exception destinations are stable enough to test.
The internal tool is the surface people may use in any of these models. A manual process can run through a simple case tracker. A fully automated background step may need no interface. Approvals and exception queues usually do.
| Situation | First move |
|---|---|
| Rare, high-novelty review | Document principles, owner, and evidence; keep judgment manual |
| Frequent data gathering | Automate collection and validation; keep the decision human |
| Stable reversible update | Automate with idempotency, verification, and exception routing |
| Consequential communication | Draft automatically; require accountable approval before sending |
| Unowned or disputed process | Resolve ownership and policy before building |
Design the exception model before changing the normal path
- 01Collect recent exceptionsHuman approvalUse actual missing, conflicting, duplicate, stale, urgent, and policy-edge cases.
- 02Classify the destinationCodeReject invalid input, request information, retry a transient step, reconcile an ambiguous effect, or create owned review work.
- 03Set a clock and ownerTriggerEvery exception has a visible state, responsible role, due time, and escalation.
- 04Return or closeHuman approvalState whether the resolved case returns to the normal path or closes with a different outcome and evidence.
Move through observe, assist, and bounded automation
Google's automation guidance describes automation as a force multiplier rather than a panacea. The same point governs transition: prove where the force is pointed before increasing it.
- 01BaselineHuman approvalMeasure volume, elapsed time, touches, corrections, exceptions, missed work, and harmful outcomes.
- 02ObserveAI judgmentGenerate a parallel recommendation without changing external state; inspect disagreements.
- 03AssistHuman approvalPrepare work automatically while the operator verifies each outcome and records corrections.
- 04Automate a safe subsetCodeRelease the stable, checkable, reversible path with strict scope and fallback.
- 05ReviewHuman approvalCompare clean completion, correction, exceptions, detection, recovery, and owner burden before expanding.
Limitations and when not to use this
- Manual work is not automatically uncontrolled, and automated work is not automatically consistent. Both depend on design, evidence, and ownership.
- A hybrid process can add review burden if the automated proposal is unreliable or the person cannot see enough evidence to verify it.
- Consequential and regulated decisions may require permanent human accountability regardless of technical capability.
Sources
- The Evolution of Automation at Google — Google Site Reliability Engineering Accessed 14 August 2026
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 14 August 2026
Assess the current process
Score its trigger, finish state, normal path, exceptions, observability, owner, and safety before changing the operating model.
Assess the current processUli 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.