Three different things. One word in the catalogue.

“Understanding AI” series, note 3 of 12. The first two explained what artificial intelligence is and how a language model works inside. This one leaves the machine and walks into the meeting room.

Tuesday, 9:30 am, the large meeting room of a logistics company in Basel. Three vendors, three presentations, the same word on all three cover slides. The first shows a system that reads orders from email and enters them in the management software. The second, a “robot” that copies data from one screen to another without anyone touching the mouse. The third, an “agent” that answers customers on its own. All three say artificial intelligence. All three cost more than the new lorry did. And the owner, who has spent thirty years telling a good haulier from a bad one in five minutes, realises she does not know where to start comparing.

The scene is imaginary. The confusion is not. It arises because three technologies sixty years apart have been squeezed into the same word, and because it suits whoever is selling. In this note I give you the three definitions, an image so you do not forget them, a criterion for knowing which one you need in each case and the seven questions I use to take a presentation apart in half an hour. By the end, the next time someone tells you “this is AI”, you will know exactly what they are telling you. And what they are not.

Software follows rules. The process robot imitates hands. The model predicts. All three automate, but only one of them can be wrong with elegance.

First: software, or the written rules.

A classic program is a recipe. Someone wrote, step by step, what to do with each piece of data: if the invoice exceeds CHF 10,000, ask for a second signature; if the customer is in Italy, apply this tax; if the field is empty, show an error. Every rule was thought up by one person and written by another, or the same one. The program understands nothing. It executes.

This has one enormous virtue we tend to take for granted: it is deterministic. With the same input it always produces the same output. If it fails, it always fails the same way, and someone can read the rule and fix it. Your accounting software, your booking system and the spreadsheet you use to calculate margins are software in this sense. They have been automating for decades, and well. Most of what a company needs to automate is still, in 2026, ordinary software. Worth remembering before the second presentation.

Its limit is just as clear. It only does what someone managed to write as a rule. And there are things nobody knows how to write as a rule: recognising that an email is a complaint even if it does not contain the word complaint, summarising a contract, deciding which order is urgent by reading the customer’s tone. That is where classic software stops.

Second: robotic process automation, or the hands that imitate.

In the late 2000s a simple and very profitable idea appeared. Many companies have programs that do not talk to each other: the order system does not connect to invoicing, the bank does not connect to the accounts. Someone, every morning, copies data from one screen to another. What if a program imitated that person? It opens the application, clicks where she clicks, copies what she copies, pastes where she pastes. This was called robotic process automation, RPA for short. The “robot” is not a machine: it is a program that moves the mouse and types.

IBM defines it with a distinction worth its weight in gold in a meeting. RPA is process-driven: it follows predefined flows, step by step, and works with structured data, the kind already in fields and columns. Artificial intelligence is data-driven: it learns patterns and can work with unstructured data, such as free text, images or voice. They are complementary, says IBM, and that is true. But they are not the same, and a process robot is, at bottom, classic software with a different interface: as deterministic and as blind as any recipe.

The image I use is a kitchen. Software is the recipe. The process robot is an assistant who follows the recipe to the letter, opens the drawers and presses the oven buttons, but never tastes the sauce. It is very useful as long as the kitchen does not change: if someone moves the knife drawer, the assistant opens thin air. That is why RPA projects break every time a vendor changes the layout of a screen. If you have been sold a robot that “adapts” to screen changes, ask how. The answer is almost always: with a person who fixes it.

Third: artificial intelligence, or the cook who tastes the sauce.

The third technology is the one we explained in the two previous notes. A model trained on enormous quantities of examples which, instead of following written rules, predicts: the next word, the category of an email, the content of a field from a scanned PDF. Nobody wrote it the rule “this is a complaint”. It has seen millions of complaints and recognises a new one even when it is phrased with Swiss courtesy.

In the kitchen, it is the cook. It tastes the sauce, notices it lacks salt and corrects it. It can improvise with what is in the fridge. And it can be wrong: mistake sugar for salt with the same confidence with which it gets everything else right. That is the decisive difference from the other two technologies and the reason for this whole series. Software and the robot fail predictably. The model fails plausibly. A badly written rule produces a visible error; a badly configured model produces an answer that looks right.

From this comes the question that has earned me the most value in a meeting, and which I give you: “If I run it twice with the same data, do I get exactly the same result?” If the answer is yes, you are being sold software or a process robot, however loudly the cover slide says AI. If the answer is “almost”, you are being sold a model, and from that moment every other question has to be about how that “almost” is measured and controlled.

Which one you need, and when.

It is not a competition. Almost every good project I have seen combines all three, and the usual mistake is to put a model where a rule would do, or a rule where a model was needed. My criterion fits in a mental table with two questions: are the rules clear? and is the data tidy?

• Clear rules, tidy data. Software. A formula, a validation, an approval flow. It is the cheapest, the most reliable and the one that needs the least supervision. Example: flagging an invoice that is 30 days overdue.
• Clear rules, tidy data, programs that do not talk to each other. A process robot, while the real connection is being built. Example: moving the bank transactions into the accounting software every morning. Know that it is a crutch, not a solution, and that it will break with the next screen change.
• Fuzzy rules or unstructured data. An AI model. Example: reading the emails that arrive at info@, deciding what they are about, extracting the order and proposing a reply. Here there really is something no rule knew how to do.
• Judgement with consequences. A model that proposes and a person who decides. Example: sorting complaints by severity. The machine orders the inbox; the decision to compensate is signed by someone.

Notice that in the last two cases the model rarely works alone. Normally it reads something messy, turns it into tidy data and hands it to ordinary software, which applies the rules from there. AI tidies; software executes; the robot, if needed, moves the mouse. When a vendor shows you a system, ask them to point to each of the three pieces on the diagram. If they cannot, they did not build it.

The most worn-out word in the catalogue: agent.

The fourth word remains, the one from the third presentation. In 2026 almost everything is called an agent. It is worth knowing where it comes from and how much lies behind it.

In December 2024 Anthropic published a technical guide for the people who build these systems, and in it draws a line that will serve you: a workflow is a system in which the model and the tools are orchestrated along paths defined in advance in code; an agent is a system in which the model itself decides which steps to take and which tools to use to complete a task. The same guide adds two pieces of advice a salesperson rarely repeats: always look for the simplest possible solution, and use agents only for open-ended problems where the number of steps cannot be predicted. For almost everything else, it says, a single well-made call to the model is enough. I devote note 5 to this distinction.

The market has gone the other way. On 25 June 2025 Gartner published a forecast that should hang in every purchasing department: more than 40% of agentic AI projects will be cancelled by the end of 2027, because of rising costs, unclear value or inadequate risk controls. In the same release it coined a term, “agent washing”, for the practice of rebranding as agents products that are not: assistants, process robots, classic automations with a fresh coat of paint. Gartner estimated that, among the thousands of vendors claiming to sell agents, only around 130 were real. And in a survey of 3,412 executives, 19% had made significant investments in agents, 42% cautious investments, 8% none and 31% were waiting to see.

I am not telling you this so that you do not buy agents. I will explain them, and properly, in two notes’ time. I am telling you so that, when you hear the word, you ask the earlier question: does the model decide the steps, or did a programmer? Most of the time a programmer did, and that is good news, because it is cheaper, more predictable and easier to control. It is only bad news if you paid for it at the price of something else.

Seven questions for half an hour.

I ask them in this order, and the quality of the answers tells me more than the demo.

• If I run it twice with the same data, do I get the same result? Separates software from model. It comes first because it changes all the others.
• Which part is model, which part is rule and which part is robot? Ask them to point to it on a diagram. Whoever built it knows by heart.
• Which model, whose, and which version? If the answer is “our own AI engine”, press on. In 2026 almost nobody trains their own model; almost everyone uses a large provider’s. That is legitimate, but it changes who controls the price and the changes.
• Which fifty cases of mine do we measure it with? Not theirs. Fifty real emails, invoices or calls from your company, with the correct answer known. If that cannot be done, it cannot be evaluated.
• What happens when it does not know? The good answer is: it says so and hands over to a person. The bad one is: it always answers.
• What breaks when something changes? A screen, an invoice format, the model version. Who fixes it, how fast and at what price.
• Where does my data go? To which provider, in which country, whether it is used for training and how it is deleted. We will cover this calmly in the note on data and law, but the question is asked in the first meeting.

1. This week, 30 minutes

   Take stock of the three pieces

   List the programs you already have and mark each one: recipe, assistant or cook. You will find almost everything is recipe, and that it works.

2. At the next presentation

   Ask the two-runs question

   Before seeing the demo. Watch whether the salesperson understands it the first time.

3. Before asking for a price

   Ask for the diagram with the three pieces marked

   And for whose model it is and which version. Keep the answer in writing.

4. Before signing

   Prepare your fifty cases

   Real ones, with the correct answer next to each. That is your gold set, and it lets you measure all three vendors with the same yardstick.

How I approach it.

In my projects, no code is written in the first week: the diagram with the three pieces is drawn. There is almost always more recipe than the client expected and less model than they had been sold. The model is reserved for what no rule knows how to do, it is measured against the fifty cases before it is switched on and it is given permission to say “I don’t know”. The rest is software, and software, when it is well made, needs no surname.

Before the next note, think of the last “AI” proposal that landed on your desk. Strike that word out in your head and ask yourself what is left: a rule that could be written down, a robot that copies clicks, or a model that genuinely has to understand something?

If you do not know which of the three boxes it falls into, that is not a failing on your part. It is exactly the question the proposal should have answered for you. And it may be worth asking why it did not.

Next note: the map. What a language model can do today inside a company, department by department, with what the studies have actually measured and what is still a promise.