Process first, then AI

When we talk about working together, I hear a similar picture of artificial intelligence: a tool you plug in that from then on runs by itself, makes no mistakes, works around the clock for a fraction of the current cost, needs nobody to check it, and gives the people in the company loads of free time back. I understand where that picture comes from, because demos of what models can do look exactly like that (one prompt, a few seconds and a finished result). In my experience, though, there is a lot of work between a demo like that and automation that really takes load off people, a large part of which has to be done before anyone even picks a model, and which doesn't end on launch day.

Automating a process with AI starts with describing the process

In my view, you can only automate a process that already exists. Before I start thinking about a model, I want to be able to describe the process in full: where the data comes from, who does what with it and in what order, what decisions are made along the way and by what rules, and what a result we consider good looks like. On top of that come three measurements without which it is hard to judge later whether the automation achieved anything: how long one run takes, which part is the most painful (that is usually the first candidate for automation, rather than the whole process at once), and what it all costs (in working hours, in mistakes that have to be fixed later, in delays).

A process that can't be described is not ready for automation yet. A model won't guess rules that exist only in someone's head, but it will answer anyway, often in a very confident tone, and without a description there is nothing to compare that answer with.

How to prepare a process for automation

First I go through the process by hand, step by step, and repeat it until every step works the way I want. This stage looks like a waste of time, and in practice it is where most things come to light: exceptions nobody remembered, decisions made by feel (which have to be turned into a written rule), data that arrives in one format one day and in another the next. These things usually come out anyway, but after automation they come out later, in a place that is harder to track down and in larger numbers, because an automated process repeats a mistake as quickly as a good result.

An example: reading product labels automatically

My own example shows this well. I built a process that reads the nutrition values from photos of a product label and saves them as a record in a database. Before I automated it, I used to retype such labels by hand, so I knew what steps the work consisted of and where it was hard (usually not in reading the characters themselves but in the layout of the table, that is, in which number belongs to which row and column).

The first version was as simple as it gets: one model, one photo, one answer. The model not only got digits wrong, it could also “fix” values so that everything added up: instead of copying what was on the label, it adjusted the numbers to what it considered sensible. Today the process looks different. The text on the label is read twice by OCR (a program that recognizes text in an image), the model transcribes the values, an ordinary program checks them against written rules, a separate check gives a second opinion, and at the end a person reviews the record and only then saves it. Of the first 33 labels, the checks flagged one as doubtful, and when the process later read whole shopping trips, over six hundred labels, about one in four was doubtful. Reading a label took about a minute and a half on average.

There is one thing in this example I can't tell you today, though: how much faster it is now than when I retyped labels by hand. I didn't measure that before I started, so I can give you the time after automation, but not the gain. It is the first measurement I would take today before any automation.

Test data and trial runs

Once the process is described and checked by hand, it is time for the automation itself, and here again you need to set aside time for the start. The model needs data that is good enough and varied enough (not only the cleanest examples, but also the illegible, unusual and incomplete ones that turn up regularly in real life). Then I run the process a few times on cases where I know the correct result, compare what came out with what I expected, adjust the prompts or the order of the steps, and run it again. One successful run doesn't mean much to me, because a model asked the same thing a second time doesn't have to answer the same way.

One AI agent for everything

What seems particularly risky to me is a setup in which one agent gets the whole task at once (read, decide, save, send) and nobody checks what comes out of it. A setup like that can work for a while, but when something starts to break, it is hard to tell where, because all the steps happen in a single run and leave no trace behind. I prefer to split the process into smaller steps, each of which hands back a result that can be checked, and I give whatever can be counted (totals, dates, complete fields, matches against a list) to an ordinary program, because a program, unlike a model, doesn't estimate.

Piloting an AI rollout with human review

I would treat the first period after launch as a pilot, in which a person reviews every result before it goes any further. That sounds as if the automation saves nothing, and at first it really does save little, but it is the simplest way I know to measure how often the model gets things wrong and what kind of mistakes they are. Only on that basis would I relax the review: first a person would look only at the results flagged as doubtful and a random sample of the rest, and if the numbers still held up, the sample could shrink. How much review stays for good depends on what a mistake costs (an error in an internal note is not the same as an error in an amount on a document that goes to a customer).

The cost and upkeep of AI automation

The cost of running such a process (with cloud models billed by the amount of text they process) is an estimate rather than a fixed amount. It depends on the number of documents, their length, how many times the process has to repeat something, and the provider's price list, which changes too. Instead of promising a specific number, I would give a range and set a spending limit, after which the process stops or someone gets a notification.

After launch there is still upkeep: the format of the incoming data changes, new models appear (sometimes better and cheaper), and a service the process depends on can stop working. In my case, for seven days in a row the model didn't answer a single request from the agents that prepare reports every morning. The report still went out every morning, because the numbers are calculated by an ordinary program and the model only describes them, but the outage itself was not caught by the program that watches over my computers. Someone has to notice and fix things like that, and it is ongoing work, not a one-off project.

Who in the company oversees the AI's work

The least obvious change concerns people. In my view, automation built on AI usually doesn't remove people's work, it changes its nature: instead of doing every step themselves, someone directs the model's work and checks its results. That person should know the process better than anyone else, settle the cases the rules didn't foresee, read the results flagged as doubtful and notice when quality starts to slowly slip, and for that they need time and the authority to make decisions. Free time does appear, but I expect there is usually less of it and it comes later than the picture at the start of this note suggests, and you win back the most in the part of the process that was the most painful (and that is exactly where it is worth starting).

If you are thinking about automation like this for your own work, I have gathered on the homepage a short list of what is worth knowing before we talk.

In short

• Automation is best started from a process that already exists: describe its steps and rules, measure how long it takes, its most painful part and its cost, and then go through it by hand until every step works, because without measuring the manual version you can't work out later what the automation gained.
• The start takes time: good, varied data, a few trial runs on cases with a known result, and fixes after each one.
• One agent for everything, with nobody checking its results, can work for a while, but when it starts to break, it is hard to tell where. Smaller steps, and an ordinary program for whatever can be counted, work better for me.
• At the start of a pilot a person checks every result, and the review is best relaxed only on the basis of measurements.
• The running cost is an estimate with a spending limit, upkeep goes on after launch, and someone has to direct the AI's work and check it.