Language models made a category of work suddenly automatable: reading a document, classifying a message, drafting a reply, extracting fields from an invoice. Work that needed a person five years ago now needs an API call and a prompt.
The constraint has moved. It used to be capability. It is now judgement — specifically, deciding which processes are worth automating at all.
Three questions, in order
Before automating anything, we ask the same three questions, and the order matters.
- Should this process exist? Roughly a fifth of the candidates we are shown should simply be removed. Automating them makes their removal harder later.
- Does it require judgement? If a human is genuinely making a decision, automate the work around the decision and leave the decision alone.
- What is the cost of being wrong? This determines the design more than anything else.
The cost of being wrong sets the architecture
A model that classifies support tickets at 94% accuracy is excellent. A model that approves refunds at 94% accuracy is a liability. Same accuracy, entirely different systems, because the consequence of the 6% is different.
In practice, this produces three designs:
- Low consequence, reversible: run automatically, sample for quality, log everything.
- Medium consequence: automate the work, route the output for a fast human confirmation, and measure how often the human disagrees.
- High consequence: automate only the preparation — gather, summarise, pre-fill — and leave the action with a person.
The goal is not to remove humans from the process. It is to remove the part of the process that was never using them well.
Deterministic first
A significant share of what gets proposed as an AI project is a rules problem in disguise. If the logic can be written as conditions, write it as conditions. It is cheaper, faster, testable, explainable and it does not drift. Save the probabilistic tools for genuinely unstructured input.
The strongest automations we have built are usually hybrids: a model to handle the unstructured part, deterministic rules around it to enforce the constraints, and a clear escalation path when the input falls outside what the system was designed for.
Measure the thing you claimed
Automation projects are unusually prone to declaring victory without evidence. If the justification was hours saved, instrument it: how many items processed, how many escalated, how many corrected afterwards, how much time the humans in the loop still spend. If those numbers are not being collected, the automation is a belief rather than a result.