Core to Deep Dive
Revise agent loops, planning styles, stop conditions, and the boundaries between model reasoning and application control.
Depth
Showing 4 of 4 questions
Short answer
ReAct alternates between reasoning about the current state, selecting an action, executing that action, and feeding the observation back into the next step. The loop ends when the model returns a final answer or the runtime reaches a hard stopping condition.
Interview-ready answer
A production ReAct loop is explicit: build the prompt from the goal and scratchpad, ask the model for either a tool action or final answer, parse and validate the output, execute only allow-listed tools, append a sanitized observation, and repeat within a step or token budget. I would also trace every transition and handle malformed output or tool failures as observations rather than letting the entire run crash.
Example
For a support question, the agent may search documentation, observe that the result is stale, query a status tool, then produce a grounded answer with both observations.
Common mistakes
Short answer
Reactive agents choose the next action from the current observation, plan-and-execute agents create a broader plan before carrying out steps, and reflective agents critique outcomes or trajectories before retrying. Each adds capability but also latency, state, and failure modes.
Interview-ready answer
I choose the simplest pattern that fits the task. Reactive control works well when the next step depends heavily on fresh tool results. Plan-and-execute helps when dependencies and budgets benefit from an explicit sequence, but plans must be revised when observations invalidate assumptions. Reflection can improve quality after a failed attempt, although unrestricted self-critique can add cost without reliable gains, so I bound retries and evaluate whether reflection actually improves outcomes.
Common mistakes
Short answer
An agent stops on a validated terminal result or a deterministic runtime limit such as maximum steps, token budget, deadline, repeated action detection, cancellation, or policy block. The model may propose completion, but application code owns termination.
Interview-ready answer
I use layered stop conditions. A semantic condition accepts a well-formed final result that satisfies the task contract; safety and resource conditions stop on budgets, deadlines, user cancellation, denied actions, or repeated no-progress states. The runtime should return an explicit terminal status and preserve the trace so a caller can distinguish success, partial completion, timeout, and policy refusal.
Common mistakes
Short answer
Prevent loops with hard step, time, token, and cost budgets plus repeated-state detection. Recover by stopping safely, returning the best verified partial result, preserving the trace, and classifying why progress stalled before any bounded retry.
Interview-ready answer
I would combine hard limits with no-progress detection based on repeated tool calls, identical observations, unchanged plans, or oscillation between states. Near the budget, the runtime can request a concise finalization attempt, but it must still enforce the hard stop. Recovery should not blindly restart: classify parsing, tool, context, or planning failure; compact or repair state; retry at most a small number of times; and surface an actionable terminal result with trace and budget usage.
Common mistakes