Automation and Augmentation
Whether a system replaces a task or assists someone doing it, which determines almost everything about its effects and is decided by deployment rather than by the technology.
When not to use it
- As a binary where a deployment genuinely sits between, which many do and which is worth stating rather than forcing.
- To imply augmentation is harmless. It changes skill requirements, pace and error patterns, and it can degrade the judgement it depends on.
- Where the task itself is being redefined, in which case the prior question is what the task now is.
Reach for something else instead
- Task-level analysis — decompose a role into tasks and classify each, since most jobs are automated in parts rather than wholesale.
- Shared autonomy — an explicit division where the machine handles specified sub-tasks and the person supplies intent, which makes the boundary a design artefact rather than an emergent one.
- -
Further reading
- Brynjolfsson, Chandar & Chen (2025), Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence — the payroll evidence and the automation-augmentation split.
- Parasuraman & Riley (1997), Humans and Automation: Use, Misuse, Disuse, Abuse — what happens to the person left in the loop.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Treating the label a vendor uses as a description of the deployment.
- Assuming augmentation is the safe default, when unmeasured human review is a weak control.
- Reading employment effects from technology capability rather than from how organisations chose to deploy it.
At a glance
Where this sits
A starting point. Nothing needs to come before it.
Computed from the prerequisite graph, not assigned. How this works