Agent Architectures: ReAct, Plan-and-Execute & Reflection

Two people fix a broken washing machine. The first pokes at it, sees what happens, pokes somewhere else — reacting to each finding. The second reads the symptoms, writes a checklist, then works through it. Neither is wrong; they suit different problems. Agent architectures are exactly this choice, with proper names attached — ReAct, Plan-and-Execute, Reflection — and interviewers use those names as shorthand for whether you understand agent design or just the vocabulary.

ReAct — the default pattern

ReAct = Reasoning + Acting, interleaved. Before each action the model writes a short thought about what it's doing and why; after each action it reads the result as an observation. Repeat until the goal is met.

Read that trace and notice what it is: a diary. The agent never plans beyond the next step, because each observation may change what the next step should be. That's the strength — it adapts to whatever it finds — and the cost, since every step pays for reasoning tokens and another round trip.

Why writing the thought actually helps

It looks like theatre. It isn't, for two reasons. Better choices: forcing the model to state a reason before acting is chain-of-thought applied to tool selection — it commits to a rationale, which measurably reduces "grabbed the first plausible tool" errors. Debuggability: when an agent does something bizarre, the thought line tells you why. Without it you have a sequence of tool calls and no explanation — and agent bugs live in the middle of runs, not at the end.

The reasoning trace is the difference between an agent you can debug and one you can only restart.

Plan-and-Execute — decide the route first

Instead of one step at a time, the model produces a full plan upfront, then executes the steps (usually with a cheaper model), re-planning if a step fails.

plan = planner.create(goal)
# ["search flights DEL->BLR for tomorrow",
#  "pick cheapest morning option",
#  "check weather in Bangalore",
#  "summarize for the user"]

for step in plan:
    result = executor.run(step, tools=TOOLS)
    if result.failed:
        plan = planner.replan(goal, done_so_far, failure=result)  # adapt
        continue

Advantages: fewer expensive reasoning calls (one plan, cheap execution), and — the underrated one — the plan is a visible artifact a human can approve before anything runs. For agents that touch real systems, that's a genuine safety feature. Disadvantage: a plan written before seeing any results can be wrong from step one, which is why re-planning is part of the pattern rather than an optional extra.

Reflection — draft, critique, revise

For output-quality tasks — writing, code, analysis — the agent produces a draft, then critiques its own work against explicit criteria, then revises. It works because generating and evaluating are different tasks: a model reviewing a finished draft notices problems it didn't avoid while writing it.

draft = model.write(task)
for _ in range(2):                         # cap the rounds - quality plateaus
    critique = model.review(draft, rubric=BRAND_RULES)
    if critique.is_acceptable:
        break
    draft = model.revise(draft, critique)

Two practical notes: cap the rounds (improvement flattens fast, usually after one or two), and give the critic a rubric — "make it better" produces waffle, while "check: every claim cited, under 200 words, no competitor names" produces fixes.

Wait — which one do I actually use?

Real systems combine them, because different phases of one task want different patterns. "Research this company and write a brief" splits cleanly: the research half benefits from Plan-and-Execute (the sub-questions are knowable upfront — financials, news, competitors, leadership), and the writing half benefits from Reflection (draft, critique against the brief's requirements, revise). ReAct handles the genuinely unknown middle — a search that returns something surprising and changes the next question.

Rules of thumb: unknown path → ReAct; knowable steps, or human approval needed → Plan-and-Execute; output quality matters → Reflection; fixed path → not an agent at all.

Step limits and budgets — non-negotiable

Every pattern here can loop forever. The classic failure isn't dramatic: the agent simply can't achieve the goal, so it tries variation after variation — rephrasing the same failing search, oscillating between two tools — while your bill grows.

MAX_STEPS = 8
MAX_COST_RS = 5.0

for step in range(MAX_STEPS):
    if run.cost_so_far > MAX_COST_RS:
        return escalate("budget exceeded", trace=run.history)
    ...
else:
    return escalate("step limit reached", trace=run.history)

An agent without a step limit is an unbounded bill waiting for a bad day. Note the escalation carries the trace — the human picking it up shouldn't have to start from zero.

Selection-round radar: "Explain ReAct" is the most-asked question in this lesson — answer with the thought/action/observation cycle plus why the thought improves tool choice and debugging. Expect the follow-up "how do you stop it looping forever?" and answer with step limits, cost budgets and escalation-with-context.

Common mistakes

• Using ReAct for a task whose steps are known — paying reasoning tokens for decisions nobody needed.
• Reflection with a vague rubric — the critique becomes praise.
• Plan-and-Execute without re-planning, so one wrong assumption ruins the run.
• Discarding the reasoning trace, then being unable to debug anything.
• No step limit or cost budget.
• Escalating without the trace, so a human restarts the whole investigation.

Quick recap

Practice Zone — PYQs from real selection rounds

Six MCQs and two tasks — write a full ReAct trace including the moment the agent stops to ask the user, then match four tasks to patterns.

Q1Agent architecturesmedium

The ReAct pattern interleaves:

Asked in

aRetrieval and cachingbReasoning (a written thought about what to do) with Acting (a tool call), then observing the result — repeated until donecRetraining and evaluationdTwo models debating

Q2Agent architecturesmedium

Plan-and-Execute differs from ReAct because:

Asked in

aIt doesn't use toolsbIt creates a full multi-step plan upfront, then executes the steps — instead of deciding one step at a timecIt requires two different modelsdIt cannot handle failures

Q3Agent architecturesmedium

The Reflection pattern means:

Asked in

aThe agent mirrors the user's tonebThe agent critiques its own draft output against criteria and revises it before returning — a generate-then-review loopcThe agent logs its actionsdTwo agents swap roles

Q4Agent architectureshard

Which pattern best suits: "research this company and write a two-page brief"?

Asked in

aPure ReAct with no planningbPlan-and-Execute for the research steps, plus Reflection on the written draftcA single LLM calldReflection only

Q5Agent architecturesmedium

Why do agent loops need a hard step limit?

Asked in

aTo comply with API termsbBecause a confused agent can loop indefinitely — repeating failed calls or oscillating between steps — burning latency and money with no resultcBecause models can only handle 10 callsdTo make the code shorter

Q6Agent architecturesmedium

What is the main downside of writing out reasoning at every step (ReAct)?

Asked in

aIt makes the agent less accuratebIt costs tokens and latency on every iteration, which matters when steps are numerous or the task is simplecIt prevents tool usedIt cannot be logged

Hands-on tasks:

FAQ

Next lesson: the toolkit most teams build on — Lesson 4: LangChain Basics →