Predict what the model emits next in this ReAct trace, given the observation just returned.
ReAct agent: weather concierge. The system prompt allows tools: get_weather(city), get_traffic(city), search_events(city, date).
User: Should I drive to the Saturday concert in downtown San Francisco?
Iteration 1:
Thought: I need to check both the weather and the traffic for downtown SF on Saturday. Let me start with weather.
Action: get_weather(city='San Francisco')
Observation: {"city": "San Francisco", "saturday": {"temp_f": 58, "conditions": "heavy rain expected, 70% chance"}}
Iteration 2:
Thought: Heavy rain expected Saturday: that affects the answer. Let me also check the traffic forecast for downtown SF.
Action: get_traffic(city='San Francisco')
Observation: {"city": "San Francisco", "saturday_evening": {"congestion_level": "severe", "avg_speed_mph": 8, "alert": "multiple road closures for concert venue"}}
Iteration 3:
Thought: ?
Predict the model's most likely Thought + Action (or final answer) for iteration 3, given the orchestrator's allowed tools and the user's question.The model should terminate. Weather and traffic both argue against driving, so the Thought phase decides to emit a final answer instead of another Action.
Picture asking a friend if you should drive to a Saturday concert. They check the weather, hear about heavy rain. They check traffic, hear about jammed roads and closures right at the venue. At that point, your friend stops checking things and just tells you no, take transit. The smart move was knowing when to stop researching. A ReAct agent has the same moment. Once it has the two pieces of information that actually answer your question, it should stop calling tools and give you the answer. Continuing to look up concert details or re-checking weather is wasted effort and a sign the agent does not know when to stop.
Detailed answer & concept explanation~6 min readEverything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Everything important, quickly.
4 min: the termination call + why wrong predictions are tempting + prompt-side termination rule + orchestrator-side step limits + frontier-stack signaling patterns (LangGraph, OpenAI Assistants, Claude tool-use).
Real products, models, and research that use this idea.
- LangGraph agents use `should_continue` edges that route to either a tool-execution node or an end node; well-written graphs have explicit termination logic on the should_continue check.
- OpenAI Assistants API run status transitions from `requires_action` (the SDK runs the tool) back to `in_progress` and finally `completed` when the model emits a non tool call message; the loop ends naturally.
- Anthropic Claude tool-use loops in 2026 terminate when the response contains no tool_use content blocks; the client knows to stop iterating without an explicit signal.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you write the system-prompt termination rule for this concierge agent?
QWhat orchestrator-side guards would you add to prevent runaway loops?
Don't say thisRed flags and common mistakes that signal junior thinking. Click to expand.
Red flags and common mistakes that signal junior thinking. Click to expand.
Predicting another tool call (search_events, re-call get_weather) instead of recognizing that the agent has enough information to terminate and synthesize a final answer.
The night-before-the-interview bullets. Scan these on the way to the call.
Primary sources. Skim if you want the original framing.
Same topic, related formats. Practice these next.