Planning, reflection and reliability in language model agents

The hardest tasks for agents are long ones: fixing a bug that spans several files, researching a question across dozens of sources, migrating a codebase, or completing a multi-step business process. Long tasks expose a basic arithmetic problem: if each step succeeds with high but imperfect probability, the chance of completing many steps without error falls quickly. This lesson examines why long-horizon tasks are hard, and the techniques that make agents more reliable: explicit planning and task decomposition, verification of each step, reflection and self-correction, search over alternatives, checkpoints and human involvement, and the system design choices that keep agents on track.

Why long tasks fail

Suppose an agent completes each step of a task correctly with probability \(p\), and errors are independent and unrecoverable. The probability of completing \(n\) steps is \(p^n\):

With \(p = 0.95\), a 5-step task succeeds 77 % of the time, a 20-step task only 36 %, and a 50-step task 8 %. Real agents are not quite this fragile, because some errors are harmless and many can be noticed and fixed, but the compounding effect is real and explains why agents that perform well on short tasks struggle on long ones. Improving reliability therefore requires either raising per-step accuracy or, more practically, detecting and recovering from errors before they compound. METR's measurements of the length of tasks that frontier agents can complete with 50 % reliability show this horizon growing rapidly, doubling roughly every several months in recent years, but reliability at high confidence levels still lags far behind.

Verification and retries

The most powerful reliability technique is to check results. Code can be compiled, linted and tested; data transformations can be checked against row counts and totals; web actions can be verified by reading the resulting page; facts can be checked against sources. When a check fails, the agent retries with the error message as feedback. The simulation below shows how much this matters.

import numpy as np
# Why long agent tasks fail, and how verification with retries helps
rng = np.random.default_rng(8)
def run_task(n_steps, p_success, verify, max_retries=2, detect=0.9, trials=20_000):
    ok = 0; cost = 0
    for _ in range(trials):
        success = True
        for s in range(n_steps):
            attempts = 0
            while True:
                attempts += 1; cost += 1
                good = rng.random() < p_success
                if good:
                    break
                caught = verify and rng.random() < detect
                if caught and attempts <= max_retries:
                    continue                     # error detected: retry the step
                success = False                  # undetected error, or out of retries
                break
            if not success:
                break
        ok += success
    return ok / trials, cost / trials
print("steps  per-step  no verification   with verification + 2 retries   tool calls (verified)")
for n in (5, 10, 20):
    for p in (0.95, 0.90):
        a, _ = run_task(n, p, False)
        b, c = run_task(n, p, True)
        print(f"{n:5d}  {p:8.2f}  {a:15.2f}   {b:30.2f}   {c:8.1f}")
print(f"analytic check: 0.95 ** 20 = {0.95 ** 20:.2f}")

steps  per-step  no verification   with verification + 2 retries   tool calls (verified)
    5      0.95             0.78                             0.97        5.2
    5      0.90             0.59                             0.94        5.4
   10      0.95             0.59                             0.95       10.2
   10      0.90             0.34                             0.89       10.4
   20      0.95             0.36                             0.90       19.9
   20      0.90             0.12                             0.79       19.7
analytic check: 0.95 ** 20 = 0.36

Without verification, a 20-step task with 90 % per-step success completes only 12 % of the time, matching the \(p^n\) formula. With a check that catches 90 % of errors and up to two retries per step, success rises to 79 %, at a cost of only a few extra tool calls on average. The gains are largest on long tasks, exactly where agents struggle. The quality of verification matters: checks that miss errors, such as weak tests or superficial reviews, give false confidence. This is why test-driven workflows, where tests are written or identified before code is changed, work so well for coding agents, and why good evaluation criteria are the foundation of reliable automation.

Planning and task decomposition

Asking an agent to plan before acting improves performance on complex tasks. A plan breaks the goal into subtasks, identifies dependencies and the information needed, and gives the agent a structure against which to track progress. Approaches include:

• Plan-and-execute: the model writes a plan, then executes steps one by one, revising the plan when observations differ from expectations.
• Hierarchical decomposition: large tasks split into subtasks that may be delegated to sub-agents, echoing HTN planning (Lesson 3).
• Explicit task lists: the agent maintains a to-do list in a file or tool, marking items complete, which also helps humans follow progress.
• Least-to-most prompting: solve simpler subproblems first and use their answers for harder ones.

Plans must stay flexible. A plan written before exploring a codebase or data set is often wrong in details, and an agent that follows its plan rigidly despite contradicting evidence fails. The plan–act–observe–revise loop from classical planning applies directly.

Reflection and self-correction

Reflection techniques have the model review its own work. Self-critique prompts the model to examine an answer for errors before finalizing it; Reflexion stores verbal reflections on failed attempts and uses them to improve later attempts; evaluator–optimizer loops pair a generator with a critic, often with explicit criteria. Reflection helps most when grounded in external feedback, such as test failures, compiler errors or retrieved evidence. Without such feedback, models are often poor at finding their own mistakes and may "correct" right answers into wrong ones, so self-critique alone is not a substitute for verification.

Search over alternatives

When one attempt may fail, generating several and choosing the best can raise success rates substantially. Best-of-n sampling generates multiple solutions and selects one using tests, a verifier model or majority voting (self-consistency). Tree search over reasoning steps or actions explores alternatives and backtracks from dead ends, as in Tree of Thoughts and agentic search methods. These approaches trade compute for reliability, and they depend on good selection signals: without a reliable verifier, choosing among many candidates can simply pick the most convincing wrong answer. Lesson 11 examines voting among multiple agents in more detail.

Checkpoints, rollback and human involvement

Agents that change things should make changes recoverable. Version control lets every code change be reviewed and reverted; databases can use transactions or work on copies; documents can be drafted rather than sent. Checkpoints save the agent's state so a long task can resume after a failure without starting over. For consequential steps, human checkpoints, such as approving a plan before execution, reviewing a pull request before merging, or confirming before sending an email or making a payment, combine automation with oversight. The art is placing checkpoints where they add the most value: too many and the agent saves little effort; too few and errors reach the real world. Lesson 12 discusses how to decide which actions need approval.

Designing for reliability

Several system-level design choices make agents more reliable:

• Narrow the task: agents with clear goals, well-defined success criteria and limited scope perform far better than those given vague, open-ended mandates.
• Provide good tools and environments: fast tests, clear error messages, sandboxes where mistakes are cheap, and documentation the agent can read.
• Make progress observable: logs, task lists and summaries let both the agent and humans see what has been done.
• Budget and stop: set limits on steps, time and cost, and require the agent to report when it is stuck rather than looping.
• Evaluate systematically: measure success rates on representative tasks, not anecdotes, and track regressions when models, prompts or tools change.

Handling ambiguity and asking for help

Many failures on long tasks begin with a misunderstanding at the start. An agent that spends an hour building the wrong thing wastes more than one that asks a clarifying question in the first minute. Good agents identify ambiguities that would change the outcome, such as which environment to deploy to, which customers a change should affect, or what format a report should take, and resolve them early, either by checking available information or by asking. They also recognize when they are stuck: repeated failures of the same approach, contradictory evidence, or missing access are signals to report the situation and propose options rather than continue blindly. Designing agents to ask well, concisely and only when it matters, is as important as designing them to act.

Case study: a coding agent fixing a bug

Consider an agent asked to fix a failing test in a large repository. A reliable workflow looks like this: read the failing test and error message; search the codebase for the relevant functions; form a hypothesis about the cause; write or identify a test that reproduces the bug; make a minimal change; run the specific test, then the broader test suite; inspect the diff for unintended changes; and summarize what was changed and why. Each step produces evidence that the next step builds on, and verification happens at several points. Agents that skip reproduction or the broader test run often produce patches that make one test pass while breaking others, or that pass by special-casing the test rather than fixing the logic, which is why evaluation suites check hidden tests the agent cannot see.

Measuring progress on long tasks

For long tasks, it helps to measure partial progress as well as final success: how many subtasks were completed correctly, where the agent went wrong, and how much human effort was needed to finish. Such measures reveal whether improvements come from better planning, better execution or better recovery, and they guide where to invest effort in tools, prompts or verification.

Timeouts and partial results

Agents should be designed to fail gracefully. When a time or cost budget runs out, a good agent stops, saves its progress, and reports what it completed, what remains and what it learned, so a human or another run can continue. Returning a clear partial result is far more useful than an incomplete change left in an unknown state or a confident claim of success that is not true.

Reliability engineering for agents borrows heavily from software engineering and operations: tests, code review, staged rollouts, monitoring and post-incident reviews. Teams that apply these established practices to their agents, instead of treating agents as magic, tend to build systems that improve steadily and fail in predictable, recoverable ways.