Perceive-Plan-Act: The Classic Agent Cycle

Most agent guides are wrong about where to start. They push you straight to ReAct — interleave reasoning and action, one tool at a time — as if the older perceive plan act loop were a quaint relic from robotics class. It isn't. For a whole category of tasks, the classic cycle beats the trendy one, and I learned this the expensive way rebuilding an onboarding agent that ReAct kept mangling. Here's the case.

The perceive plan act loop is the original agent shape: perceive the current state, form a complete plan, then act on that plan step by step — re-perceiving only when reality diverges. ReAct fuses these into a tight per-step cycle. That fusion is a strength for open-ended research and a liability for structured, predictable work. This is the story of picking the right one.

The Problem the Team Faced

An HR-tech company had an employee-onboarding agent: given a new hire's role and start date, it was supposed to create accounts, assign training, schedule intro meetings, and file paperwork — around a dozen ordered steps with real dependencies. The account has to exist before you can assign training to it. The manager has to be identified before you can schedule the intro.

Built on a plain ReAct agent loop, it worked about seventy percent of the time. The other thirty percent, it would act, observe, re-reason, and change its mind mid-sequence — assigning training to an account it hadn't finished creating, or scheduling a meeting before resolving the manager. Each step was locally sensible. The overall sequence was a mess. For a compliance-sensitive HR workflow, seventy percent isn't a starting point; it's a liability.

The Wrong Approach

The team's first instinct was to fight ReAct with more ReAct. They wrote a longer system prompt, added ordering rules, begged the model to "complete each step fully before starting the next."

You are an onboarding agent. Complete steps IN ORDER.
Do not start a step until the previous one is fully confirmed.
Available tools: create_account, assign_training, schedule_meeting, ...

What this does: tries to enforce a global order through prompt instructions inside a loop that re-plans every single turn — which is exactly why it keeps failing.

It barely helped. The reason is structural: a per-step reasoning loop re-decides the whole plan on every turn. Every observation is an invitation to reconsider, and a model handed twelve interdependent steps will reconsider, drifting from the order you asked for. You can't prompt your way out of a loop shape that re-plans by design.

The team burned two weeks on prompt variants before accepting this. Each new version fixed a few reorderings and introduced others, because they were fighting the loop's fundamental behavior with wording. The lesson stung: they'd assumed "agent reliability" was a prompt-quality problem, when for this task it was an architecture problem the whole time. No amount of polish on a per-turn reasoning loop makes it stop reasoning per turn.

⚠️ Common mistake: Assuming a wandering agent needs a better prompt. Sometimes the prompt is fine and the loop architecture is wrong. If your task has a fixed, knowable sequence and the agent keeps reordering it, no amount of "please go in order" fixes a loop built to re-plan continuously. Change the loop, not the wording.

The Correct Prompt

The fix was to switch loop shapes. Plan once, up front, then execute the plan step by step — re-planning only if a step actually fails. That's the perceive plan act loop, and it maps perfectly to a task with a known structure.

STAGE 1 — PLAN (one model call):
Given role={role}, start_date={date}, produce an ordered JSON plan:
[{"step": 1, "tool": "create_account", "args": {...}, "depends_on": []},
 {"step": 2, "tool": "assign_training", "args": {...}, "depends_on": [1]},
 ...]
Do not execute anything. Only produce the plan.

STAGE 2 — EXECUTE (loop, no re-planning):
Run steps in order. For each, wait for its depends_on to succeed.
If a step fails, STOP and return to planning for that step only.

What this does: separates planning from execution into two stages, so the full ordered plan is fixed before any action runs, and the execution loop can't silently reorder the sequence.

plan = model.plan(role, start_date)          ,[object Object],
,[object Object], step ,[object Object], topological_order(plan):
    ,[object Object], ,[object Object], deps_satisfied(step, done):
        ,[object Object],
    ,[object Object],:
        results[step.,[object Object],] = tools[step.tool](**step.args)
        done.add(step.,[object Object],)
    ,[object Object], Exception ,[object Object], e:
        plan = model.replan(step, e, done)    ,[object Object],

What this does: executes the fixed plan in dependency order and only re-invokes the planner when a specific step fails — keeping the common case perfectly ordered while still recovering from surprises.

Results and What Changed

Success on the full onboarding sequence went from about seventy percent to the high nineties. The agent stopped reordering steps because the order was decided once, before any action, and the execution loop simply followed it. Failures became local — a single step retried, not the whole plan scrambled.

The token cost dropped too, which surprised the team. ReAct had been re-reasoning about the entire twelve-step plan on every turn — twelve times the planning tokens. Planning once and executing cut that reasoning overhead sharply. Faster, cheaper, and more correct, all from matching the loop shape to the task.

There was a quieter benefit nobody predicted: the plan became a reviewable artifact. Because stage one emitted a full JSON plan before any account was touched, a human could approve the plan for a sensitive hire in seconds — reading twelve ordered steps is far easier than auditing twelve interleaved reasoning turns after the fact. Separating planning from execution didn't just lift reliability; it created a natural checkpoint for human oversight that the fused loop never offered.

⚡ Pro tip: Measure the re-reasoning tax directly. Log planning tokens separately from execution tokens. If planning dominates the bill, you're probably re-deciding work whose structure you already knew — a strong signal to move to a plan-once loop.

⚡ Pro tip: When a task has a fixed, knowable structure — onboarding, deployment checklists, data pipelines — plan once and execute. Save per-step re-reasoning for genuinely open-ended work where you can't know step three until you see step two's result.

How to Apply This to Your Situation

Ask one question of your task: do I know the steps before I start? If yes — the sequence is knowable from the goal — the perceive plan act loop will usually beat ReAct on reliability and cost. If no — each step depends on what the last one revealed — ReAct's per-turn reasoning earns its keep.

Two more tasks that fit the plan-first shape cleanly: a release engineer's deployment agent, where the steps — build, test, stage, promote — are fixed and ordered, and a claims adjuster's intake agent, where each new claim follows the same known checklist. In both, the sequence is knowable from the goal, so re-deciding it every turn is pure waste. Plan the checklist once, execute it, re-plan only the step that actually breaks.

Many real agents want both: a planning stage that lays out the known structure, and a ReAct-style sub-loop inside any step that turns out to be open-ended. The loop shape isn't a religion; it's a tool you match to the shape of the work.

⚡ Pro tip: Don't treat plan-first and ReAct as enemies. The strongest structured agents plan the known skeleton up front, then drop into a small ReAct sub-loop inside any single step that turns out to be open-ended. Outer loop for structure, inner loop for surprise.

The meta-lesson outlasts this one agent: before you tune a single prompt, ask whether your loop shape matches your task's shape. A re-planning loop on a fixed sequence — or a plan-first loop on genuinely open-ended research — will fight you no matter how good the prompts are. Diagnose the shape first. It's the cheapest, highest-impact decision in agent building, and it's the one people skip.

⚡ Pro tip: Even inside a perceive plan act loop, make the plan visible in your logs as structured JSON. When a run fails, you can see exactly which step broke and whether the plan was wrong or the execution was — two very different fixes.

Next Steps

Try the two-stage version on your most structured agent task. Have the model emit a JSON plan with

depends_on

The planning prompt and the execute-in-order skeleton become reusable across every structured agent you build. I keep both saved and versioned in PromptABCD — the plan-stage prompt, the JSON plan schema, the executor — so the next structured workflow starts from the version that already hit the high nineties instead of a blank page and a hunch. The two weeks of prompt-fighting only had to happen once.