ReAct & Plan-and-Execute

Structured output gave the runtime a reliable shape for one model response. Agent architectures ask the next question: who decides the next step when one response isn't enough?

Agent architectures turn a one-shot model call into a stateful system that can request tools, observe results, and continue. ReAct and plan-and-execute patterns give you two control loops for multi-step product work.

A code assistant that inspects a failed CI job needs to read the error log, check the changed files, explain the failure, and open a rollback proposal if the release broke production. A plain LLM call is passive: it produces tokens, but it doesn't execute side effects on its own. Agent runtimes bridge that gap by treating the model as a reasoning engine that can choose tools, update state, and coordinate multi-step work.

Most product paths should stay deterministic. An agent becomes useful when the next safe step depends on live evidence that can't be enumerated cheaply in advance, and when your runtime can check its effects.

Before the patterns, one reality check that frames everything below. Anthropic's guidance on building effective agents draws a line between two kinds of systems^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/research/building-effective-agents}. A workflow is a system where LLMs and tools follow predefined code paths that you wrote. An agent is a system where the model dynamically directs its own process and tool use, deciding at runtime how to reach the goal. Both are useful. The guidance is blunt: find the simplest pattern that works and add complexity only when it demonstrably improves outcomes, because agentic systems trade latency and cost for flexibility. Stripped down, an agent is "just LLMs using tools based on environmental feedback in a loop." ReAct and Plan-and-Execute are two named shapes of that loop, not a special runtime category. A fixed prompt chain or a single tool-calling call is often the right answer.

Agent loop: An agent needs more than an LLM with tools. It's a loop with state, allowed actions, observations, and runtime boundaries. Some agents also need planning or long-term memory; don't add those components until the task requires them. If the steps are known in advance, a workflow is cheaper and easier to debug.

Why is "agent = LLM + tools" an incomplete mental model?

Answer

Tools are only one part. A reliable agent needs runtime-owned state, validation, enforced budgets, and a way to observe tool results before choosing another action. Planning and long-term memory are optional additions for tasks that need them.

Two ideas you have already met become the agent loop. Chain-of-Thought prompting studied how intermediate reasoning steps in demonstrations can elicit multi-step reasoning before answers.^{[2]Reference 2Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.https://arxiv.org/abs/2201.11903} Function calling lets a model request an action using arguments that your code validates and executes. An agent runtime turns these ideas into a loop: request a next move, execute an allowed tool, record an observation, and repeat. Two useful loop shapes matter most here: ReAct, which decides one step at a time, and Plan-and-Execute, which drafts a roadmap before moving.

What makes the deployment-debugging assistant an agent instead of a single tool call?

Answer

It doesn't know the right action upfront. It must inspect CI status, logs, changed files, and deployment state, then choose the next step from those observations. A single tool call answers one known question. An agent controls a loop where each result changes the next decision.

You need to summarize a changelog, translate the summary, then post it to a fixed release channel. The three steps never change. Workflow or agent?

Answer

A workflow. The steps are fixed and known in advance, so a hard-coded chain of three calls is cheaper, faster, and easier to debug than letting a model decide the path at runtime. Reserve agents for tasks where the next step genuinely depends on what the model observes, like the deployment-debugging case where logs, changed files, and service health can each change the route.

ReAct: reasoning + acting

Why one step at a time?

The ReAct (Reason + Act) pattern is an influential agent loop. Proposed by Yao et al. (2023), it interleaves reasoning traces with actions and observations on the paper's evaluated tasks.^{[3]Reference 3ReAct: Synergizing Reasoning and Acting in Language Models.https://arxiv.org/abs/2210.03629} A reasoning-only response can't inspect a live CI failure. An acting-only policy may issue tool calls without enough task context. ReAct combines a next-step decision with fresh environmental evidence.

A code agent resolving a failed release follows the same loop. It checks the CI failure (Observation), decides the error points at a migration (Reasoning), reads the migration diff (Action), then runs a targeted test before choosing the next step. ReAct applies this observe-decide-act pattern to AI.

The paper writes this pattern as Thought, Action, and Observation. Treat Thought: as explanatory notation, not as a production API contract. OpenAI's current reasoning documentation describes reasoning tokens as hidden output tokens rather than a raw trace returned to the application.^{[4]Reference 4Reasoning modelshttps://developers.openai.com/api/docs/guides/reasoning} Store the observable state you can audit: validated tool requests, tool results, bounded decision notes when a user needs an explanation, and budget usage.

The analogy that fits best is an on-call engineer debugging from live evidence. They read one signal, form a hypothesis, run the next narrow check, and update the route from what came back. ReAct is that loop. It doesn't assume the whole incident path is known upfront. It adapts after every observation.

This visual shows that feedback loop: every observation becomes the state for the next reasoning step.

Why is ReAct a good fit when the failure state is uncertain?

Answer

Because ReAct can postpone commitment. It checks one live fact, updates state, and chooses the next action from what it just learned. If the CI log points at a test regression, it can run the test. If production metrics are already recovering, it can avoid an unnecessary rollback. The control loop stays grounded in the environment.

The ReAct loop

In practice, a user's request triggers repeated next-move decisions, tool execution, and observations until the model returns a final answer or the runtime stops the loop.

A concrete trace

This paper-style ReAct trace asks the agent to triage a failed deployment. The Thought lines make the lesson legible; an application can implement the same control loop without storing private reasoning text.

Notice what happens to state as the loop runs. After the first tool call, the runtime has the goal, the action, and the observation. After another call, it has another evidence record to make available to the next model turn. If every raw result is appended, context grows with the trajectory; long tasks need summaries, external state, or another control pattern. The exact token cost depends on your prompts, tools, and summarization policy.

In the R1842 trace, why does ReAct wait for the CI observation before deciding whether to patch or roll back?

Answer

ReAct chooses each action from the latest state. The CI result determines whether the failure is a test regression, migration bug, flaky dependency, or already-recovered infrastructure issue. Acting before the observation would turn the agent into a guesser rather than a grounded tool user.

What state must the runtime preserve between ReAct turns?

Answer

At minimum, it preserves the original goal, the allowed tools, prior tool calls, tool results, remaining step or token budget, and enough trajectory summary for the model to avoid repeating itself. The model proposes the next action, but the runtime owns durable state.

Building the loop in code

A functional runtime validates each requested move before it executes anything. The model-facing schema in a hosted API can enforce the shape of NextMove; this dependency-free example focuses on application responsibilities: tool allowlisting, step limits, observation storage, and a final answer grounded in those observations.

The model proposes NextMove records. The runtime decides whether a tool is available, whether budget remains, and whether enough evidence exists to return an answer. No free-form private reasoning trace is needed in the audit log.

In the minimal Python loop, which parts are deterministic software and which part is probabilistic?

Answer

Schema validation, tool allowlisting, tool execution, step limits, and observation storage are deterministic runtime code. Model selection of the next move is probabilistic. Reliable agents keep hard guarantees in runtime code instead of relying on model compliance.

When ReAct breaks

ReAct's tight interleaving of decisions and actions creates specific failure modes worth knowing:

Infinite loops. ReAct agents can get stuck repeating the same action when a tool returns unhelpful results. If a search returns no results, the agent might search again with the identical query instead of reformulating. Enforcing a maximum step count and tracking action hashes prevents this from running indefinitely.

Context overflow. Each step may append actions, observations, and summaries to the context window. For tasks requiring many steps, that context can eventually exhaust the model's limit. Strategies include summarizing older evidence, storing full results outside the prompt, or switching to a longer-context model.

Grounding failures. ReAct's key strength is grounding reasoning in actual observations rather than the model's internal beliefs. When a tool returns misleading or incomplete data, the agent can chase a false trail. Reliable implementations include sanity checks on tool outputs before feeding them back as observations.

Observation taint. Tool results, file contents, CI logs, webhooks, and page text are untrusted evidence, not instructions and not authority. Label them with delimiters, redact secrets, and bound size before they re-enter the model. Keep a taint bit or trust tier on each observation record. If any observation on the decision path is tainted, the runtime may allow more narrow reads but must block or HITL high-risk tools. Taint sticks to derived state: a poisoned log must not authorize open_patch or rollback. The same rule later appears in computer-use agents for page banners; name it here because every later agent loop inherits ReAct's observe-act cycle. Pair this with prompt-injection defense and production guardrails.

Interface errors. If the model's requested action doesn't satisfy the expected tool schema, the runtime must reject it. JSON mode only gives valid JSON syntax; it doesn't validate correct tool fields. Use strict tool schemas where supported and validate the resulting arguments and policy in application code.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

A ReAct agent calls get_ci_failure("R1842") three times and receives the same log each time. Which failure mode is this, and what should the runtime do?

Answer

That's an infinite loop or progress failure. The runtime should detect repeated action hashes or repeated intent, stop the loop, and force a strategy change such as inspecting the diff, running a targeted test, escalating, or returning a bounded failure instead of spending more tool calls.

What is the difference between a parsing error and a grounding failure?

Answer

A parsing error means the runtime couldn't read the model's requested action, such as malformed JSON or an unknown format. A grounding failure means the tool call ran, but the observation was misleading, stale, incomplete, or interpreted incorrectly. The first is an interface problem. The second is an evidence problem.

Self-consistency without duplicated effects

Self-consistency samples multiple reasoning paths and selects a common answer, originally for reasoning tasks with a defined final response.^{[6]Reference 6Self-Consistency Improves Chain of Thought Reasoning in Language Models.https://arxiv.org/abs/2203.11171} Applying that idea to an agent requires a boundary: candidate trajectories can inspect fixed, read-only evidence or run in a sandbox, but they shouldn't each open real pull requests, roll back services, or post incident updates. After selecting a proposal, the runtime still applies policy and executes at most one approved effect.

Self-consistency multiplies model and read-only tool work by the number of samples. It can support a reviewable recommendation, but it isn't permission to repeat writes.

Why is self-consistency risky for a ReAct agent that can open PRs, roll back releases, or page teams?

Answer

Each sampled trajectory may execute side effects. Running five trajectories can create five PRs, duplicate incident comments, or trigger multiple rollbacks unless tools are sandboxed, simulated, or protected with idempotency keys. Self-consistency is safest for read-only or cheap verification tasks.

When can self-consistency improve ReAct without creating production risk?

Answer

Use it for read-only tasks with cheap tools and a clear final answer, such as inspecting logs, classifying a failure mode, or drafting a bounded recommendation. For real writes, select one proposal and run the normal authorization and idempotency checks once.

Reflexion: learning from a failed attempt

Self-consistency samples many trajectories in parallel and votes. Reflexion (Shinn et al., 2023)^{[7]Reference 7Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} takes the opposite approach across attempts: when a trajectory fails, the agent writes a short natural-language reflection on why it failed and stores that note in memory, then retries with the reflection added to its context. The original paper calls this "verbal reinforcement learning," because the agent improves through written self-critique rather than weight updates. On the HumanEval coding benchmark, Reflexion reported 91% pass@1, above the 80% GPT-4 baseline reported in the same paper.

The mechanism fits the deployment-debugging example directly. Suppose a ReAct attempt declares a release fixed after reading one stale CI log, and an evaluator flags it as wrong because the targeted test still fails. A Reflexion-style agent records a note such as "verify the current run before proposing a deploy retry," then carries that note into the next attempt. Reflexion works best when three conditions hold: you get a clear pass or fail signal, the notes stay short and task-specific, and retries are allowed. It's a memory technique layered on top of ReAct, not a replacement control loop.

The failure signal comes from an evaluator or environment check, not from the agent deciding that its own unsupported story sounds convincing.

How is Reflexion different from self-consistency, and what does it require to work?

Answer

Self-consistency runs independent trajectories and votes on the answer; the runs do not learn from each other. Reflexion is sequential: a failed attempt produces a written lesson stored in memory, and the next attempt reads that lesson. It requires a clear failure signal, the ability to retry, and short task-specific reflections rather than long rambling self-criticism.

Plan-and-Execute

Why plan first?

ReAct is useful, but it's local: it chooses the next action from the latest observation rather than from a committed global plan. For complex tasks such as "audit every failed workflow from yesterday and draft recovery actions," a ReAct agent might get lost in one flaky test and forget the overall release-readiness workflow.

If ReAct is like an on-call engineer resolving the next visible signal, Plan-and-Execute is like an incident runbook. First, the planner maps the recovery steps, then executors handle CI checks, log reads, owner lookups, patch drafting, and rollout decisions in order.

Plan-and-Execute decouples planning from execution. It's a practical runtime pattern related to plan-first prompting techniques such as Plan-and-Solve,^{[8]Reference 8Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models.https://arxiv.org/abs/2305.04091} but it doesn't imply one standard protocol. A plan may be a linear checklist or a dependency graph:

1. Planner: An LLM generates a multi-step plan based on the user request.
2. Executor: An agent (often a ReAct agent itself) executes each step of the plan.
3. Replanner: The system reviews the results and updates the plan if necessary.

These roles don't have to be different models. Small systems often use one model in separate planning and execution prompts, while cost-optimized systems route planning to a stronger model and execution to cheaper specialists.

What is the planner responsible for, and what should it avoid doing?

Answer

The planner owns decomposition, sequencing, dependencies, and success criteria. It should avoid doing hidden execution work or inventing facts. If a plan step needs CI data, the planner should create a step to fetch that data, not guess the failure status.

This visual shows the key separation: a planner owns the global shape, executors own local work, and verifier/replanner steps keep the plan from going stale.

The Plan-and-Execute flow

This architecture cleanly separates planning from execution. A planner drafts the initial steps, executors work through them, and a validation loop checks whether the remaining plan still makes sense. That global plan reduces goal drift on long tasks, but it doesn't eliminate it. A weak initial plan can still send every executor in the wrong direction.

The same release, planned

Return to the R1842 example. A Plan-and-Execute agent would first emit a plan, then execute it:

Planner output

Executor trace

The executor for Step 4 might itself be a small ReAct agent that reasons about the inputs and picks the best action. That's a common hybrid pattern: a global planner keeps the big picture, while local ReAct loops handle individual decisions.

A useful plan records dependencies rather than pretending all five steps are sequential. In this release example, CI metadata, changed files, and deployment health can be fetched independently. The action decision must wait for all three.

This representation exposes concurrency without overstating it. The first three reads can run together only if the runtime supports concurrent execution and the tools don't share a conflicting resource.

Why might Step 4, decide_action(...), be its own ReAct loop?

Answer

The decision may need extra checks after reading the first inputs: failing test output, migration history, service health, or rollback policy. A local ReAct loop can gather those facts without losing the global plan that says the task must end with one confirmed recovery action.

Comparing the two approaches

Choosing between ReAct and Plan-and-Execute requires balancing cost, task complexity, and reliability. ReAct is useful for short, evidence-dependent decisions, but it can drift on long tasks because it lacks an explicit global plan. Plan-and-Execute gives you that plan, but it can produce brittle execution if you don't pair it with validation and replanning.

Read it as a gate, not a spectrum. First ask whether a fresh tool result can change next safe action. If not, planner overhead buys nothing and ordinary workflow code is better. If yes, then ask how much route is known upfront: ReAct for discovered paths, Plan-and-Execute for stable decomposition, hybrid when both appear in same task.

You need to audit all failed workflows from yesterday, group them by failure mode, draft recovery actions, and send one summary. Which architecture fits better, and why?

Answer

Plan-and-Execute fits better because the work has a clear global structure and decomposable steps. A planner can map the audit, grouping, recovery drafting, and synthesis phases, while executors handle local checks. ReAct may drift because it only sees the next action at each turn.

Why doesn't Plan-and-Execute automatically reduce latency?

Answer

The planner is still a serial step, and dependent executor steps still wait for prior outputs. Latency drops only when the plan exposes truly independent work, such as checking failed workflows for different services in parallel, and when the runtime can run those executors concurrently.

When to use each

Use ReAct when:

• The environment provides immediate feedback after each action
• Task length is bounded by an explicit runtime budget
• You need to ground decisions in live data (search, database lookups)
• The optimal path isn't predictable upfront

Use Plan-and-Execute when:

• The task has a clear overall structure (audit failed workflows, draft a recovery report)
• Steps have dependencies that benefit from upfront sequencing
• You can parallelize independent sub-tasks
• Executor steps are well-scoped and locally checkable (running tests, scraping pages, querying APIs with known schemas)

What question should you ask before choosing Plan-and-Execute?

Answer

Ask whether the task has a stable global structure that can be decomposed before execution. If the answer is yes, planning helps. If every useful next step depends on the previous observation, a ReAct loop is usually simpler and more grounded.

The brittleness problem

Plan-and-Execute's main weakness is the brittleness of the initial plan. If the planner misinterprets the user's intent, the entire execution pipeline is misaligned. Worse, downstream executor steps often depend on outputs from earlier steps, so a wrong assumption in Step 1 can invalidate Steps 2 through N. A ReAct loop gets an earlier opportunity to react to new evidence, but it can still repeat a bad decision without runtime checks.

Production implementations address this by:

• Constraining the planner's output format: Use structured prompts that limit the planner to a fixed set of step templates rather than free-form generation.
• Adding a validation step: After the planner generates the initial plan, a second pass checks that each step is achievable and that prerequisites are satisfied.
• Triggering replanning early: Rather than waiting for an executor to fail, check intermediate outputs against the original goal and replan if the delta exceeds a threshold.

When evidence breaks an assumption, patch only unfinished work. The completed CI query remains an observation; a revised plan shouldn't issue the same write again.

An executor discovers that the CI API is down, but the original plan still says "fetch CI logs for every failed workflow." What should happen next?

Answer

The system should replan from the current state instead of blindly following the stale plan. The revised plan might use cached logs, mark affected runs for later retry, or escalate the CI-specific subset while continuing independent steps.

What should a replanner patch: the whole plan or the remaining plan?

Answer

Usually the remaining plan. Completed steps are evidence, and restarting them wastes time or creates duplicate side effects. The replanner should keep valid outputs, mark failed assumptions, and update only the steps that still depend on changed state.

How tool calls flow

Calling a tool is shorthand. The side effect still happens in your runtime (your Python or TypeScript code). At the API boundary, the model may emit raw JSON, a structured tool-call object, or another structured output rather than plain text.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs} Your application is the part that validates arguments, executes the external call, and feeds the result back into the next model turn.

To make this work, the LLM needs to know exactly what tools are available and how to use them. In practice, the runtime passes structured tool definitions either in the prompt or through the provider's tool-calling API. Those definitions are usually JSON-schema-like rather than the full JSON Schema spec, and the model uses the field descriptions, enums, and required keys to construct a valid request.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

Tool use connects model decisions to fresh, authorized evidence and controlled effects. A CI-status tool can return the latest failed step; a write tool can open a rollback proposal only after application policy approves it.

Tool definition

Tools need an argument contract so the LLM knows the allowed request shape. Tool-calling APIs can expose such schemas directly to the model. In a supported strict schema mode, the provider enforces the declared structure and types. The application still validates authorization, resource existence, semantic constraints, and policy, including whether this actor may inspect the requested CI run.

This example deliberately leaves include_logs optional because it's an application-level schema. If you submit a schema in OpenAI strict mode, every property must appear in required; represent a conceptually optional field with a nullable type instead.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

The execution loop

The underlying mechanics of "Tool Use" involve a hidden round-trip handled by your application:

1. User: "Why did CI run R1842 fail?"
2. LLM: Returns a tool call record or JSON such as {"tool": "get_ci_status", "args": {"run_id": "R1842"}}
3. Runtime: Pauses generation. Parses the tool call payload. Calls API. Gets "failed: migration-test duplicate column".
4. Runtime: Feeds the result back as a tool-result message containing "failed: migration-test duplicate column"
5. LLM: "Run R1842 failed in migration-test because the migration re-adds an existing column."

This hidden round-trip relies entirely on your application code. The LLM doesn't execute the API request itself; it merely generates the structured request representing the intended call. The host application needs to securely execute the external call, manage connection timeouts, handle authentication, and then format the response back into a format that the LLM can ingest for its next reasoning step.

Common mistake: Treating schema validation as sufficient. Constrained outputs reduce syntax errors, but your runtime still needs to handle semantically bad arguments, missing auth, and tool timeouts.

A write needs another boundary: retrying the same agent turn must not create duplicate effects. Give each intended effect an idempotency key owned by your application, not invented afresh on every model retry.

The model emits a valid tool call schema: get_ci_status({"run_id": "R1842"}). Name two problems that can still happen after schema validation passes.

Answer

The run may not belong to a repository the actor can inspect, the API may time out, the run ID may be stale or nonexistent, the tool may return incomplete data, or the action may violate policy. Schema validation checks shape, not all semantics or runtime conditions.

Why is "the model called a tool" technically imprecise?

Answer

The model emitted a tool-call request. The host runtime parsed it, authorized it, executed code or an API request, captured the result, and sent a tool-result message back. Tool execution belongs to application code, not to the model itself.

When agents break

An unconstrained loop can spend far beyond the intended request budget or issue duplicate writes. Production systems need runtime controls before an agent is allowed to affect deployments, repositories, or incident communications.

Agents operate in dynamic environments where external state can change between steps. When a tool returns an unexpected format, or an API call times out, a naive agent might blindly retry the exact same action or invent a response. Because an observation influences later moves, errors can compound. A single unsupported conclusion can derail the execution plan.

To build reliable agents, engineers need strong guardrails at the runtime layer. This means treating the LLM as an unreliable sub-component rather than a deterministic program. You need to validate all structured outputs, enforce hard step and token budgets, and return actionable error messages back to the model when a failure occurs.

Why are step caps and budgets runtime controls rather than prompt controls?

Answer

A prompt instruction can ask the model to stop, but only runtime code can enforce a hard maximum. Step caps, token budgets, wall-clock timeouts, and API quotas must live outside the model so a malformed or looping trajectory can't ignore them.

Which failure mode is characteristic of Plan-and-Execute, and which one is common in ReAct?

Answer

Brittle upfront plans are characteristic of Plan-and-Execute because they can misalign downstream executors. Repeated-action loops are common in ReAct because the model can keep choosing the same next action after unhelpful observations. Either architecture still needs runtime controls.

Detecting cycles in code

To prevent loops, track normalized actions in a short recent window. The detector below catches repeated single actions and short alternating patterns. A production detector also needs progress signals, because an agent can repeat a valid read while receiving new pages of results.

Why is even the improved cycle detector above incomplete?

Answer

It catches exact normalized patterns, but not semantically equivalent arguments or repeated actions that legitimately produce new pages of progress. Production runtimes combine pattern checks with progress markers, budgets, and task-specific stop conditions.

Try it yourself

The partial ReAct trace below comes from a different release. Three steps are shown, but the fourth step contains a mistake. Read the trace, identify what goes wrong, and decide what the agent should have done instead.

What went wrong? The agent compared a healthy region on an older commit with an unhealthy region on the new commit, but never verified that the affected region was rolled back or recovered. A different region's health doesn't prove the incident is resolved. The agent should have checked the service health in us-east after rollback or kept the incident open.

The fix: Add an enforced verify_region_recovered precondition before the close action. A prompt reminder is useful context, but it can't block a write when the model ignores it.

Assume the monitoring system returns current latency for the affected region. The runtime can block closure until the target region meets its recovery threshold.

What invariant was missing before close_incident?

Answer

The agent needed a precondition: the affected region must meet the recovery threshold. A healthy region on another commit is useful context, but it is not evidence that the failing region recovered.

Agent architecture choices

• Start with the simplest pattern. An agent is "just LLMs using tools based on environmental feedback in a loop"^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/research/building-effective-agents}. If the steps are known in advance, a fixed workflow or a single tool-calling call beats an autonomous loop on cost, latency, and debuggability. Reach for ReAct or Plan-and-Execute only when the next step genuinely depends on what the model observes.
• ReAct fits short, interactive tasks whose next move depends on fresh evidence. In practice, start with a small tool-calling loop and add orchestration only when evaluations justify it.^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/research/building-effective-agents}
• Plan-and-Execute fits work with a stable global structure and checkable local steps. It separates planning from execution while requiring validation and replanning.
• Reflexion^{[7]Reference 7Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} adds a memory of written lessons from failed attempts on top of a ReAct loop. It's a refinement, not a separate control architecture.
• Multi-agent systems can use a Plan-and-Execute shape when planner, executor, and verifier roles become separate workers. These control-loop terms set up later orchestration work.
• Memory matters for both architectures. ReAct trajectories grow one observation at a time, while Plan-and-Execute systems need somewhere to store intermediate outputs between phases. A dedicated article on agent memory and persistence follows later in the path.
• Observability needs owned state. Log validated tool calls, planner outputs, redacted observations with taint tags, approvals, retries, and budget usage. Don't make raw chain-of-thought your audit artifact.
• Plan-and-Execute inherits the same taint rule: tag planner inputs by trust, and never let plan text grant tool authority. Privileged steps still hit tool policy even if a checklist item "says" to run them.