An AI agent is a language model put in a loop. That is the whole idea, and it is worth taking literally.

The model looks at a goal and the history so far, and it decides one action. An orchestrator runs that action as a tool, takes the result, and hands it back to the model. The model looks again and decides the next action. This repeats until the model decides the goal is met, or until a budget stops it. The model does not run anything itself. It only proposes; the orchestrator executes and owns the loop.

That loop is where every hard problem in this chapter lives. Not the prompt, not the model choice. The loop. And the first hard problem is the one that surprises almost everyone the first time they ship an agent: a system that was magical in the demo becomes unusable on real work, for a reason that has nothing to do with how smart the model is.

The number of steps a task takes is the strongest predictor of whether an agent finishes it correctly, and it is the one thing a demo quietly controls for you.

Count the steps in a typical demo: two, maybe three, on a clean chosen example. Count the steps in real work: ten, twenty, fifty, against messy inputs and tools that sometimes fail. Same agent, same model, same prompt. The only thing that changed is how many actions had to go right in a row. That single variable, length, is doing almost all the work in whether the agent succeeds, and almost nobody is watching it.

You cannot prompt your way out of this, because it is not a wording problem. It is arithmetic, and the next slide is the arithmetic.

Because the steps are a chain, and a chain multiplies.

Think about what it takes for a whole task to succeed: every step in it has to succeed. If the steps are roughly independent, the probability that all of them succeed is the product of their individual success rates, not the average. Multiplication punishes length in a way that intuition does not expect.

Put numbers on it. Suppose each step succeeds 95 percent of the time, which sounds excellent. A five step task succeeds about 77 percent of the time. A twenty step task succeeds about 36 percent of the time. A fifty step task succeeds under 8 percent of the time. The per-step number never changed. Only the length did.

Run it yourself and watch the collapse.

The lesson in that table is blunt. A per-step reliability that feels great is not good enough once a task is long, and the fastest way to a reliable agent is usually to make the task shorter, not the model smarter.

There is no single fix. There is a stack of them, and a real system uses all four.

Shorten the task. Two ten step tasks are far more reliable than one twenty step task, because 0.95 to the tenth twice is a much friendlier number than 0.95 to the twentieth once. Decomposing a big goal into smaller bounded ones is the highest-leverage move you have.

Raise per-step reliability. Better tool schemas that are hard to misuse, validation that rejects a malformed action before it runs, and clearer instructions all push each step closer to 1. Small gains here are amplified by the exponent.

Add verification. A second call that checks the first one's work trades cost for reliability, and on the steps that matter most it is worth it.

Make steps recoverable. If a step can retry instead of sinking the whole run, a transient failure stops being fatal. This is the subject of the durable-execution lesson later in this chapter.

Underneath all four levers is a single change in how you think about the thing you are building.

The mindset that fails is treating an agent like a function that returns the right answer. The mindset that ships treats it like an unreliable distributed system, because that is what it is: a sequence of calls over a network to a component that is stochastic and sometimes wrong. You already know how to build reliable systems out of unreliable parts. You use retries, verification, bounded scope, idempotency, and recovery. An agent needs exactly the same discipline, and each lesson that follows takes one of those tools and shows how it applies to the loop.

It is also why, later, you will see the advice to constrain an agent rather than maximize its autonomy. A shorter, narrower agent is not a weaker product. It is a more reliable one, and reliability is what makes it shippable at all.