Why AI speeds up individual tasks but not expert organisations

The task gets faster, the process does not

In expert work, the time spent performing a single step is rarely the bottleneck. The bottleneck is everything between the steps: waiting for someone to have time to look at it, the context switch when the author returns to the case three days later, the review round that waits for a meeting, and the handover from one person to the next along with the small loss that every handover produces. Speed up one step and leave the chain untouched, and the whole does not move. Ten hours of writing becomes two, but if there are three weeks of waiting and three review rounds around it, end-to-end time improves by a few per cent. Then there is what gets forgotten. The project manager does not have the whole picture, because the whole picture does not exist in any single place. Making one step faster does not fix this. A step that was in nobody's memory does not get faster. It goes missing. The second problem only appears at scale. When ten specialists do the same work, each of them has their own prompts. Prompts do get shared, and sharing them is a good habit, but it does not solve the problem. Each person has loaded the context of their own conversation themselves: different background material, different examples, different emphases. The same prompt in a different context produces a different result. So the variation does not come from someone prompting worse than the others. It comes from ten people running ten different processes that look identical from the outside. Which leads to the heart of the matter. The process has to belong to the whole unit, not to ten people's ten habits. As long as it lives in a person's head and a person's chat window, it is not the unit's process, however many people do it under the same name with the same tool. This is worth conceding plainly: individual prompting works. It just works at the wrong level. It optimises the part of the work that was never the constraint.

Three reasons the benefit does not compound

The gains cannot be added up

When everyone's improvement happens differently, the organisation does not have a process that is ten per cent better. It has three hundred different ways of doing the same work, some of which are now faster. Quality lives in the person rather than the process, and personal improvements do not sum into anything you can manage, measure, or promise a client.

Context is rebuilt by hand every single time

A language model produces good output when it is given good context: background, rules, and examples of what an acceptable result looks like. Assembling that context is human work, and it is redone from scratch on every run. It is counted nowhere, because it looks like doing the work rather than preparing it. The more demanding the task, the larger the share of time that goes into building context. Which is why the benefit is largest where the stakes are smallest.

Nobody owns the result

When a person changes roles or leaves, their way of working leaves with them. Nothing stayed in the organisation, because nothing was recorded anywhere except in one individual's habits. A year later, the next person starts over.

Your metrics measure adoption, not change

Most organisations track licence utilisation, active users, and a satisfaction score from a user survey. All three go up, and the report looks good. None of them measures what was being bought. They tell you the tool has been adopted. They say nothing about cycle time, capacity, variation in quality, or error rates. A licence is a receipt, not a change. Try this substitution instead: measure end-to-end time and its variation for one recurring assignment type, before and after. If the number does not move, utilisation is not an answer. It is a comfort.

What changes when the unit is a process, not a task

When an expert process is broken down into small enough parts, two things become visible that never show at the task level. First, a large share of the work needs no language model at all. When an expert process is broken down into implementable steps, there are typically between forty and sixty of them. In a measured example covering three workflows from one sales process, more than half of the steps were deterministic technical tasks: lookups, transformations, checks, and transfers that behave the same way every time. About 30 per cent were language model calls where interpretation is genuinely needed. The rest were human approval points. So in more than half of the steps there is nothing to hallucinate, because no model is involved at all. This matters for two reasons. The risk conversation changes, because risk is not spread evenly but concentrates in identifiable places. And the cost conversation changes, because the cheapest token is the one you never spend. Second, the bottleneck sits in the client's own calendar. From the same implementation, the measured split of human effort during specification was 80 per cent the client's own specialists, 10 per cent the external specifier, and 10 per cent the technical implementer. The client's share is 80 per cent because specification is the work of drawing out tacit knowledge, and that knowledge exists only in the people who actually know how the work is done. The first working version was coded by machine from the finished specification in roughly twenty hours. It was not finished, and it was not supposed to be. What follows is iteration, and the same asymmetry repeats there. A review session typically has one developer and between two and four of the client's specialists in it, so every shared hour consumes several times more of the client's time than of the developer's. There is no measured split for the iteration phase yet, but the structure is the same as in specification, and for the same reason: only the client can tell whether the process behaves as intended. So the bottleneck does not disappear when the build is finished. It moves. First the knowledge has to come out of people, then the judgement has to go back to them. Both findings point the same way. What decides the outcome happens before the first run.

Four questions you can answer yourselves

If two different specialists handle the same assignment, how far apart are the results? If the answer is "quite far", the problem is not the tool. How many steps are there in your most important recurring process? If you cannot say, it cannot be handed to a machine. Where in the process does someone approve something, and how do they know the result is acceptable? If the answer is experience, the acceptance criteria have never been written down. When your best practitioner retires, what is left? If the answer is a folder and a good memory, the knowledge has not moved anywhere yet. If more than two of these landed, you are at the point where the easy tools have been tried and found insufficient. That is the right place to be, not a failure. It is simply a different problem from the one the tools were solving.

What to do about it

The work is described precisely enough to hand to a machine: steps, data flows, acceptance criteria, human control points, and risk classification. The description is written in machine-readable form, and it stays with the organisation regardless of who eventually builds the implementation or on which platform. This work gets done either way. The only question is whether it is done deliberately up front, or expensively during implementation, where every ambiguity surfaces only once someone is building on top of it. For more on what spec-first means in practice and what an implementable specification contains, see our Insights section.

Next step

Start with a 30-minute discovery conversation. We identify where your expert work concentrates and assess which process is worth starting from. No implementation commitment.