Agents that plan and agents that react

Some agents decide the whole sequence up front and then execute it. Others take one step, look at the result, and decide the next. Both are reasonable. They fail in opposite ways, and matching the shape to the task saves a great deal of trouble later.

What planning gives you

A plan made before execution can be inspected before anything happens. That is a considerable governance advantage: you can check the intended sequence against policy, estimate cost, and stop it before the first action rather than during the fourth.

Plans are also legible after the fact. When something went wrong, the record shows what the agent intended, which is usually more informative than a sequence of actions with no stated purpose.

The cost is rigidity. A plan is built on a snapshot of the world, and the world moves. Step four assumes the state that existed before step one, which may no longer hold.

What reacting gives you

A reactive agent sees what actually happened before choosing what to do next, so it handles surprise naturally. Tasks with unpredictable intermediate states suit it.

The cost is unpredictability of a different kind. Nothing can be inspected in advance because nothing was decided in advance. Cost is unbounded until a limit stops it. And the same input can produce different paths on different days, which makes evaluation harder and reproduction of a failure harder still.

How they fail

A planning agent fails by completing a plan that stopped making sense at step two. The output is internally consistent, arrives confidently, and is wrong in a way that takes a person time to unpick.

A reactive agent fails by wandering. It pursues a reasonable-looking path, then another, accumulating cost and producing partial work. It rarely produces a confidently wrong final answer; it produces an expensive nothing.

Neither failure is worse in general. One is worse in your specific context, and that is the thing worth deciding.

How we would choose

If the task has a stable structure and the governance requirement is high, plan. Inspecting intent before execution is worth the rigidity, and most business processes are more stable than they feel.

If the task genuinely cannot be sequenced in advance, react, but constrain it: a hard step limit, a budget that blocks, and a checkpoint where a person confirms before anything with consequence happens.

In practice the useful shape is usually a plan with re-planning permitted at defined points, rather than either pure form.

Where situation awareness fits

Oran 3.6 tracks what has already happened within a run and what changed underneath it. That directly addresses the planning failure: a step is not repeated if it already succeeded, and a step is flagged rather than executed if the record it depends on has moved.

It does not remove the trade-off. It removes the most common and most expensive version of it.

What to measure either way

Cost per completed outcome rather than per run, because a reactive agent that half-finishes three times has cost you three runs and produced nothing. Step counts, so wandering is visible before the budget stops it. And retries separately from successes, because they are the same failure billed twice.

Next

The Agent Orchestration System pages cover planning, policy enforcement and budgets. The versions page covers what each Oran version added, including situation awareness.