When is Tree of Thought the wrong tool and ReAct the right one for a task?

## Two different bottlenecks It is tempting to rank prompting techniques on a single axis of "power". They are not on one axis. Tree of Thought and ReAct remove different obstacles, and picking the wrong one is one of the most common design errors in this space. **Tree of Thought removes premature commitment.** The model generates several candidate continuations from a reasoning state, something evaluates the states, weak branches are pruned, and dead ends can be abandoned. Every token involved is produced by the model from what is already in its context. Search widens the space of derivations considered; it does not widen the information available. **ReAct removes missing information.** Reasoning alternates with actions taken against an environment — a query, a lookup, a command — and the observation returned becomes new context. The information content of the episode grows over time. What ReAct does *not* do well on its own is explore alternatives: it follows one trajectory, and a wrong turn is corrected only if a later observation contradicts it. ## The diagnostic Take real failures from your eval set and classify each one: - **Derivation failure** — the model had everything it needed and reasoned to the wrong place, usually committing early to one of several plausible lines. This is search-shaped. A tree with a partial-state evaluator can catch it. - **Information failure** — the answer depended on something outside the context: an order's current status, the contents of a repository file, today's inventory, a customer's plan tier. No amount of internal branching manufactures it. This is interaction-shaped. - **Instruction or formatting failure** — the model knew and derived correctly but violated the required shape. Neither technique is the fix; the prompt or a schema constraint is. The pathological case worth naming in an interview: applying search to an information failure. Every branch is fluent and internally consistent, the evaluator (which shares the same missing knowledge) scores them all highly, and you ship a confidently wrong answer having paid ten times the cost. Uniformly high scores across dissimilar branches is a reliable smell that the bottleneck is not search. ## Cost and observability differ too A tree's spend is dominated by generation and evaluation calls and is fairly predictable from branching factor and depth. An interaction loop's spend is dominated by how many actions the task needs and how large the observations are, which is data-dependent and much harder to bound in advance. They also fail differently in production: a tree can burn budget exploring a space with no solution in it, while an interaction loop can stall repeating an action that keeps returning the same unhelpful observation. The mitigations are correspondingly different — depth and width caps for one, step caps and repeat detection for the other. ## Hybrids The distinction is analytical, not a wall. Productive combinations include: - **Search over plans, grounded by tools.** Propose several candidate approaches, then use a cheap external check — run the tests, query the API, validate the schema — as the evaluator instead of a self-judgement. This is the strongest form, because the pruning signal comes from outside the model. - **Interaction with local branching.** Follow one trajectory, but at a genuinely ambiguous decision point expand a few alternatives and let the next observation adjudicate. - **Retrieve first, then search.** Fetch the facts the task depends on, then reason once over a complete context — often the cheapest and most robust arrangement, because it converts an information failure into an ordinary derivation problem before any search begins. ## The interview answer in one line Ask whether the missing thing is a *derivation* or an *observation*. Search buys derivations; interaction buys observations; the failure taxonomy of your own system, not the reputation of the technique, tells you which you are short of.