A language model, in its ordinary use, receives an input and produces an output. An agent is what you get when the output is fed back in — when the model acts, observes what happened, and decides what to do next, repeatedly, until it judges the task finished. The change sounds procedural and is not. A single response either succeeds or fails and the user sees which; a loop of thirty steps can fail at step four and spend twenty-six more steps building on the failure, and nobody notices until the end. This piece is about that loop, about the arithmetic of compounding reliability that governs how long it can run, and about the fact that most of the difficulty turns out to be context management rather than reasoning.
The loop
The structure is small enough to state in a paragraph. The model is given a goal, a set of tools , and whatever context it starts with. It produces some reasoning and an action. The action is executed and its result appended to the conversation. The model is invoked again on the extended conversation, produces the next action, and so on, until it emits something signalling completion or a limit is reached.
That is the whole architecture, and the elaborate frameworks built around it are variations on where the reasoning goes, how the history is stored, and what happens when things go wrong.
What makes it powerful is that the model’s output becomes its own input, so the system can do things no single forward pass could. It can explore — try something, see it fail, try differently. It can decompose — handle one part, then use the result for the next. It can persist — keep working while a single response would have had to stop. And it gets feedback from the world rather than only from its own predictions, which is the sharpest difference from chain-of-thought reasoning , where the model deliberates but never learns whether any intermediate step was actually right.
The arithmetic that governs everything
Here is the calculation that explains most agent failures, and it needs no more than multiplication.
Suppose each step succeeds with probability $p$, independently. Then a task requiring $n$ steps succeeds with probability $p^n$:
$$P(\text{success}) = p^{\,n}$$At $p = 0.95$ — which would be a very reliable step — ten steps give $0.60$, thirty give $0.21$, and fifty give $0.08$. A system whose individual actions are right nineteen times in twenty fails most long tasks. Getting to a useful success rate over thirty steps requires per-step reliability above $0.99$, which is a much harder engineering target than it sounds.
Two implications follow, and they shape everything.
Reducing the number of steps is as valuable as improving each one. A tool that accomplishes in one call what previously took five improves the whole system more than a considerable improvement in the model. This is the strongest argument for designing tools around tasks rather than around the underlying API — a single tool that performs a complete operation, rather than six primitives the model must sequence correctly.
Recovery beats prevention. The independence assumption is what makes the compounding so brutal, and it is also what can be attacked. If a failed step can be detected and retried, its failure no longer terminates the chain. An agent that checks its work, notices an error, and corrects it is not making fewer mistakes — it is breaking the multiplication. Almost every technique that makes agents practical is a form of this: verification, retries, tests, human checkpoints.
Figure 1. Why nineteen-in-twenty fails most long tasks.
Context is the real constraint
The most consistent surprise for people building these systems is that the binding limit is not the model’s intelligence but its context.
Every step adds material. The action, the result, the reasoning that produced it. A tool that returns a directory listing, a search result, a file, an error trace — these accumulate, and after twenty steps the conversation may hold a hundred thousand tokens of which the great majority is no longer relevant. The cache grows accordingly, and worse, the dilution and lost-in-the-middle effects mean the original instruction is now buried in the middle of a long transcript, attended to less reliably than anything recent.
The practical consequence is that agents drift. They lose track of what they were asked, repeat work they have already done, and pursue subgoals that made sense ten steps ago. This looks like a reasoning failure and is usually an attention failure.
So context management becomes the central engineering activity. Summarize the history periodically and replace the raw transcript with the summary. Keep a separate structured record of what has been accomplished and what remains, re-stated at each step rather than reconstructed from the conversation. Write intermediate results to files and hold only references in context. Restate the goal near the end of the prompt where attention is strongest. Give subtasks to fresh invocations with clean context and return only their conclusions, which keeps the parent’s history short and is the strongest version of the technique.
That last pattern — a coordinating agent delegating to sub-agents whose context it never inherits — is the main structural answer to the problem, and its cost is that the parent cannot see what the child saw, only what it reported.
Figure 2. What twenty steps leave in the window.
Common structures
A few arrangements recur often enough to name.
Reason, act, observe. Interleaving explicit reasoning with actions, rather than emitting actions alone. The reasoning is not decoration: it gives the model tokens in which to consider what the last observation implies before committing, and it makes the trace legible to whoever has to debug it.
Plan then execute. Produce a full plan first, then work through it. This helps on tasks with real structure and hurts on tasks where the right next step depends on what the last one revealed, because a plan made in ignorance is followed past the point where it stopped making sense. The usual compromise is to re-plan periodically rather than once.
Critique and revise. A second pass — the same model or a different one — examines the output and identifies problems, which are fed back. This works well when the critique can appeal to something external, such as a test suite or a specification, and much less well when the model is judging its own work by its own standards, since the same blind spots produced and then evaluate the answer.
Delegation. A coordinator decomposes and dispatches to specialists. It is the answer to context accumulation and to genuinely parallel subtasks, and its difficulty is that decomposition is itself a hard judgement, and that a coordinator working from a summary of a summary is several steps removed from the ground truth.
Evaluation, and why it is the bottleneck
Evaluating an agent is substantially harder than evaluating a model, and the difficulty is not incidental.
There is often no single correct answer, only outcomes that are more or less acceptable. Cost varies enormously between runs, so quality must be reported against tokens spent rather than alone. The same task run twice takes different paths, so results are noisy and small differences require many trials. And the environments are stateful, so a genuine evaluation must be reset between runs, which makes the whole exercise expensive and slow.
The consequence is that agent development is unusually prone to proceeding on impressions. A change feels better on the handful of examples someone tried; whether it is better is frequently unknown. Teams that build reliable systems are almost always the ones that invested early in a real evaluation harness — sandboxed environments, deterministic resets, a suite of tasks with checkable outcomes — and the ones that did not tend to plateau at demonstrations.
The honest state of things is that agents work well when the loop is short, the tools are well-designed, the environment gives clear feedback, and success is checkable. They work poorly on long-horizon tasks in environments that do not answer back. That is a narrower claim than the enthusiasm around them suggests, and it is also a description of a rapidly moving boundary — the horizon over which these systems remain coherent has been extending steadily, and the compounding arithmetic says that each increment of per-step reliability buys disproportionately more of it.
What to carry forward
An agent is a model whose output is fed back as its own input: it acts, observes, and decides again, in a loop, until the task is done or a limit is hit. The loop’s power is that it gets feedback from the world rather than only from its own predictions, which lets it explore, decompose, and recover in ways a single response cannot. Its governing constraint is multiplicative — with per-step reliability $p$ and $n$ steps, success goes as $p^n$, so even a very reliable step fails most long tasks — from which two things follow: reducing the number of steps is worth as much as improving each one, which argues for tools designed around whole tasks rather than primitives; and recovery beats prevention, since detecting and retrying a failed step breaks the multiplication that makes the arithmetic so unforgiving. In practice the binding limit is not reasoning but context: every step accumulates material, the original instruction ends up buried where attention is weakest, and the resulting drift looks like a reasoning failure while being an attention failure — so summarization, external state, and delegating subtasks to fresh invocations with clean context are the central engineering activity rather than a detail. The recurring structures are interleaving reasoning with action, planning versus re-planning, critique loops that work when they can appeal to something external and much less well when a model judges itself, and hierarchical delegation. And evaluation is the real bottleneck, since there is rarely one correct answer, cost varies per run, paths are nondeterministic, and environments are stateful — which is why these systems work well on short loops with checkable outcomes and poorly on long horizons in environments that do not answer back.
The figures in this article follow the shared figure key , which explains what every shape, line style and colour means.
