Analyse and compare agent architectures (ReAct, Plan-and-Execute...

Q: In the context of agent architectures, what distinguishes an AI agent from a single-turn LLM system (e.g., one-shot QA or email classification)?

An AI agent is characterised by its control loop around the model , not just the model itself. Single-turn system Produces an answer (or classification) once and stops. Agent Decides at runtime what to do next under an open-ended goal. Uses tools and takes actions that can affect its environment. Maintains state across steps and can adapt after observing the consequences of actions.

Q: When comparing agent architectures (ReAct, Plan-and-Execute, Reflexion, Tree of Thoughts, LATS), what common analysis questions should you apply to each one?

Use the same questions each time to make a meaningful comparison: Task representation : How is the task represented? Planning timing : Does the agent plan before acting or while acting? Tool/environment use : How does it use tools or interact with the environment? Feedback and failure : How does it handle feedback and failure? Search breadth : Does it explore one path or several alternatives? Strengths and limitations : What are its main strengths and limitations? Application fit : For which application is it most suitable?

Q: In an LLM-based agent, what is the typical agent loop (from inputs to termination), and what gets updated each cycle?

An LLM-based agent typically runs an iterative loop: Inputs to the LLM: user instructions, observations, retrieved information, and/or tool results. Decision step: the LLM decides what to do next (which may include calling a tool). Interaction: the agent uses a tool or interacts with the environment. Result/observation: the agent observes the tool/environment result. Update: the agent updates its working context and continues. Stop condition: the loop continues until the agent can produce a final response . This can be summarized as: goal/observation → reasoning → plan/next action → interaction → result → updated reasoning → next action or final answer.

Q: What does “planning” mean in an agent architecture, what are the three levels of plan described, and what capability distinguishes a “good” agent’s planning?

Planning means decomposing a complex task into smaller tasks and deciding their order . The material describes three levels: Strategic plan: high-level objective framing (e.g., “write a literature review”). Tactical plan: mid-level approach (e.g., “search, classify, and draft”). Operational plan: concrete actions (e.g., “search a database using these keywords”). A key capability of good agents is that they can revise a plan during execution when new information shows the original plan is failing.

Q: When comparing named agent architectures (e.g., ReAct vs. a rigid one-time plan), what comparison method does the framework recommend, and what is the key reasoning link you should make?

The framework recommends starting from the agent loop and its design dimensions , rather than from architecture labels. The key reasoning link is: Application demands → loop requirements → architecture suitability For example, if the task is sequential and partially observable (as in coding), an architecture that can incorporate new observations and revise its next action/plan (e.g., ReAct or LATS) has different suitability than a rigid one-time plan . This ties control flow to the task’s demands.

In the context of agent architectures, what distinguishes an AI agent from a single-turn LLM system (e.g., one-shot QA or email classification)?

An AI agent is characterised by its control loop around the model, not just the model itself.

Single-turn system
- Produces an answer (or classification) once and stops.
Agent
- Decides at runtime what to do next under an open-ended goal.
- Uses tools and takes actions that can affect its environment.
- Maintains state across steps and can adapt after observing the consequences of actions.

When comparing agent architectures (ReAct, Plan-and-Execute, Reflexion, Tree of Thoughts, LATS), what common analysis questions should you apply to each one?

Use the same questions each time to make a meaningful comparison:

Task representation: How is the task represented?
Planning timing: Does the agent plan before acting or while acting?
Tool/environment use: How does it use tools or interact with the environment?
Feedback and failure: How does it handle feedback and failure?
Search breadth: Does it explore one path or several alternatives?
Strengths and limitations: What are its main strengths and limitations?
Application fit: For which application is it most suitable?

Summarise how each of the five architectures moves from a goal to successful action: ReAct, Plan-and-Execute, Reflexion, Tree of Thoughts, and LATS.

The architectures differ in how they progress from a goal toward success:

ReAct
- Tightly interleaves thought and action while progressing.
Plan-and-Execute
- Separates planning from execution (a plan first, then carry it out).
Reflexion
- Improves later attempts through feedback from earlier outcomes.
Tree of Thoughts
- Searches through alternative reasoning paths rather than following only one.
LATS (Language Agent Tree Search)
- Combines tree search with actual environment interaction.

A ReAct agent repeatedly searches, inspects results, reformulates its query, and searches again. What does this illustrate about why agent behaviour is not “just the model being used”?

It illustrates that agent behaviour is largely determined by the control loop around the model:

The loop enables multiple steps (search → inspect → reformulate → search again) rather than a single response.
The agent can act, observe consequences, and adapt mid-task, which changes what it does next.
This is an architecture question (how reasoning, acting, observing, and responding to failure are organised), not merely a model-choice question.

For the learning objective “Analyse and compare agent architectures,” what kinds of responses would not satisfy the objective (even if factually correct)?

Responses fail the objective when they avoid architecture comparison and justification, such as:

Memorising historical dates without connecting them to architecture design.
Explaining attention mechanisms or LLM pre-training instead of agent control/architecture.
Designing a complete memory or safety system (beyond scope here).
Claiming one architecture is universally best rather than comparing strengths/limitations and fit.
Naming an architecture without explaining why it fits the task.

In an LLM-based agent, what is the typical agent loop (from inputs to termination), and what gets updated each cycle?

An LLM-based agent typically runs an iterative loop:

Inputs to the LLM: user instructions, observations, retrieved information, and/or tool results.
Decision step: the LLM decides what to do next (which may include calling a tool).
Interaction: the agent uses a tool or interacts with the environment.
Result/observation: the agent observes the tool/environment result.
Update: the agent updates its working context and continues.
Stop condition: the loop continues until the agent can produce a final response.

This can be summarized as: goal/observation → reasoning → plan/next action → interaction → result → updated reasoning → next action or final answer.

What does “planning” mean in an agent architecture, what are the three levels of plan described, and what capability distinguishes a “good” agent’s planning?

Planning means decomposing a complex task into smaller tasks and deciding their order. The material describes three levels:

Strategic plan: high-level objective framing (e.g., “write a literature review”).
Tactical plan: mid-level approach (e.g., “search, classify, and draft”).
Operational plan: concrete actions (e.g., “search a database using these keywords”).

A key capability of good agents is that they can revise a plan during execution when new information shows the original plan is failing.

Use the framework’s “design choices” to analyze an agent architecture: what dimensions should you assess, and what does each dimension mean at a high level?

The framework suggests assessing these architecture design dimensions:

Control flow: how reasoning/acting is organized (e.g., interleaved, separated, reflective, or search-based).
Feedback: what signals guide improvement (tool results, evaluator scores, self-critique, or environment rewards).
Search breadth: whether the agent keeps one current path or explores several candidate paths.
Adaptability: whether it can change the plan during execution.
Cost: number of LLM calls, tool calls, and evaluations required.
Best setting: which task type it suits (static, interactive, uncertain, or highly branching).

A coding agent must read files, search a codebase, edit code, run tests, inspect failures, and revise the fix. Using the framework, why is this environment “sequential,” “partially observable,” and potentially “dynamic,” and why do those properties matter for architecture choice?

These properties follow from how coding work changes and reveals state:

Sequential: each edit changes the state of the codebase, so actions have step-by-step dependencies.
Partially observable: the agent can’t inspect the entire codebase at once; key information appears only after reading files or running tests.
Dynamic: other developers may change files, so the environment can shift during execution.

These properties matter because architectures must incorporate new observations and often need to revise the next action/plan as test failures and file contents are discovered.

When comparing named agent architectures (e.g., ReAct vs. a rigid one-time plan), what comparison method does the framework recommend, and what is the key reasoning link you should make?

The framework recommends starting from the agent loop and its design dimensions, rather than from architecture labels. The key reasoning link is:

Application demands → loop requirements → architecture suitability

For example, if the task is sequential and partially observable (as in coding), an architecture that can incorporate new observations and revise its next action/plan (e.g., ReAct or LATS) has different suitability than a rigid one-time plan. This ties control flow to the task’s demands.

In agent architecture analysis, how do reactive and deliberative agents differ in when they decide what to do, and why are many modern LLM agents described as hybrid?

Reactive agent: decides what to do in response to a new observation (responds directly to what it just saw).
Deliberative agent: decides what to do by maintaining an internal plan before acting.
Hybrid (common in modern LLM agents): combines both patterns:
- plans at a high level,
- but reacts to new information during execution.

For tasks with clear subtasks and dependencies, why can planning help, and what two specific failure modes can occur in LLM-generated plans?

Planning helps when a task has clear subtasks and dependencies because it provides a roadmap of what should happen and in what order. However, LLM-generated plans can fail by:

Missing steps (the plan omits required actions).
Dependency errors: the plan orders steps inconsistently with prerequisites (e.g., requiring the results of step six while placing step four before step six).

Give three situations where an agent should replan during execution, based on execution or tool outcomes.

Replanning is necessary when execution reveals the current plan will not work, such as:

A search returns no useful results (insufficient evidence to proceed as planned).
A test fails (the attempted step does not succeed, requiring a new approach).
An expected tool is unavailable (the plan depended on a tool that cannot be used).

Define planning, execution, reflection, and search as distinct functions in an agent architecture, and state what each one contributes.

Planning: decides what should happen (selects intended steps/subtasks).
Execution: carries out a planned step (acts in the world/tools).
Reflection: evaluates what happened and how future behaviour should improve (uses outcomes to adjust future actions).
Search: compares multiple possible reasoning or action paths (considers alternatives rather than committing to one path immediately).

A literature-review agent must (1) define scope, (2) search databases, (3) categorise papers, (4) identify themes, (5) draft sections, (6) add citations, (7) review and revise. Which architecture is described as naturally representing this workflow, and how would ReAct behave differently on the same task?

Plan-and-Execute naturally represents the workflow because it matches an ordered series of subtasks (scope → search → categorise → synthesize → draft → cite → revise).
ReAct would more likely start by searching first, then inspect results, and decide dynamically whether to:
- narrow the query,
- read a paper, or
- change direction.

When explaining why planning architecture matters, how can you justify choosing Plan-and-Execute versus ReAct or Reflexion using (a) ordered subtasks and (b) uncertainty in search results?

Use Plan-and-Execute when the task has visible task structure with ordered subtasks (a roadmap fits a decomposition like scope, search, classification, drafting).
Use ReAct or Reflexion when execution results can change the next step, especially under uncertainty (e.g., search may produce inadequate evidence, forcing replanning based on what was found).

In the ReAct (Reasoning and Acting) agent architecture, what is the core control loop, and what role do tool actions and observations play in the agent’s reasoning?

ReAct alternates between internal reasoning and external action, using observations to update context and choose the next step.

Loop
- Goal → reason about next step → call a tool/act → observe result → incorporate result into context → reason again → act again or answer.
Role of tools and observations
- Actions can include searching, reading a file, calling an API, or running code.
- The action’s result is added to context, enabling the next reasoning step to be conditioned on the latest observation rather than a fixed upfront plan.

For ReAct, list three strengths and explain how each strength follows from interleaving reasoning traces with actions.

Adapts quickly when observations change the situation
- Because each action produces a new observation that is added to context, the next reasoning step can update decisions immediately.
Naturally supports tool use and interactive environments
- Tool calls (searching, reading files, calling APIs, running code) are first-class “act” steps, so the architecture fits interactive workflows.
Avoids committing too early to a complete plan
- Since the agent decides locally after each observation, it can delay full commitment until it has gathered key information.

For ReAct, identify three limitations and explain how the same alternating reasoning/action loop can produce each limitation.

May be inefficient because it repeatedly reasons after every observation
- The architecture encourages frequent “reason again” steps, which can add overhead in long sequences.
May become myopic and fail to maintain a coherent long-term strategy
- Repeated local decisions can overweight the latest observation and underemphasize an overarching plan.
Can loop, misuse tools, or take unnecessary actions
- When each cycle triggers another action, the agent may keep acting without convergence, or choose actions that do not reduce uncertainty or advance the goal.

Given a task description, decide whether ReAct is suitable and justify the decision using specific suitability criteria and “less suitable” criteria from ReAct’s profile: (1) web browsing with changing page content; (2) extensive offline search among many alternatives requiring a stable global plan.

(1) Web browsing with changing page content: suitable
- ReAct is particularly suitable for web browsing and tasks where the next action depends strongly on the latest observation.
- Its alternating loop supports interactive environments and fast adaptation when observations change.
(2) Extensive offline search with many alternatives and a stable global plan: less suitable
- ReAct is less suitable when extensive offline search among many alternatives is required.
- It can become myopic and may fail to maintain a coherent long-term strategy, which undermines a stable global plan.

In the Plan-and-Execute agent architecture, what are the two conceptual roles, and how does work flow from a user goal to a final result?

Plan-and-Execute separates the agent into:

Planner
- Creates a sequence of subtasks (can operate at strategic and tactical levels).
Executor
- Carries out the subtasks, handling operational details such as specific tool calls.

Typical flow:

Goal → generate a plan
Execute step one → execute step two → continue (or replan)
Final result

Analyse why Plan-and-Execute can make complex tasks easier to monitor and debug. What specific property of the architecture enables this?

Plan-and-Execute can make complex tasks easier to monitor and debug because it creates a clear roadmap before execution.

The planner outputs an explicit sequence of subtasks, which provides structure for tasks with a recognisable order.
This explicit plan makes the process easier to inspect (you can examine the intended steps and their order) while the executor focuses on carrying them out.

What are the main limitations of Plan-and-Execute, and how do they relate to risk from early planning decisions?

Main limitations of Plan-and-Execute include:

Early incorrect assumption propagates
- An incorrect assumption in the plan can affect many later steps.
Plan quality issues
- The plan may contain missing steps or incorrect dependencies.
Reduced responsiveness to change
- It can be less responsive if the environment changes unexpectedly, turning organisational structure into rigidity.

For what kinds of tasks is Plan-and-Execute suitable, and what additional mechanism should be included when tool results might invalidate the original plan?

Plan-and-Execute is suitable for tasks with stable, decomposable subtasks, such as:

report generation
project workflows
data pipelines

When tool results may invalidate the original plan, it should include a replanning mechanism, so execution can adapt rather than follow an outdated roadmap.

Compare Plan-and-Execute with a reactive architecture using the key distinguishing feature stated in the material, and explain when that feature becomes a weakness.

Key distinguishing feature: Plan-and-Execute has an explicit separation between planner and executor.

This separation supports a roadmap that is easy to inspect and execute (useful when the task has recognisable stages).
It becomes a weakness when new information (e.g., search results) invalidates an early assumption:
- Without replanning, the architecture’s organisational strength becomes rigidity and it is less responsive to unexpected changes.

In the Reflexion agent architecture, what is the core loop from an initial attempt to a revised attempt, and what makes it different from simply repeating the same reasoning?

Core loop:
- Attempt → outcome or evaluator feedback → verbal reflection → stored lesson → revised attempt
Key difference from repetition:
- The agent does not rerun the same reasoning; it creates an explicit verbal reflection about what went wrong, stores it as a lesson, and conditions the next attempt on that stored guidance.

For Reflexion, what strengths make it valuable across repeated attempts, and what condition about evaluation/feedback supports those strengths?

Supports improvement across repeated attempts
- The agent can get better from one try to the next by incorporating stored lessons into later attempts.
Turns failures into explicit, reusable guidance
- Reflections are written down as lessons, so the agent can reuse them instead of rediscovering them.
Useful when an evaluator can identify success
- Reflexion works well when there is an outcome signal or evaluator feedback indicating whether the attempt succeeded.

In Reflexion, what are the main limitations, and why do they matter for choosing when to use this architecture?

Self-reflection may be incorrect or superficial
- If the agent’s explanation of failure is wrong, the stored lesson can misguide future attempts.
Requires multiple attempts (higher cost)
- Because it relies on retries and refinement, it increases cost relative to a single-shot attempt.
Does not automatically explore every possible alternative
- Reflexion improves via learned lessons, but it does not guarantee broad exploration of the space of alternatives.

A coding agent produces a patch that fails two tests; the failure analysis says the patch changed validation logic but ignored an error-handling path. In Reflexion, what lesson should be stored, and how should it change the next attempt?

Stored lesson:
- The patch addressed validation logic but missed an error-handling path; future edits must inspect and handle both paths.
Effect on revised attempt:
- Condition the next attempt on this lesson by explicitly checking both validation and error-handling paths before making code changes, rather than repeating the previous approach.

For what task types is Reflexion suitable, and in what situations is it less useful?

Suitable for:
- Coding, writing, planning, and game tasks where attempts can be evaluated and retried.
Less useful when:
- There is no meaningful feedback signal.
- Only one irreversible action is possible (so retries are not feasible).

Explain how Reflexion fits the course idea of “non-parametric learning,” including what changes and what does not change.

What does not change:
- The model weights do not change.
What changes:
- The agent’s effective behaviour changes through context, memory, and improved instructions.
Why Reflexion fits:
- It improves the next attempt by storing feedback/lessons and using them as additional context, rather than performing weight updates.

When explaining or motivating Reflexion, what should you begin with, and what decision rule does that imply about when Reflexion is preferable?

Begin with:
- A failed or evaluated attempt (not with a new plan), then show how the reflection becomes context for future reasoning.
Implied decision rule:
- Prefer Reflexion when repeated attempts are possible and reliable feedback is available; it is weaker when the agent cannot judge whether its own explanation of failure is correct.

In Tree of Thoughts (ToT), how is reasoning represented, what is a “thought,” and how does the agent use branching during problem solving?

Reasoning representation: Tree of Thoughts (ToT) represents reasoning as a set of alternative partial solution paths (a tree) rather than one linear chain.
Thought: a “thought” is a meaningful intermediate step in solving the problem.
Branching use: the agent
- generates several candidate thoughts,
- evaluates branches,
- expands promising branches, and
- discards weak or contradictory branches (often after contradictions are revealed).

For Tree of Thoughts (ToT), outline the core workflow from problem to final answer, including where backtracking fits.

Start with a problem.
Generate candidate thoughts (multiple possible intermediate steps).
Evaluate branches to check which remain strong/consistent.
Expand promising branches by generating further thoughts from them.
Backtrack or select a solution: if an expanded branch fails (e.g., contradiction), backtrack and continue from other candidates; otherwise select a satisfactory solution path.

In a puzzle-solving use case, how does Tree of Thoughts (ToT) reduce the risk of accepting the first plausible answer?

ToT keeps several candidate solution paths (e.g., multiple possible first moves) instead of committing to one.
It evaluates which candidates remain consistent with the puzzle’s constraints.
It abandons branches that lead to contradictions, often only after evaluation reveals the contradiction.
This explicit branching and pruning reduces the chance of stopping at the first plausible but wrong path.

What are the main strengths of Tree of Thoughts (ToT), and what types of tasks do those strengths particularly support?

Explores alternatives: ToT explores multiple reasoning paths instead of committing to the first plausible idea.
- Supports tasks with multiple candidate reasoning paths.
Supports backtracking: if a partial solution fails, the agent can backtrack and pursue other branches.
- Helps on tasks where partial attempts commonly hit dead ends.
Suited to comparing possibilities: it can generate and compare several candidate thoughts/branches.
- Fits problems where several possible solutions must be compared.

What are the key limitations of Tree of Thoughts (ToT), and what causes ToT to become especially expensive?

Many model calls and evaluations: ToT requires repeated generation and evaluation across branches.
Evaluator dependence: ToT’s performance depends on the quality of the branch evaluator.
High branching factor cost: when the branching factor is large, the number of branches to explore/evaluate can grow, making the approach expensive.

For what application domains is Tree of Thoughts (ToT) suitable, and when is it less suitable?

Suitable for:
- puzzles
- mathematical reasoning
- strategic planning
- creative generation
- tasks where several possible solutions must be compared
Less suitable for:
- simple tool-use tasks where the next action is obvious, because extensive branching adds unnecessary cost.

Why does Tree of Thoughts (ToT) tend to be less attractive for straightforward interactive tasks, even though it is strong for high-branching reasoning problems?

Benefit for high-branching reasoning: ToT’s explicit branching lets an agent preserve multiple candidate paths and discard a branch after evaluation reveals contradictions.
Cost for straightforward tasks: the additional exploration and evaluation (many calls across branches) adds overhead.
Result: for straightforward interactive tasks where the next action is obvious, this overhead makes ToT less attractive than simpler approaches.

What is LATS (Language Agent Tree Search), and what is its core loop from state to decision?

LATS (Language Agent Tree Search) combines language-model reasoning with tree search plus feedback from an environment or evaluator, so it can try actions and use observed consequences to guide search.

Core loop (one iteration):
- Start from a current state
- Generate candidate actions or thoughts (branches)
- Execute or simulate a branch
- Observe feedback (consequences)
- Evaluate the resulting state
- Expand promising states, backtrack from poor branches, or select a branch to continue

For which application domains is LATS described as suitable, and when is it often excessive?

Suitable domains (because actions have observable consequences):
- Game playing
- Complex coding tasks
- Web interaction
- Planning problems where trying an action reveals information
Often excessive:
- Simple question-answering tasks
- Workflows with a clear deterministic sequence (where extensive branching and evaluation adds unnecessary cost)

Compare LATS to a purely internal Tree of Thoughts process: what is the key distinction to focus on, and what trade-off does it create?

The key distinction is the source of evaluation.

LATS
- Evaluates branches using consequences in an environment or an evaluator signal (e.g., executing actions and observing results).
Purely internal Tree of Thoughts
- Relies on internal plausibility rather than grounded environmental feedback.
Trade-off
- Power: grounded evaluation supports interactive planning and recovery via backtracking.
- Cost/risk: repeated execution and evaluation makes LATS more costly and potentially riskier than internal reasoning alone.

In a complex coding task with failing tests, how would a LATS agent use environment feedback to guide search over fixes?

A LATS coding agent can treat alternative fixes as search branches and evaluate them using test outcomes.

Generate several candidate patches (candidate actions/thoughts).
Execute each patch in an isolated sandbox.
Run the tests to observe feedback from the environment.
Score/evaluate each resulting state using the test results.
Select or expand the best-performing branch for further exploration, and backtrack from poor branches.

Given a task where “the next action depends on the latest observation,” which architecture is the best fit in this summary, and what property of its control loop explains the fit?

Best fit: ReAct.
Why: ReAct follows one evolving path with immediate reasoning and action, so new observations (e.g., tool outputs or test results) can directly determine what to do next, without committing to a fixed upfront plan.

A project has “stable, visible subtasks” and many dependencies that must be organized in advance. Which architecture is most suitable here, and what is its main risk?

Most suitable: Plan-and-Execute.
Reason: it builds one explicit roadmap and performs planning before execution, providing strong structure and monitoring that fits stable, visible subtasks and dependency management.
Main risk: it is vulnerable to early planning errors; if the initial plan is wrong, execution can be guided poorly.

When should you choose Reflexion over single-pass execution, and what requirement must hold for Reflexion to work well?

Choose Reflexion when attempts can be evaluated and repeated and you want improvement across multiple tries.
Mechanism: it uses repeated attempts linked by verbal lessons to learn from failures.
Requirement: it requires reliable feedback so the agent can judge failures/successes and form useful lessons.

Distinguish Tree of Thoughts from LATS in terms of where branching happens and how branches are evaluated; include the main cost/safety implications.

Tree of Thoughts (ToT):
- Branching: multiple internal reasoning branches.
- Evaluation: depends on an evaluator to assess branches.
- Implications: high cost and evaluator dependence.
LATS:
- Branching: multiple branches that are connected to environment execution.
- Evaluation: uses environment feedback to evaluate/rank branches and enables backtracking.
- Implications: very high cost plus safety requirements because actions are executed in an environment.

How can a production agent system combine Plan-and-Execute, ReAct, Reflexion, and optionally a LATS-style search without applying expensive branching everywhere?

Combine roles:
- Plan-and-Execute creates the high-level roadmap.
- ReAct governs tool use within each step, adapting to observations during execution.
- Reflexion analyzes failed attempts and produces lessons for subsequent tries.
Add branching selectively: include a LATS-style search only for parts of the task where multiple branches are worth exploring, limiting the computational and safety costs of broad exploration.

For each scenario, choose an architecture (or pair) and justify briefly: (1) debugging a small, familiar error; (2) a large migration across many modules; (3) patches repeatedly fail; (4) several fundamentally different fixes are possible.

Small, familiar debugging error → ReAct:
- Fits “inspect, edit, test, and react” because test results can directly determine the next action.
Large migration across many modules → Plan-and-Execute:
- Better structure for organizing many dependencies in advance using an explicit roadmap.
Patches repeatedly fail → Reflexion (add-on):
- Uses repeated attempts plus verbal lessons to learn from failures across tries (assuming evaluable feedback).
Fundamentally different fixes possible → Tree of Thoughts or LATS:
- Both explore alternatives via branching; LATS is especially attractive when candidate actions can be executed and evaluated in an environment.

What is the recommended reasoning pattern for defending an architecture choice, and why does this imply selection “must be justified rather than stated as a preference”?

Reasoning pattern: connect the task’s properties (e.g., uncertainty, stability of subtasks, ability to evaluate attempts, cost of trying alternatives) to the architecture’s control loop (how it plans, reacts, branches, and uses feedback).
Why this matters: no architecture is automatically superior; different control loops trade off planning depth, exploration, feedback use, adaptability, and computational cost. Therefore, a recommendation must show how the task’s needs align with the chosen loop (e.g., environment feedback ranking branches makes LATS attractive when multiple candidate fixes must be tested).

For a web research assistant working in a partially observable environment (it does not know in advance which pages contain useful evidence), compare when ReAct, Plan-and-Execute, Reflexion, and ToT/LATS are suitable, including one key limitation/threshold for using ToT/LATS.

ReAct
- Suitable for alternating between search, inspection, query refinement, and synthesis as observations arrive.
Plan-and-Execute
- Suitable for structuring the work into phases such as scope, search, source evaluation, and writing.
Reflexion
- Useful when the agent can record failed queries and improve them later.
ToT or LATS
- Justified only when several research strategies must be systematically compared.
- Limitation/threshold: unnecessary overhead if there is no need to compare multiple strategies.

For a coding assistant that must read files, edit code, run tests, and respond to failures, analyse which roles are best matched to ReAct, Plan-and-Execute, Reflexion, and LATS, and state one governance/safety concern highlighted by this setting.

ReAct
- Strong baseline because each observation (e.g., test output) changes the next decision.
Plan-and-Execute
- Helps with large changes involving several files by structuring multi-step work.
Reflexion
- Can store why a previous patch failed to guide improved fixes.
LATS
- Appropriate when multiple candidate patches can safely be tested in a sandbox and compared.
Governance/safety concern
- The broad action space makes permission systems and human approval important, especially for destructive commands.

For a game agent that may need to compare many possible action sequences, compare the strengths/limitations of ToT, LATS, ReAct, and Plan-and-Execute, including the specific failure mode noted for ReAct and a condition that forces Plan-and-Execute to adapt.

ToT (Tree of Thoughts)
- Can explore internal candidate strategies by considering multiple possible action sequences.
LATS
- Can execute or simulate actions and use game feedback to evaluate candidate strategies.
ReAct
- Limitation: may commit too quickly to a local action rather than comparing alternatives.
Plan-and-Execute
- Can provide an overall strategy.
- Limitation/condition: it needs replanning when the opponent changes the state.

For a report-writing agent, decide when Plan-and-Execute, Reflexion, and ToT are appropriate, and give one case where ToT is explicitly unnecessary.

Plan-and-Execute
- Well-suited because a report can be decomposed into research questions, evidence collection, drafting, citation, and revision.
Reflexion
- Appropriate for evaluating coherence and missing evidence after a draft is produced.
ToT
- Useful when multiple outlines or arguments must be compared.
- Unnecessary when the report is short and well-defined.

For a customer-support agent handling user cases, compare when ReAct, Plan-and-Execute, Reflexion, and LATS are suitable, and specify the condition under which LATS is considered “usually excessive.”

ReAct
- Useful to retrieve account information, inspect policy documents, and formulate a response based on observations.
Plan-and-Execute
- Useful for complex cases involving several verification steps.
Reflexion
- Can improve responses using labelled quality feedback.
LATS
- Usually excessive unless the agent must safely explore several resolution paths before taking an irreversible action.

When a comparison answer says “Architecture X is better,” what key clarification must be added to make the claim meaningful and defensible?

The answer must state “better for what” by connecting the claim to the task and its demands, rather than giving a context-free ranking. A defensible comparison ties “better” to task-specific requirements such as

feedback availability/needs
branching and search requirements
planning needs
failure-recovery requirements
computational cost constraints

In comparing agent architectures, what is the specific mistake about Reflexion that you must avoid, and what is the correct distinction?

Mistake to avoid: confusing Reflexion with ordinary replanning.
Correct distinction:
- Replanning changes the task plan.
- Reflexion extracts a lesson from an earlier attempt (i.e., it is about learning from a prior try, not merely changing the plan).

What two common misconceptions should you avoid when describing Tree of Thoughts (ToT) and LATS in a comparison, and what should you say instead?

ToT misconception: “ToT is necessarily interactive.”
- Instead: ToT branches can remain internal; interactivity is not required.
LATS misconception: “LATS is merely ToT with a different name.”
- Instead: LATS uses search together with environment or evaluator feedback.

What is an incorrect assumption about Plan-and-Execute in a comparison, and how should a strong answer qualify it?

Incorrect assumption: Plan-and-Execute never adapts.
Required qualification: a strong implementation of Plan-and-Execute includes replanning, so adaptation can be part of the architecture depending on implementation.

When recommending branching/search-based methods in an architecture comparison, what factor must you always discuss, and why (in the sense of what it constrains in your recommendation)?

You must always discuss computational cost, because branching methods can increase resource use; cost therefore constrains whether a branching/search approach is appropriate for the task’s requirements and practical limits.

For the agent architectures ReAct, Plan-and-Execute, Reflexion, Tree of Thoughts (ToT), and LATS, what is the core organising idea of each in terms of reasoning, action, feedback, and/or search?

ReAct: interleaves reasoning with action (acts, then uses outcomes to guide the next reasoning/action step).
Plan-and-Execute: separates a roadmap (plan) from execution (first outline subtasks/order, then carry them out).
Reflexion: improves later attempts using verbal feedback from earlier attempts.
Tree of Thoughts (ToT): explores internal alternatives by searching over multiple candidate reasoning paths.
LATS: explores alternatives using environmental evaluation (execute candidates in an environment and use the results to evaluate/guide search).

Match each architecture to a suitable application domain, and justify each match with the key property that makes it fit: (1) web agent, (2) structured report writing, (3) repeated coding attempts with tests, (4) puzzle solving, (5) sandboxed coding or game playing.

ReAct → web agent
- Fits when search results determine the next query, so reasoning must adapt after each action.
Plan-and-Execute → structured report
- Fits when subtasks and order are relatively clear, so a roadmap can be laid out then followed.
Reflexion → repeated coding attempts with tests
- Fits when tests reveal whether a previous attempt failed, enabling verbal feedback to improve the next attempt.
ToT → puzzle solving
- Fits when several internal solution paths can be explored and evaluated without acting in the world.
LATS → sandboxed coding or game playing
- Fits when candidate actions can be executed and scored in an environment to evaluate alternatives.

Compare Tree of Thoughts (ToT) and LATS in how they evaluate alternatives, and state a scenario type where each is a better fit based on that difference.

How alternatives are evaluated
- ToT: explores and evaluates internal alternatives (alternative reasoning paths assessed internally).
- LATS: explores alternatives using environmental evaluation (candidate actions are executed and scored in an environment).
Better-fit scenario types
- ToT: puzzles, where multiple internal solution paths can be compared without relying on executing actions.
- LATS: sandboxed coding or game playing, where candidate actions can be run and scored to guide the search.

You are designing a “strongest practical” agent for a complex task. Using only the roles described for the architectures in this chapter summary, propose a hybrid design and explain what each component contributes.

Planning (Plan-and-Execute)
- Provides global structure by defining a roadmap of subtasks and their order.
Local tool use control (ReAct)
- Handles local decisions by interleaving reasoning with action as new information arrives from actions/tools.
Learning from failure (Reflexion)
- Uses verbal feedback from failed attempts to improve later attempts.
Reserve search for high-branching decisions (ToT or LATS)
- Use a search method when there are many meaningful alternatives: ToT for internal alternatives; LATS when the environment can evaluate candidates.

An agent task is sequential, partially observable, and dynamic (e.g., coding where edits change state and tests reveal new information). How do these environment properties jointly push you toward ReAct or LATS rather than a rigid Plan-and-Execute plan, and what mitigation can make Plan-and-Execute viable anyway?

Sequential, partially observable, and dynamic settings mean the “right next step” depends on new observations revealed only after actions (reading files, running tests, seeing failures). Architectures whose control loop incorporates observation-to-next-action updates fit better.

ReAct/LATS: interleave action with observation and update reasoning each cycle, so they can adapt as state changes.
Rigid Plan-and-Execute: risks committing early to assumptions that later tool results invalidate.
Mitigation: include a replanning mechanism so tool outcomes can trigger plan revision, making Plan-and-Execute less brittle.

How do “search breadth” and “feedback source” together distinguish Tree of Thoughts from LATS, and why does that difference change both cost and safety considerations?

Both architectures increase search breadth by exploring multiple branches, but they differ in where branch evaluation comes from.

Tree of Thoughts: explores several internal reasoning branches and evaluates them with an internal branch evaluator; cost rises with more model calls/evaluations, but it avoids executing potentially unsafe real actions.
LATS: explores branches by executing or simulating actions and scoring resulting states using environment/evaluator feedback; this typically increases cost further (execution + evaluation) and raises safety needs (unsafe actions must be isolated, e.g., sandboxing).

A Plan-and-Execute agent encounters failed search results midway through a literature review. Explain how to combine replanning and Reflexion without confusing them, and what each contributes to improving performance.

Replanning updates the task plan because execution results show the original roadmap is failing (e.g., search returns inadequate evidence). Reflexion stores a verbal lesson from a failed attempt and conditions the next attempt on that lesson.

Replanning contribution: changes ordering/choice of subtasks (strategic/tactical/operational) to restore feasibility.
Reflexion contribution: turns the failure into reusable guidance (e.g., “queries were too broad; add constraint X”), improving subsequent attempts even after the plan is updated.

How can the “three levels of plan” (strategic, tactical, operational) be distributed across a hybrid architecture that combines Plan-and-Execute with ReAct, and why does this allocation match their respective strengths?

A practical hybrid can align planning levels to each architecture’s control-flow advantages.

Strategic/tactical planning: assign to Plan-and-Execute so the agent gets a clear roadmap (high-level goals and ordered subtasks) that is easy to monitor and debug.
Operational decisions: assign to ReAct within each step, because tool calls and next actions often depend on the latest observation (interactive, partially observable execution).
Rationale: Plan-and-Execute provides global structure; ReAct provides local adaptability and avoids overcommitting to operational details before seeing tool results.

When choosing between ReAct and branching methods (Tree of Thoughts or LATS) for a task, how should “computational cost” and “number of meaningful alternatives” be reasoned about together to justify the recommendation?

The recommendation should link the task’s branching needs to the added cost of exploring branches.

ReAct: follows one evolving path and is often sufficient when the next action is driven by the latest observation; it avoids the high overhead of evaluating many alternatives.
Tree of Thoughts/LATS: justify only when there are many plausible alternatives worth comparing (high branching), because they incur many model calls/evaluations (ToT) and often execution + evaluation costs and safety controls (LATS).
Reasoning link: if alternatives are few or obvious, branching adds unnecessary cost; if alternatives are many and consequential, branching can prevent premature commitment.

Analyse and compare agent architectures (ReAct, Plan-and-Execute, Reflexion, LATS, Tree of Thoughts), identifying their strengths, limitations, and suitable application domains

69 important questions on Analyse and compare agent architectures (ReAct, Plan-and-Execute, Reflexion, LATS, Tree of Thoughts), identifying their strengths, limitations, and suitable application domains