Cognitive Architectures for AI Agents: ReAct, Reflexion, and Plan-and-Execute

I've watched an agent pass every check I ran, then fail a different way the moment I stopped watching. When that happens, my first move is usually to bolt on a thinking loop: make it check its own work, or plan every step before it moves. Check which loop fits the failure before you add anything.

The short answer. You add a cognitive architecture on top of an agent that reasons and acts. ReAct reasons and acts one step at a time. Reflexion adds a self-critique pass and needs an outside signal to grade against, or it degrades. Plan-and-execute maps every step before running any, and pays off only when something catches a plan gone wrong.

Architecture	What it adds	Best when	Example
ReAct	Reason, act, observe the result, repeat	The next step depends on what a tool just returned	Search, browsing, multi-step lookups
Reflexion	A self-critique pass between attempts	Something outside the model can grade the attempt	Code review against a failing test, writing against a scored rubric
Plan-and-execute	Every step mapped before any of them run	You can write down the whole sequence in advance	A research pipeline, a fixed multi-stage job

This picks up after how to decide when a job needs an agent instead of one prompt: once you've decided you need an agent, these three are what you can add on top of it, and none of them are free.

What does ReAct add to a base agent loop?

ReAct is the loop most agents run, named or not. Yao et al. describe the mechanism plainly: "reasoning traces help the model induce, track, and update action plans... while actions allow it to interface with external sources... to gather additional information." [1]

The loop does four things, in order:

1. Reason about what to do next, given the task and everything observed so far.
2. Act by calling a tool or taking a step based on that reasoning.
3. Observe whatever the tool or the environment returns.
4. Repeat, feeding that observation into the next round of reasoning, until the task is done.

The smallest real shape of it is one function that loops:

# the shape of a ReAct step, run until the task ends
def react_step(task, history):
    thought = reason(task, history)
    action = choose_tool(thought)
    observation = run_tool(action)
    history.append((thought, action, observation))
    return history

Nothing here checks the agent's own output against a rubric, and nothing plans past the next step. ReAct is the foundation the other two architectures sit on top of.

What does Reflexion add, and when does it go wrong?

Reflexion adds a memory of failure. Shinn et al. describe it as agents that "verbally reflect on task feedback signals, then maintain their own reflective text in an episodic memory buffer" for the next attempt. [2] After an episode ends, the agent writes itself a note on what went wrong, and that note feeds the next try.

Reflexion lives or dies on having a real feedback signal. Google DeepMind tested what happens when that signal is missing, running GPT-3.5 through rounds of self-correction with nothing external to check its answers against. [3]

• GSM8K: 75.9% to 75.1% to 74.7% across correction rounds.
• CommonSenseQA: 75.8% to 38.1% to 41.8%, a 34-point collapse.

Their own words: "LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction." [3]

The lesson isn't that Reflexion is broken. Before you add a reflection pass by default, check what's grading the attempt. If it's the same model checking its own output, that isn't a feedback signal.

Reflexion needs something outside the model to check against:

• A test suite
• A rubric someone else wrote
• A human reviewer

What does plan-and-execute add?

Plan-and-execute splits the job into two roles. A planner maps every step before the first one runs. Executors, the same model or specialists built for each step, then run that plan in sequence.

Microsoft's Magentic-One measured what the planning role is worth by removing it. It's a research benchmark, evaluated on GAIA, AssistantBench, and WebArena rather than live production traffic [4].

• Strip the orchestrator's ledgers, re-planning, and loop detection down to a plain group chat: performance drops 31%.
• Remove individual specialist agents: performance drops 21% to 39%, depending on which one.

The orchestrator's job isn't organizing the steps:

• Keeps a ledger of what's been tried and what came back
• Notices when the plan has gone wrong
• Re-plans from there

If your planner hands the next step a malformed result, you get no warning. The next executor reads that bad data, acts on it, and by the time you see the output the error has compounded through every step in between. Checking a plan's own output before the next step reads it is what closes that gap.

When should you not add any of these?

Most of the time, according to the company that tried it and pulled back. Shopify Sidekick's system prompt grew past 50 tools and became, in their words, "Death by a Thousand Instructions." [5]

Their fix was not a planner and not subagents. It was Just-in-Time instructions: tool-specific guidance returned with the tool's result, instead of front-loaded into the prompt. Two numbers moved:

1. LLM-judge agreement with human raters: Cohen's Kappa 0.02 to 0.61, against a human baseline of 0.69.
2. Syntax validation: about 93% to about 99%. [5]

Their own recommendation: "Avoid multi-agent architectures early: Simple single-agent systems can handle more complexity than you might expect." [5]

Shopify's system prompt had grown past 50 tools and collapsed under its own weight. Adding architecture on top of that fixes nothing; the prompt needed to shrink. Magentic-One's numbers only show up on tasks that genuinely have an ordered sequence of dependent steps, the case Shopify never had.

Run these three questions before you add anything:

1. Can you write down every step in advance? If not, plan-and-execute adds nothing, because the plan will be wrong before the first step runs.
2. Does your reflection pass grade against something outside the model, or is it grading its own output? The DeepMind finding applies to the second case.
3. Is the real problem that your prompt or context is too full, or that the task genuinely has ordered steps a plan needs to track? Shopify's answer was the first one. They shipped without adding architecture at all.

How do you know your architecture choice is working?

The architecture you pick matters less than whether you have a real reliability signal for it. Sierra's τ-bench ran GPT-4o-class agents on realistic support tasks with real policy constraints.

Their finding: "even state-of-the-art function calling agents (like gpt-4o) succeed on <50% of the tasks, and are quite inconsistent (pass^8 <25% in retail)." [6] That gap, the same task run once versus run eight times, is the reliability story a team misses when it only checks a task once and calls it done.

Whichever of these three you add, grading it on pass@k rather than a single run is how you find out it's holding up, rather than trusting the one time you happened to look.

Quick recap

• ReAct reasons, acts, and observes in a loop. It's the foundation the other two sit on top of, not a fourth option.
• Reflexion adds a self-critique pass, and needs an outside signal to grade against. Without one, Google DeepMind measured a 34-point collapse on CommonSenseQA across correction rounds.
• Plan-and-execute maps every step before running any of them. Magentic-One's ablation shows the planner's real value is catching a plan that's gone wrong, not organizing the steps.
• Shopify Sidekick refused more architecture past 50 tools; the problem was a bloated prompt, not task complexity.
• Whichever architecture you pick, measure it on pass@k, not pass@1. Sierra's τ-bench found GPT-4o agents passing under 25% of the time on the same retail task run eight times.

Start Here

The intake at daisyguti.ai/work-with-me is about nine questions and takes a few minutes, held as a live conversation with an AI. It turns your answers into a brief with what you're trying to solve, what you've already tried, and what a working version looks like to you.

I read that and reply with whether one of these architectures fits what you're building, or whether a plainer workflow gets you there faster.

Sources

1. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (submitted October 6, 2022) - https://arxiv.org/abs/2210.03629 - the reason-act-observe loop, in the authors' own words.
2. Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (submitted March 20, 2023) - https://arxiv.org/abs/2303.11366 - the episodic memory buffer mechanism and its dependence on a feedback signal.
3. Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet," Google DeepMind, ICLR 2024 (submitted October 3, 2023) - https://arxiv.org/abs/2310.01798 - the GSM8K and CommonSenseQA self-correction figures and the authors' own conclusion.
4. Fourney et al., "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks," Microsoft Research AI Frontiers (November 7, 2024) - https://arxiv.org/abs/2411.04468 - the orchestrator and specialist-removal ablation figures.
5. Shopify Engineering, "Building Production-Ready Agentic Systems" (August 26, 2025) - https://shopify.engineering/building-production-ready-agentic-systems - "Death by a Thousand Instructions," the Cohen's Kappa and syntax-validation figures, and the multi-agent recommendation.
6. Yao et al., "τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains," Sierra (submitted June 17, 2024) - https://arxiv.org/abs/2406.12045 - the pass@1 and pass@8 (retail) figures for GPT-4o-class agents.