On 23 July 1983, just after eight in the evening, at 12,500 meters above Ontario, a low fuel pressure alarm sounded in the cockpit of an Air Canada Boeing 767, and a moment later the second engine died just as the first had. Captain Bob Pearson and First Officer Maurice Quintal were flying from Montreal through Ottawa to Edmonton with 69 people on board and less than half of the fuel the flight plan considered necessary.
The cause was a conversion factor. The fuel gauges on that aircraft were not working, so the amount in the tanks was measured by hand with a dipstick, in liters, and then converted to kilograms, because the flight plan required 22,300 kilograms. The fueling worker gave a fuel density of 1.77, which meant pounds per liter, and the crew calculated with it as if it meant kilograms, although the correct value was about 0.8. The measurement and the arithmetic were correct, while the whole error sat in one number at the very beginning, which every following step accepted on trust. In Ottawa the crew repeated the calculation with the same conversion factor and got the same wrong result. About 10,100 kilograms of fuel went on board instead of 22,300.
Pearson was an experienced glider pilot, and Quintal knew the former military base at Gimli and suggested it as a landing site. The aircraft, with no working engine, glided for about seventeen minutes and settled onto a disused runway where a race happened to be under way. Nobody died. The inquiry later found that the airline had not clearly assigned to anyone the responsibility for calculating the fuel load, and in 1985 both pilots received a diploma from the International Aeronautical Federation for outstanding airmanship, although the airline had earlier punished them with a demotion and a suspension.
If the whole flight depended on one number entered at the start, who should have confirmed it before all the following steps trusted it?
An artificial intelligence agent works like that crew: it carries out a series of steps, each based on the result of the previous one, and it rarely goes back to the first number to check it. The thesis of this post is that the profitability of an agent depends on how many checkpoints the process contains and where they stand, while the quality of the model itself matters less than vendor presentations suggest.
How an agent differs from an ordinary chat window
An ordinary assistant answers a question in one move: it receives text and returns text. An agent receives a goal, for example “reconcile supplier invoices with last month's orders,” and works in a loop: it plans the next step, reaches for a tool, reads the result, judges whether the goal has been achieved, and if not, plans another step. By a tool I mean here any program the agent can launch on its own, for example a search engine or a spreadsheet. The decisions are made by a language model, a program that, on the basis of a huge number of examples, predicts the most probable continuation of a text, including a text that is an instruction for a tool.
In its December 2024 paper “Building effective agents,” Anthropic separated two things that sales conversations throw into one bag. A workflow is a path written in advance in code, along which the model carries out steps set by a programmer. An agent steers its own course and its choice of tools. With a customer complaint, a workflow will always read the message, find the order and write a reply, while an agent will decide for itself whether to check the warehouse stock or to ask the customer a question. The first solution is predictable, the second flexible, and it is for that flexibility that one pays.
Why a mistake from the start travels through the whole job
Every step of an agent is based on the result of the previous one, and the model reads its own earlier notes as facts. If in step two it writes down a wrong amount, step five calculates a discount from the wrong amount, and step eight writes the customer a polite letter with the wrong discount. The later steps were carried out correctly, only on bad data, exactly as in the Boeing cockpit, where every arithmetic operation was in order.
A little probability shows the scale. Assume, for illustration, that an agent gets a single step right in 95 percent of cases and that the errors are independent of each other. After ten steps the whole job is correct in about 60 percent of cases, after twenty in about 36. The real values depend on the task and nobody knows them for your process until it is measured, but the direction is certain: a longer chain lowers the chance that the final result is good. Anthropic puts it plainly in the same paper: an agent's autonomy means higher costs and the potential for compounding errors, so the authors advise looking for the simplest solution and making it more complicated only when the simple one is not enough.
Checking again does not always help, as Ottawa shows. The crew repeated the calculation but used the same density, so they repeated the error too. An agent that judges its own result on the basis of the same data behaves similarly: a check makes sense only when it draws on a source other than the one that may have failed.
What the data say about agent deployments
According to press reports of a June 2025 announcement by the research firm Gartner, more than 40 percent of agent projects will be cancelled by the end of 2027 because of rising costs and unclear business value. The same firm describes a phenomenon called “agent washing”: vendors relabel ordinary assistants and chatbots as agents, and out of thousands of companies claiming such products, Gartner estimates that about 130 have a genuine offer. The forecast concerns the whole market and is an analysts' estimate, not a measurement in a particular company, but it agrees with what follows from the calculation above: cost grows with every step, while certainty of the result shrinks.
The cost has several parts. A ten-step agent makes a dozen or so calls to the model instead of one, and later steps usually read an ever longer history, so the bill for requests is often many times higher than for an ordinary answer. On top of that comes the time of the person who reviews the results, because without it the calculation looks too rosy.
What an agent does well and what it cannot do
An agent proves itself where there are few steps, each can be verified from its result and a mistake costs little, for example when preparing a list of invoices for approval or in the first sorting of requests. It copes badly with long chains, with irreversible actions (a transfer, sending a contract, changing data in the HR system) and wherever the result has no simple test.
The risk also concerns permissions. An agent with access to systems performs actions that nobody looked at before they were carried out, so I grant it permissions as I would to a new employee on probation: read access first, and write access only after the first results have been checked. Before a conversation with a vendor it is worth preparing one question: how many steps does its agent take in a typical task, and at which points does a person see an intermediate result. An answer such as “it depends” means that nobody has measured it yet. My recommendation is to start with a workflow and to reach for an agent when the number of possible paths truly makes it impossible to write them down in advance.
The first step for Monday morning
On Monday do one thing that costs an hour and requires no purchase:
- Choose a process that takes someone an hour a day and has at most five steps, for example reconciling invoices with orders.
- Write the steps on a sheet of paper and mark the one in which the first number or first decision appears on which the others depend.
- Set a checkpoint after that step, carried out by a person on the basis of a source other than the one the agent uses, for example the paper invoice instead of its copy in the system.
- Run the agent in draft mode, in which it prepares and a person approves, and compare its results with the employee's work on twenty closed cases from the previous month.
If the agreement is below 90 percent (this is my working threshold, which every finance department should set according to its own tolerance for error), first improve the description of the process and the checkpoints, and only then change the model. Until then the agent remains an assistant that prepares drafts, and the transfer and the sending of a contract are approved by a person who knows the first number.