Can Your Agent Actually Learn From Previous Runs?

A production agent can execute the same class of task hundreds or thousands of times.

It can see the same failure repeatedly.

It can discover the same workaround repeatedly.

It can call the same expensive model repeatedly.

And still behave as if every task is the first one it has ever seen.

That is not necessarily a memory problem.

It may already have excellent memory.

Does One Agent Plan, Execute and Judge Its Own Work? Build a Planner-Executor-Critic Architecture

A single model can often do all of these things:

• understand a task,
• decide what to do,
• execute a tool call,
• inspect the result,
• critique its own work,
• decide whether it succeeded,
• and produce the final answer.

That is convenient.

It is also a dangerous concentration of responsibilities.

If the same component creates the plan, executes it, explains why the result is good, and decides whether the job is complete, then failures become difficult to localize.

A common agent architecture starts simply:

request
   ↓
model
   ↓
action

That simplicity is valuable.

It should be your default.

But eventually you may notice something strange.

The same model is being asked to do everything:

• classify the task,
• search documentation,
• reason about code,
• write SQL,
• review a patch,
• summarize logs,
• judge another model,
• decide whether a deployment is safe,
• and answer simple questions that did not require an expensive model in the first place.

At that point the problem may no longer be:

A common failure in search-based agents is easy to miss.

The agent generates several plausible branches.

It scores them.

One branch looks weak.

So the runtime prunes it.

Later, you discover that the discarded branch was the only one that could have reached the correct solution.

The problem was not generation.

The problem was not necessarily the model.

The problem was search allocation.

The agent spent too much compute exploiting what looked good early and too little compute exploring alternatives whose value only became visible later.

A reasoning agent can fail even when every individual step looks plausible.

The problem is often not that the model cannot produce a good line of reasoning.

The problem is that it commits too early.

It chooses one interpretation, one hypothesis, one plan, or one next step and then spends the rest of the run trying to make that decision work.

That gives us a common failure pattern:

problem
  ↓
first plausible thought
  ↓
second thought conditioned on the first
  ↓
third thought conditioned on both
  ↓
...
  ↓
confident answer built on an early mistake

If the first branch was wrong, every later step inherits the error.

A reasoning agent gives you one answer.

You run it again.

It gives you another.

You change nothing important:

• same task,
• same tools,
• same model family,
• same broad context.

Yet the result changes.

That is not necessarily a bug.

A probabilistic model is allowed to produce more than one plausible trajectory.

The engineering question is different:

How should an agent system use that variation?

One common answer is self-consistency.

Most developers first encounter chain of thought as a prompting trick:

Think step by step.

That framing is too shallow for agent engineering.

For an advanced agent, the useful idea is not that the model should produce a long explanation. The useful idea is that a difficult task may benefit from intermediate computational state before the system commits to an action or answer.

That is a very different claim.

A reasoning trace can help a system decompose a problem, preserve intermediate conclusions, identify missing information, decide what to verify next, and expose places where search or tools should be used.

Advanced Agents From First Principles 00: When Should You Use an Advanced Agent Architecture?

You built an agent.

It can:

• call tools,
• maintain state,
• plan,
• revise its own work,
• search over alternatives,
• remember useful information,
• and verify whether the requested outcome actually happened.

Now the temptation begins.

You add another model.

Then a critic.

Then a planner.

Then a judge.

Then a router.

Then three specialist agents.

Then a tree search.

An AI agent says:

Done. The task is complete.

That sentence is almost worthless.

The agent may have:

• edited the wrong file,
• changed the right file incorrectly,
• skipped part of the request,
• broken another subsystem,
• failed to save its work,
• misread a tool result,
• passed a stale test,
• inspected the wrong environment,
• or simply decided that its own answer looked convincing.

The central problem is simple:

The system that produced the answer should not be the only system deciding whether the answer is correct.

An AI agent often fails for a surprisingly ordinary reason:

it commits too early.

It finds one plausible next action, follows it, and then spends the rest of the run trying to make that first choice work.

That can look intelligent because the agent keeps reasoning, calling tools, revising plans, and explaining itself.

But underneath, the trajectory may be almost completely determined by an early mistake.

A coding agent chooses the wrong implementation strategy and spends twenty tool calls repairing it.