ReAct & Plan-and-Execute

Suppose a deployment fails after a code change. You need to check the continuous-integration (CI) run, inspect changed files, test a hypothesis, and decide whether to patch, roll back, or wait. A single model response can list those actions. It can't see the result of the first check and safely choose the second.

That's the jump from structured output. A schema gives the runtime a reliable shape for one response. Agent architectures add a control question: who chooses the next step when new evidence changes the situation?

ReAct and Plan-and-Execute name two ways to answer that question. ReAct picks one tool from the latest evidence. Plan-and-Execute drafts a route, runs bounded steps, and replans when evidence breaks an assumption. In both designs, the model proposes; your agent runtime validates, executes, and stops the loop.

Before choosing either pattern, keep the boundary clear. A plain LLM call produces tokens, but it doesn't execute side effects on its own. Most product paths should stay deterministic. An agent earns its complexity when the next safe step depends on live evidence you can't enumerate cheaply in advance, and when the runtime can check those effects.

Anthropic's guidance on building effective agents separates two kinds of systems.^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/engineering/building-effective-agents} A workflow is a system where LLMs and tools follow code paths that you wrote. An agent is a system where the model dynamically directs its process and tool use at runtime.

Both can be useful. Start with the simplest pattern that works, then add complexity only when it improves outcomes enough to justify its latency and cost. In short, an agent is "just LLMs using tools based on environmental feedback in a loop." ReAct and Plan-and-Execute are named shapes for that loop, not special runtime categories. A fixed prompt chain or one 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 from earlier lessons supply pieces of the loop. Chain-of-Thought prompting showed that intermediate reasoning steps in demonstrations can elicit multi-step reasoning before an answer.^{[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 with arguments that your code validates and executes. The function-calling lesson covered that request shape.

The runtime joins those pieces: request a next move, execute an allowed tool, record an observation, and repeat. ReAct decides one step at a time. Plan-and-Execute drafts a route 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: choose the next move

Let evidence choose the next action

The ReAct (Reason + Act) pattern interleaves a next-step decision with a tool action and its observation. Yao et al. (ICLR 2023) showed that this lets a model update its route from the environment instead of relying on reasoning-only or acting-only prompts.^{[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 puts the two together: a code agent checks the CI failure, reads the migration diff it points toward, and runs a targeted test before choosing what to do next.

The paper labels the three parts Thought, Action, and Observation. Treat Thought: as explanatory notation, not as a production API contract. OpenAI's reasoning docs describe reasoning tokens as hidden output tokens that still occupy the context window and are billed as output. You can request a summary, but the raw trace isn't an application audit log.^{[4]Reference 4Reasoning modelshttps://developers.openai.com/api/docs/guides/reasoning}

Store the state you can audit: validated tool requests, tool results, bounded decision notes when a user needs an explanation, and budget usage. That record is enough to explain what the runtime did without treating private reasoning text as an audit artifact.

Operationally, the loop is simple: read one signal, form a hypothesis, run the next narrow check, and update the route from what came back. ReAct doesn't assume the whole incident path is known upfront. It adapts after every observation.

🔬 Research insight: Yao et al. evaluated ReAct on HotpotQA, FEVER, ALFWorld, and WebShop. On the two interactive tasks, few-shot ReAct (one or two in-context examples) beat imitation and reinforcement-learning methods trained on thousands to hundreds of thousands of episodes, with absolute success-rate gains of 34 percentage points on ALFWorld and 10 on WebShop. Those are 2023 paper numbers on those benchmarks, not a claim about today's coding agents.

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.

A concrete trace

A user request becomes a loop of next-move decision, tool execution, and observation until the model returns an answer or the runtime stops. Read the trace below as a small release investigation: each observation narrows the next move, and the final write waits for a verification result.

The Thought lines make the paper-style trace readable. An application can run the same control loop while storing only observable state and bounded decision notes, not private reasoning text.

State accumulates as the loop runs. After the first tool call, the runtime has the goal, the action, and one observation. The next model turn receives that record and proposes another move.

Appending every raw result forever makes the prompt grow with the trajectory. Long tasks need summaries, external state, or another control pattern. 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 executing anything. The model-facing schema can enforce the shape of NextMove; the dependency-free example below keeps the rest in application code.

Pass it a list of proposed moves and an allowlist of tools. It returns either a grounded answer or a bounded stop message, along with the observations the runtime collected.

The output makes ownership concrete. The model proposes NextMove records; the runtime checks tool availability, remaining budget, and evidence before returning 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.

Where the loop needs guardrails

The same tight feedback loop that makes ReAct useful also exposes a few predictable failure modes. Each one points to a runtime boundary rather than a better-sounding prompt.

Infinite loops

ReAct agents can get stuck repeating an action when a tool returns an unhelpful result. A search with no results may trigger the identical search again instead of a reformulation. Enforce a maximum step count and track action hashes so the loop stops or changes strategy.

Context overflow

Each step may append actions, observations, and summaries to the context window. A long task can exhaust that limit before it reaches a useful conclusion. Summarize older evidence, keep full results outside the prompt, or choose a model with a longer context when those trade-offs fit the task.

Grounding failures

ReAct grounds the next move in observations rather than the model's internal beliefs. That grounding can still fail when a tool returns misleading or incomplete data, sending the agent down a false trail. Add sanity checks before tool output becomes an observation.

Observation taint

Tool results, file contents, CI logs, webhooks, and page text are untrusted evidence, not instructions or authority. Delimit them, redact secrets, and bound their size before they re-enter the model.

Keep a taint bit or trust tier on each observation. If any observation on the decision path is tainted, the runtime may allow narrow evidence reads, but it must block or route high-risk tools through human-in-the-loop (HITL) review. Taint follows derived state: a poisoned log can't authorize open_patch or a rollback.

This rule will matter again in computer-use agents, where page banners become observations. Pair it 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 gives valid JSON syntax, but it doesn't validate tool fields. Use strict schemas where supported, then validate arguments and policy in application code.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

The small gate below makes the trust boundary visible: a tainted observation can support a narrow read, but it can't authorize a high-risk write.

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.

Keep self-consistency read-only

Self-consistency samples multiple reasoning paths and selects a common answer. It was introduced 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} In an agent, candidate trajectories may inspect fixed, read-only evidence or run in a sandbox.

They shouldn't each open real pull requests, roll back services, or post incident updates. After a proposal wins the vote, 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. That extra work can produce a more 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 and votes. Reflexion (Shinn et al., 2023)^{[7]Reference 7Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} takes a sequential path across attempts: when a trajectory fails, the agent writes a short reflection on why it failed, stores that note in memory, and retries with the note in context. The original paper calls this "verbal reinforcement learning" because the agent improves through written self-critique rather than weight updates.

On HumanEval, the paper reports 91% pass@1 for Reflexion versus an 80% GPT-4 baseline in the same table. That number comes from iterative retries with compiler or self-generated tests, not a single sample. Treat it as evidence that evaluated feedback can help retries, not as a current leaderboard score.

The deployment-debugging example makes the mechanism concrete. Suppose a ReAct attempt declares a release fixed after reading a stale CI log, but an evaluator finds that the targeted test still fails. A Reflexion-style agent records "verify the current run before proposing a deploy retry" and carries that note into the next attempt.

Reflexion needs three things: a clear pass or fail signal, short task-specific notes, and permission to retry. 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 don't 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. On a task such as "audit every failed workflow from yesterday and draft recovery actions," it might spend the whole run on one flaky test and lose the release-readiness objective.

Plan-and-Execute keeps that objective visible. A planner maps the recovery steps, executors handle CI checks, log reads, owner lookups, patch drafting, and rollout decisions, and a later check decides whether the route still fits the evidence.

Plan-and-Execute separates planning from execution. It's 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 prescribe one protocol. HuggingGPT is an early planner-then-executor system: a controller LLM decomposes the request and selects specialist models, an execution stage runs those calls, and a later stage summarizes.^{[9]Reference 9HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face.https://arxiv.org/abs/2303.17580} Anthropic's orchestrator-workers workflow sits in the same family: a central model decomposes, workers execute, and results are synthesized.^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/engineering/building-effective-agents}

A plan can be a linear checklist or a dependency graph. The useful roles are:

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. A small system can use one model in separate planning and execution prompts. A cost-optimized system can 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 shouldn't do hidden execution work or invent facts. If a plan step needs CI data, the planner should create a step to fetch that data, not guess the failure status.

R1842 makes the separation visible. Three independent reads can fan out, the recovery decision waits for all three, and a later failure patches only unfinished work.

The same release, planned

A planner drafts initial steps, executors work through them, and a validation loop checks whether the remaining plan still fits. The 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.

Return to R1842. First read the planner's proposed route. Then compare each executor result with the assumption behind that step.

Planner output

Executor trace

Step 4 might itself use a small ReAct agent. That's the hybrid pattern: a global planner keeps the big picture, while a local loop gathers whatever extra evidence the decision needs.

A useful plan records dependencies instead of pretending every step is sequential. In this release, CI metadata, changed files, and deployment health can be fetched independently. The action decision must wait for all three.

The output exposes possible concurrency without promising it. The first three reads can run together only when 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.

Compare the control loops

The choice turns on task shape, not a universal winner. ReAct suits short, evidence-dependent decisions, but it can drift on long tasks without a global plan. Plan-and-Execute gives you that plan, but it can execute a bad assumption at scale unless validation and replanning sit beside it.

Read the figure as a gate, not a spectrum. First ask whether a fresh tool result can change the next safe action. If not, planner overhead buys nothing and ordinary workflow code is better. If yes, ask how much of the route is known upfront.

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.

Match the pattern to the task

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.

When the first plan meets new evidence

Plan-and-Execute's main weakness is a brittle initial plan. If the planner misreads the user's intent, every executor can follow the wrong route. A wrong assumption in Step 1 can invalidate Steps 2 through N because later steps depend on its output. ReAct gets an earlier chance to react, but it can still repeat a bad decision without runtime checks.

Three controls contain that risk:

• 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: Check intermediate outputs against the original goal instead of waiting for an executor to fail, then replan if the delta exceeds a threshold.

When evidence breaks an assumption, patch only unfinished work. A completed CI query remains a valid observation, so 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.

Other topologies for other uncertainty

ReAct and Plan-and-Execute both move forward. ReAct chooses the next action greedily; Plan-and-Execute follows a dependency graph and patches unfinished nodes after a failure. Two other shapes help when the uncertainty looks different: Router-Delegator for known categories, and Language Agent Tree Search (LATS) for branching search with lookahead and backtracking.

Router-Delegator: single-turn intent dispatch

Suppose incoming requests already fall into three routes: database migration, CI failure triage, or read-only documentation lookup. A multi-step agent would spend its first turns rediscovering a choice your application already knows how to make.

A Router-Delegator architecture classifies intent in one model turn and delegates execution directly to a specialized handler, deterministic workflow, or dedicated sub-agent. The router needs three checks:

1. Classify Intent: An LLM or lightweight classifier inspects the input query against a discrete set of allowed routes.
2. Confidence Check: If classification confidence meets a runtime threshold, dispatch to the designated handler.
3. Fallback: If ambiguous or low-confidence, route to a triage agent or request clarification from the user.

Why use a Router-Delegator before initiating a ReAct or Plan-and-Execute agent?

Answer

Routing prevents over-engineering. If a query maps cleanly to an existing deterministic script or dedicated pipeline, routing dispatches directly in one turn without spending time or tokens generating plans or exploratory tool loops.

Language Agent Tree Search (LATS): keep alternatives alive

ReAct decides greedily at each step, and Plan-and-Execute assumes forward linear or DAG progression. For complex code generation, theorem proving, or multi-hop debugging, a greedy choice can lead down a dead end and force an expensive restart.

Language Agent Tree Search (LATS) (Zhou et al., ICML 2024)^{[10]Reference 10Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Modelshttps://arxiv.org/abs/2310.04406} keeps alternatives alive. It treats reasoning, acting, and planning as one search problem: explore agent trajectories as a tree guided by Monte Carlo Tree Search (MCTS).

At an R1842 root, consider three candidate actions: roll back now, inspect the CI diff, or retry deploy. The code below gives retry_deploy only one visit and a low average value, yet UCT can still select it because rarely visited branches need exploration. That intuition comes before the formula.

LATS maintains a tree of states instead of one trajectory. Each node represents an action or observation, and each edge represents a state transition. One iteration has four phases:

1. Selection: Starting at the root, traverse the tree by choosing child nodes that maximize the Upper Confidence Bound for Trees ($UCT$):

$UCT(s, a) = Q(s, a) + c \sqrt{\frac{\ln N(s)}{N(s, a)}}$

Here $Q(s, a)$ is the estimated value of taking action $a$ in state $s$, $N(s)$ is the visit count of parent state $s$, $N(s, a)$ is the visit count of the specific action edge, and $c$ is an exploration parameter (often $\sqrt{2}$). $UCT$ balances exploiting high-scoring known paths ($Q$) against exploring rarely visited alternatives ($N$).

1. Expansion: Sample $k$ alternative thoughts or tool actions from the model at the selected node to generate new child branches.
2. Evaluation / Simulation: Score the new state using an LLM self-reflection prompt (assigning a scalar value between 0 and 1) or automated environment feedback (such as unit test execution status).
3. Backpropagation: Propagate the evaluation score and trajectory reflections back up to all ancestor nodes, updating their visit counts and average $Q$ values.

LATS also integrates Reflexion-style linguistic feedback: when a branch fails during evaluation, a natural-language critique is stored in that node, informing subsequent expansions from that state.

How does LATS differ from standard ReAct with retries?

Answer

Standard ReAct with retries commits to one step at a time and must restart the entire trajectory or append error context sequentially when stuck. LATS maintains a full search tree, uses UCT to balance exploring unvisited actions against exploiting high-value paths, and can backtrack to alternate decision branches without discarding valid intermediate work.

Architectural comparison across control topologies

The topologies differ in what they do with uncertainty. A fixed workflow avoids it, a router resolves it in one turn, ReAct responds to one observation at a time, Plan-and-Execute organizes it across dependencies, and LATS spends extra work exploring alternatives. Compare them on token cost, latency, search complexity, and environment feedback:

From a decision to a tool call

The architectures above decide what to try. The side effect still belongs to your runtime, not to the model. 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}

The runtime validates the request, executes the external call, and feeds a bounded result into the next model turn. The LLM still needs a precise description of available tools and their argument shapes.

The runtime can pass those definitions in a prompt or through the provider's tool-calling API. They are usually JSON-schema-like rather than the full JSON Schema specification. Field descriptions, enums, and required keys help the model construct a valid request.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

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 that contract directly. In a supported strict schema mode, the provider enforces 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}

One request, one guarded round-trip

The model never hits the CI API itself. Your application owns the round-trip. Follow R1842 through the boundary:

R1842 tool round-trip: the model proposes get_ci_status, the runtime validates and executes, and only the bounded result returns for the next move.

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 payload, calls the API, and gets "failed: migration-test duplicate column".
4. Runtime: Feeds that bounded result back as a tool-result message.
5. LLM: "Run R1842 failed in migration-test because the migration re-adds an existing column."

The LLM generates the structured request. The host application authenticates, enforces timeouts, executes the call, and formats the response for the next model turn.

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.

Runtime-owned stopping rules

Earlier sections named the failure modes. Now turn them into controls. ReAct can loop, Plan-and-Execute can follow a stale plan, and both become costly or dangerous once writes enter the tool set.

External state can change between steps. An unexpected tool format or API timeout can trigger a blind retry or an invented response. Because each observation influences later moves, one unsupported conclusion can derail the rest of the plan.

Treat the LLM as an unreliable sub-component, not a deterministic program. Validate structured outputs, enforce hard step and token budgets, and return actionable error observations when a call fails. Those guardrails live in the runtime, which the next lesson examines.

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.

Detect cycles, then look for progress

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. An agent can repeat a valid read while receiving new pages of results, so repetition alone doesn't prove failure.

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.

Test the invariant on a new release

The R2099 trace changes the release ID but keeps the same control problem. Read three steps, then stop at the fourth: identify the missing evidence before you read the explanation.

Pause before reading on: what fresh observation would make close_incident safe?

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 service health in us-east after rollback or kept the incident open.

Add an enforced verify_region_recovered precondition before the close action. A prompt reminder can provide 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 isn't evidence that the failing region recovered.

A practical choice rule

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/engineering/building-effective-agents}. If the steps are known in advance, a fixed workflow or one tool-calling call usually wins on cost, latency, and debuggability. Reach for ReAct or Plan-and-Execute only when the next step genuinely depends on what the model observes.

Use Router-Delegator when distinct intent categories can dispatch directly to specialized tools or workflows in one turn. Use ReAct for short interactive tasks whose next move depends on fresh evidence, and add orchestration only when evaluations justify it.^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/engineering/building-effective-agents}

Use Plan-and-Execute when the route has a stable global structure and checkable local steps. Add Reflexion^{[7]Reference 7Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} when evaluated failures can teach the next retry, or LATS^{[10]Reference 10Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Modelshttps://arxiv.org/abs/2310.04406} when the task needs scored branches and backtracking. A multi-agent system can split planner, executor, and verifier roles across workers, but the same control boundaries still apply.

Both architectures need state and observability. ReAct trajectories grow one observation at a time; Plan-and-Execute needs storage for intermediate outputs between phases. Agent memory and persistence comes later in the path. Log validated tool calls, planner outputs, redacted observations with taint tags, approvals, retries, and budget usage. Raw chain-of-thought isn't an audit artifact.

Plan-and-Execute inherits the taint rule: tag planner inputs by trust, and never let plan text grant tool authority. Privileged steps still pass through tool policy even when a checklist item says to run them.