The method, in plain terms

Six levels describing what a company knows about its own work. L0, everything lives in people's heads. L1, a few people experiment on their own. L2, the work is written in a form a machine can follow. L3, the data is under control. L4 and L5 describe systems that adapt and learn on their own.

These are dependencies, not a schedule: you do not skip a level. The step from L1 to L2 is where most projects live or die, and it is where we spend the most time.

Two questions are enough to classify a workflow. Same input, same path every time? Fewer than twenty or so branches in the diagram? If so, it is fixed-flow automation: two to six weeks, a predictable cost, and behaviour you can test end to end.

If the path changes case by case and something has to be decided in an unpredictable context, it is a reasoning agent: two to four months, with an uncertainty no quote removes. Six or seven ideas out of ten fall in the first bucket. That is where the return comes fastest, and where we start.

What an agent does at each step comes down to seven moves: wait for a trigger, check, classify, enrich, produce, execute, ask. Decomposing a workflow means writing down which ones chain together and where a person decides.

The point is practical. Once the workflow is written as moves, you can see which steps are risky, which verify themselves automatically, and where to put the human approval. The diagram below shows a supplier invoice, from the file arriving to the accounting entry.

Five levels answering one question: who decides. Operator, the person does the work. Collaborator, the agent produces pieces. Consultant, the agent proposes and the person approves every time. Approver, the agent acts on low-risk cases. Observer, the agent acts alone and the person audits afterwards.

Every deployment starts as a consultant. Moving to approver is conditional: thirty days above 95% accuracy, and only on low-risk actions. Irreversible actions never become observer, and the list is written into the contract.

We build one agent per workflow. On tasks nothing verifies automatically, every added agent is one more place where an error slips in silently, then propagates to the next agents, which treat it as valid input.

An analysis published in May 2026 measured a 17x error amplification between multi-agent and single-agent systems on the same task. Multi-agent architectures still make sense when every result verifies itself without a human, like a mathematical proof or a passing test. Your invoices and client emails do not verify like that.

An agent that works in a demo and an agent still working six months later are two different objects. The second has recovery points, memory separated from working context, a written list of what it may do, explicit failure handling, and an isolated environment with limited access to your tools.

These five are not options. A deployment missing one will hold for the length of the demonstration, then drift without anyone noticing.

An automation produces nothing by itself. It frees hours, and those hours have to go somewhere: task, time saved, usable capacity, reassignment, result. If the chain breaks at reassignment, the hours dissolve into email and the return stays at zero.

Second question, more awkward: who still does this work the old way, in parallel? The shadow process is the most common cause of a measured gain of zero.

Then the J-curve. For two or three months, a deployment that works and one that fails look the same from the outside: extra costs, no visible effect. So we set leading indicators before spending, and stop at week eight if they have not moved.