An agent is a loop. And loops are watched.

“Understanding AI” series, note 5 of 12. The previous note was the map of the verbs. This one explains how they connect to each other and to your systems, and what the most-heard word of 2026 really means.

Wednesday, 6:40 pm, the office of the finance director of a wholesaler in Lucerne. He has spent a week trialling an “agent” which, according to the demo, reconciles supplier invoices on its own: it reads the PDF, finds the order, compares amounts, checks the delivery note, consults the contract if there is a discount, asks the bank whether it has been paid, decides whether to book it and books it. Fourteen steps. Today he has reviewed the week’s forty invoices and found nineteen correct, fourteen with some error and seven he cannot judge because the agent took a path nobody can reconstruct. In the demo it was almost always right. What changed?

The scene is imaginary. The arithmetic that explains it is not, and it is the most important part of this note. Before I get to it I need to give you the three pieces from which any AI system that does more than chat is built. There are few of them, they have odd names and, once seen, they are not forgotten.

A model on its own is only an engine. Retrieval gives it the documents, tools give it hands and memory gives it the thread. An agent is that set placed inside a loop.

Piece one: retrieval, or the archivist.

You will remember from note 2 that the model only sees what is on the desk, and that your documents are in the basement. Retrieval is the archivist who, for every question, goes down to the basement, finds the three or four documents that deal with it and puts them on the desk before the model answers. The technique was described in May 2020 in a paper by researchers at Facebook AI Research, University College London and New York University, under the name retrieval-augmented generation, RAG for short, and its purpose was exactly the one that interests you: that the model answers with knowledge that can be updated and checked, instead of with what it memorised during training.

What changes in practice is enormous. An assistant without retrieval answers about your returns policy with general knowledge; one with retrieval reads your policy, answers from it and cites the paragraph. And it allows something almost nobody values until they need it: changing the answer without touching the model. If the policy changes tomorrow, the document is changed and the assistant answers differently by the afternoon. It also has its own failures, which the vendor rarely mentions: if the archivist brings up the wrong document, or an old version, the model will answer confidently from it. The quality of a retrieval system depends on the quality of the archive far more than on the model.

Piece two: tools, or the hands.

A model on its own produces text. It cannot query your database, send an email or create an invoice. A tool is a specific permission to do one of those things: the model is told what the tool does and what data it needs, and the model, when it sees fit, asks to use it with that data; the system runs it and returns the result. “Look up the status of order 4471” is a tool. “Send an email” is another. “Book an invoice” is another, and one of those that is granted with care.

In November 2024 Anthropic published an open standard for describing and connecting tools, the Model Context Protocol, which other providers have since adopted. For you this means one practical thing: the connections between a model and your systems stop being bespoke pieces only their maker understands and take on a common format that can be moved to another provider. Ask about it before signing. And keep the principle that follows: every tool is a permission, and permissions are granted one by one. A model that can read orders has no reason to be able to delete them.

Piece three: memory, or the thread.

The third piece is the most modest and the one that causes the most confusion. A model remembers nothing from one conversation to the next. What is called memory is a place where the system keeps notes, a summary of what has been said, a customer’s preferences, the state of a task, and puts them back on the desk in the next conversation. It is useful and it is a risk, because what is stored must be viewable, correctable and deletable, and because last week’s note may be wrong and still exert influence.

Anthropic calls this combination the augmented model: a model with retrieval, tools and memory. It is the brick from which everything else is built, and almost everything your company needs fits in a single well-made brick. I explain that now.

Workflows: when a person decides the steps.

In December 2024 Anthropic published a guide for people who build these systems, based on what it had seen across dozens of teams, and its first conclusion is the one that suits you best: the systems that worked best did not use complex frameworks but simple patterns. The guide separates two families. In a workflow, the steps are defined in advance in code, and the model is used at each step for its verb: classify, extract, draft. In an agent, the model itself decides which steps to take and which tools to use until the task is done.

The workflow patterns it describes are five, and I translate them into your company:

• Chaining. One step after another, each with a check. First extract the data from the invoice; check that it adds up; then look up the order. If something fails, it stops there and you can see where.
• Routing. Classify first and send each case down a different path. Complaints to one flow, orders to another, whatever is not understood to a person.
• Parallelising. Do several things at once, or the same thing several times and vote. Three independent readings of a contract that must agree before a figure is accepted.
• Orchestrating. One model splits the work into parts and others do them. Useful when you do not know in advance how many parts there will be.
• Evaluate and correct. One model writes and another reviews against given criteria, in a loop, until the review passes. Very useful in translation and drafting.

Notice what they have in common: in all of them, a person decided the shape of the process. The model works inside a lane. You know which step failed, you can repeat only that step and you can place a human review exactly where the risk calls for it. For our finance director’s invoice reconciliation, this is what I would build. And it is what the guide recommends: look for the simplest solution and add complexity only when the problem demands it.

Agents: when the model decides the steps.

An agent is the augmented model placed in a loop: it receives a task, decides a step, uses a tool, looks at the result, decides the next step, and so on until it considers the task done or hits a limit. It is the most capable piece and the hardest to control, because the path is not written down anywhere: it improvises it every time. Anthropic’s guide reserves it for open-ended problems, where the number of steps cannot be predicted, and recommends testing it extensively in closed environments and fencing it in: limits on steps, on money, on permissions, and points at which it stops to ask for confirmation.

How far do they go today? An independent research group, METR, has since 2024 measured one specific thing: the length of the tasks, measured in the time an expert person takes, that the best models complete successfully half the time. In March 2025 it published that this horizon was around one hour for the best model of the moment, that models almost always succeeded at tasks under four minutes and almost always failed at tasks over four hours, and that the horizon had roughly doubled every seven months for six years. The authors warn that the figures depend on the tasks and on the people they are compared with, and that extrapolating assumes the trend continues. Take it for what it is: an honest measurement, with its limits, of something growing fast. And note the word “half”.

The finance director’s arithmetic.

Back to Lucerne. The fourteen-step agent was “almost always” right at each step during the demo. Suppose it really is right 95% of the time at each one, which is a very good figure for a step that reads a PDF or interprets a contract. The probability that all fourteen steps go well is 0.95 multiplied by itself fourteen times: 49%. Half the invoices, wrong or half done. At 98% per step, which is excellent, the full chain gets 75% right. With ten steps at 99%, 90%. This is not an opinion about AI: it is the multiplication of probabilities, and on its own it explains the Gartner forecast I quoted in note 3, that more than 40% of agent projects will be cancelled by the end of 2027.

The design consequence is clear and it is the one I always use. Short chains, checks between steps and a person where the error costs. The same reconciliation, built as a five-step workflow with an arithmetic check at the second step and a human review only for the invoices that do not match, gets right the ones it gets right, stops on the ones it does not and leaves a trail anyone can follow. It is less impressive in a demo. It is what works on a Wednesday at 6:40 pm.

• A brick before a building. Almost everything is solved with an augmented model and one well-made call. If you are offered an agent, ask why a workflow is not enough.
• Counted steps. Ask for the number of steps in the system and the success rate of each, measured on your cases. Multiply. If the vendor does not understand the multiplication, they have not measured.
• Permissions one by one. Each tool, one permission; each permission, with a limit and a log. Reading does not imply writing; writing does not imply deleting or paying.
• Mandatory stops. Before any step with external consequences, the system stops and asks. A sent email cannot be unsent.
• A full trail. Every decision the system takes is logged: what it read, which tool it used, what came back. If the path cannot be reconstructed, it cannot be corrected.
• The archive rules. In retrieval systems, the quality of the document archive matters more than the model. An expired document is a well-presented error.

1. This week

   Draw the process in steps

   The one you want to automate, on one sheet: one step per line, with the question “what happens if this one goes wrong?” next to it. If it has more than eight lines, split it.

2. This week

   Do the multiplication

   Give each step a reasonable success rate and multiply. That is the number you should demand to see in a demo, not the look of surprise.

3. At the next meeting

   Ask who decides the steps

   If the model decides them, it is an agent and you must ask about limits, permissions and stops. If a programmer decided them, it is a workflow and you must ask about the checks between steps.

4. Before signing

   Ask for the list of permissions

   Which tools the system can use, with what limits and who can change them. A short list is a good sign.

How I approach it.

I build workflows with short steps and checks, and I reserve agents for what is genuinely open-ended: researching, exploring, preparing. Nothing with external consequences happens without a stop. Every system has a log a manager can read without knowing how to code, and the first question of every project is how many steps there are and how often each one is right on the fifty gold cases. The rest is presentation.

Before moving on to the next note, do the arithmetic with a process of your own. Choose one that has several steps today: a booking, an invoice, an enquiry that becomes an appointment. Count the steps and ask yourself how often each one gets it right. If nobody in your business knows, that is already an answer.

And a question worth leaving open until the next note: if an agent ran that process tomorrow, where would you put the first stop?

Next note: integrating AI into your company. The order of the steps, from the map to the first process in production, the gold set, shadow mode and why the project starts long before a vendor is chosen.