Everything an agent does is one short cycle repeated. Understanding the cycle tells you why agents are impressive on some tasks, why they waste enormous effort on others, and where to put a checkpoint when you want control back.
The cycle
Plan. Given the goal and everything that has happened so far, the model decides the single next step.
Act. It requests a tool call. The harness performs it for real.
Observe. The result is added to the conversation. So is the failure, if it failed.
Check. The model looks at the accumulated state and decides: goal met, try something else, or continue.
Then it plans again. That is the loop. A long agent run is not a grand strategy being executed. It is this cycle, many times, each turn seeing only the conversation built so far.
Why it works at all
Two things make a small cycle capable of long tasks.
Feedback. Each observation is real information from the world, not a guess. When a file is missing, the agent finds out and can adapt. Chat assistants have no equivalent — they cannot discover they were wrong mid-answer.
Decomposition emerges. Nobody hands the agent a plan. Because each turn only has to choose the next reasonable step given the current state, a long sequence of locally sensible steps often adds up to a completed task.
Why errors compound
Here is the arithmetic that matters most, and it is the honest reason agent reliability is hard.
Suppose, purely as an illustration, that each step is right nineteen times out of twenty — an assumption, not a measurement of any particular system. That sounds strong. Over a twenty-step task, if every step must be right, the chance of a clean run is roughly one in three. Nothing has malfunctioned. Ordinary per-step accuracy simply does not survive multiplication.
Worse, mistakes do not stay put. A wrong value read in step three becomes context for step four, which reasons correctly from a false premise and produces a confident, wrong result. By step twelve the agent is working hard on the wrong problem, and its later steps look just as competent as its earlier ones.
This is why "the agent got it wrong" usually means "an early observation was wrong and nothing checked it." The fact-checking habits that apply to chat output apply doubly here.
Getting stuck
Loops fail in recognizable ways.
The retry spiral. A tool keeps failing. The agent keeps trying variations. Each attempt costs money and time, and it does not have a good sense of when to stop.
The wrong groove. It settles on an approach that cannot work and refines it repeatedly instead of stepping back.
Losing the thread. Long runs fill the context window. Early instructions scroll out of view, and the agent starts behaving as if you never said them.
Declaring victory. It decides the goal is met when it is not, because the state looks approximately right and the plausible next token is a summary.
Well-built agents mitigate all of these with step limits, budget caps, and periodic re-reading of the original goal. None of it eliminates the underlying problem.
Where to interrupt
Because the loop is discrete, you can put a gate between any two turns. The useful places are: before any irreversible action, after the initial plan is formed, and at a fixed step count for a progress check.
An agent that plans first, shows the plan, and waits for approval gives you most of the value with a fraction of the risk. That is not a limitation to be engineered away; on consequential tasks it is the correct design. Guardrails and human-in-the-loop covers how to place those gates well.
Key takeaway: an agent is a short cycle repeated, and each repetition inherits every earlier mistake. Long autonomous runs are not more intelligent than short ones — they are just less supervised.