The order of operations

Most conversations about AI at work start with capability. What can this model do? Which tool should we buy? Someone has seen a demo, or a competitor has announced something, and the question arrives already shaped around a product. I understand why. Capability is visible and exciting, and it is the part everyone can discuss without knowing the work in detail.

I have spent my working life on the other side of that question: physics first, then materials, then manufacturing, and lately data and AI on industrial problems. The longer I have done it, the more the useful question has moved from what a tool can do to what work we are actually trying to improve. The order in which you ask those two questions decides a lot of what happens afterwards.

Start with the work

A process on a production line does not care which software you have bought. It has inputs, outputs, tolerances, a cycle time and a set of ways it can go wrong. Before anyone changes it, the people responsible need to know what goes in, what comes out, what the constraints are, what depends on what, how it fails, and who has to act when it does. Manufacturing teaches this bluntly, because a bad decision produces scrap you can weigh.

Knowledge work is the same, only harder to see. A report, an approval, a customer reply and a design review all have inputs, outputs, dependencies and failure modes. They are less visible than a moulded part, so it is easier to skip writing them down. When the tool is chosen first, that step usually gets skipped, and the automation ends up attached to whichever part of the workflow happened to resemble the demo.

So the first job is to understand the work well enough to describe it to someone who has never done it: what arrives, what leaves, what has to be true for the output to be usable, and what a wrong output costs.

Tasks are not the same as decisions

Once the work is written down it stops looking like one activity. A job is a bundle of tasks and decisions, and the two behave differently.

Some parts of most jobs are transformations. They are bounded, repeatable and checkable, and you can say in advance what a correct result looks like:

• reformatting data from one shape into another
• retrieving the right document or record
• drafting the first version of something whose structure is known
• calculating a value from inputs that are already trusted
• comparing two things against a rule

Other parts are decisions, and the right answer depends on context the task description does not contain:

• working out what the situation actually is when it is ambiguous
• prioritising between things that all matter
• trading one good against another
• living with consequences that land on someone else
• being accountable for the result

The distinction matters because AI, and automation in general, is good at the first kind and much more dangerous on the second. A capability-first conversation blurs them. It asks whether the model can produce the output, when the question that matters is which kind of thing the output is.

Put judgment before automation

Can AI do this? For a bounded task the honest answer is usually yes, some of the time. The question that decides whether it should is different: what happens if the answer is wrong, incomplete, or right in general and wrong for this case?

Sometimes the answer is nothing much. A draft that misses the point costs a minute of rewriting. Sometimes a person will act on the output without checking, because checking would take as long as doing the work, and the consequence is real: a customer commitment, a safety margin, a financial figure, a design that goes to production.

That question is where human judgment belongs in the sequence, before any decision about automation rather than as a review step added afterwards. It is the decision about which tasks can carry an occasional wrong answer and which cannot, and the model cannot make it, because the model does not know what the output is for.

It is also why verification gets more important as generation gets cheaper. When producing an answer costs almost nothing, the scarce skill is knowing what to check and who is responsible for checking it. That was true of simulations before it was true of language models.

Then decide where AI helps

With the work understood and the tasks separated from the decisions, the places where AI reduces friction become fairly obvious. They are usually the bounded, checkable tasks: summarising material a person would otherwise read in full, structuring inputs that arrive in inconsistent forms, retrieving the relevant precedent, generating options for a person to choose between, finding patterns across more cases than anyone could hold in their head, drafting, and supporting an analysis that a person then owns.

Each of those leaves a person in the position of deciding, with better material than before. AI helps most where it changes the quality of what someone has in front of them when they make the call, and least where it is asked to make the call itself.

I try not to attach numbers to this. The improvement depends entirely on the work, and claiming a percentage before understanding the process is the capability-first mistake again, wearing a spreadsheet.

Tool choice comes last

Only at this point does the tool question make sense, and by then it is often a different question from the one people expected. Once the task is clear, the right answer might be a language model. It might be computer vision, classical automation, a deterministic script, a database query, or a rule a person already knows and simply needs enforced. Sometimes it is an agent with the checks designed around it. Sometimes it is no AI at all, because the problem was a process problem and the process is now fixed.

Engineering taught me that the tool is only ever one component of a system. The material, the machine, the software, the data and the people around it all constrain what the tool can do, and most of the real problems live in the joints between them. Choosing the tool first means choosing a component before knowing the system it has to fit.

The sequence I now use

Understand the work. Identify the tasks and the decisions inside it. Apply human judgment to which of those can tolerate a wrong answer. Decide where AI helps. Then, and only then, choose tools.

Its value is mostly in the order, and in the discipline of not skipping ahead when a capable tool is sitting right there. I still find that hard. The demo is always more interesting than the process map. But every time I have skipped the early steps, the work has reminded me that it existed before the tool did, and that it will still be there after the tool has moved on.