Self-Consistency, Tree of Thoughts, and ReAct

Some tasks benefit from trying more than one answer. Others require exploring possible plans or interacting with a tool to get missing information. Self-consistency, Tree of Thoughts, and ReAct are three approaches for those situations. They add different kinds of work, and each has a cost.

This lesson will help you tell them apart, choose a suitable first experiment, and decide when a clear direct prompt is still the best option. The examples are illustrative. I have not run them against a live model, so treat the sample outputs as teaching examples, not measured results.

First ask what is difficult

Before choosing a technique, name the problem you are trying to solve. Is one answer too sensitive to how the model phrases its first attempt? Does the task require exploring several possible routes? Does the model need information or an action from outside the conversation?

Those questions point to different methods:

• Self-consistency generates several candidate answers, then selects an answer that appears repeatedly or passes a separate check.
• Tree of Thoughts (ToT) explores multiple partial solutions, evaluates them, and continues along promising branches. It can also backtrack.
• ReAct alternates a model’s next step with an action in a tool or environment, then uses the observation to decide what to do next.

These names describe patterns, not magic prompt phrases. Real systems often need application code to make multiple calls, compare answers, manage branches, or execute tools. Adding “use self-consistency” to a single ordinary chat message does not automatically create an independent voting system.

Self-consistency: compare several attempts

The self-consistency method begins with a prompt that can lead to more than one plausible route. Instead of accepting only the first generated answer, a system samples multiple attempts and chooses the answer with the strongest agreement. The original paper proposed this as an alternative decoding strategy for chain-of-thought prompting and reported results on several reasoning benchmarks. Those findings apply to the tested models and tasks; they are not a promise that voting improves every answer.

Here is an illustrative arithmetic task:

Three friends split the cost of three tickets at $27 each and one $18 booking fee. How much does each person pay?

An application could ask for three candidate answers. Imagine the candidates are:

1. “The total is 3 × $27 + $18 = $99. Split three ways: $33 each.”
2. “The tickets cost $81, then the $18 fee makes $99. Each friend pays $33.”
3. “The total is $99, so each person pays $30.”

Two candidates agree on $33 and show compatible arithmetic. But agreement is not a proof. They may share the same mistake, especially if all samples are produced by the same model from nearly identical prompts. For this small problem, a calculator or short script is a better final check than spending several model calls.

This pattern is more useful when answers can be compared reliably. A system might normalize equivalent answers such as “$33 each” and “33 dollars per person,” then count them as the same result. For a numeric task, code can check the value. For a multiple-choice question, a vote can select a common option, though the option still needs trustworthy grounding. For open-ended writing, there may be no single answer to vote on.

How prompt ensembling is related

Prompt ensembling asks the same underlying task in several different ways, then combines the outputs. For example, a customer feedback classifier might receive one prompt that asks for the main complaint, another that asks what went wrong, and a third that classifies the requested remedy. If the task and labels remain aligned, agreement across differently framed prompts can reveal fragile cases.

Self-consistency commonly samples multiple outputs from one prompt. Prompt ensembling varies the prompts or views. The terms can overlap in a system that uses both, but they describe different sources of variation. Neither method guarantees independent opinions: the same model, training data, and assumptions may shape every answer.

Decide how outputs will be combined before generating them. If the candidates use different labels or levels of detail, an informal majority vote may be meaningless. Set a shared answer format, decide how to handle ties and disagreement, and retain the original candidates so a reviewer can see why the system selected its result.

When it is worth trying

Consider self-consistency or an ensemble when a task has a checkable answer, different attempts can plausibly expose different errors, and the cost of a wrong answer justifies the extra work. Compare it with a direct prompt on a small set of representative examples. Track both answer quality and the number of calls, tokens, and seconds required.

Do not use voting as a substitute for an authoritative source, a calculation, or a qualified person when one is available. A majority can repeat a shared false assumption. It can also conceal a useful minority answer. If outputs disagree, that disagreement may be a reason to stop and review rather than force a winner.

Tree of Thoughts: search over partial solutions

Self-consistency compares complete candidate answers. Tree of Thoughts makes the search itself explicit. A problem is represented as a sequence of partial steps, or “thoughts.” The system can propose several next steps, judge which seem promising, expand selected branches, and backtrack if a path stops working.

Suppose you need to plan a half-day community event with a fixed venue, a small budget, and activities for both children and adults. A direct prompt may produce one polished schedule. A search-style workflow might first create several event structures, check each against venue and budget constraints, expand the strongest options, and revise a branch that has no workable transition between activities. A human organizer should still confirm the budget, access needs, and safety details.

The Tree of Thoughts paper introduced this framework for deliberate problem solving and tested it on tasks involving planning or search, including Game of 24, creative writing, and Mini Crosswords. Its abstract describes exploring coherent intermediate steps, self-evaluating choices, and looking ahead or backtracking. These experiments show why search can be useful for particular tasks; they do not establish that ToT is a universal upgrade for writing or everyday questions.

ToT is a better fit when choices have consequences for later steps and there is a meaningful way to evaluate partial progress. Examples include a puzzle with explicit rules, a route through a set of constraints, or a plan that can be checked against requirements. It is a poor fit for a simple definition, a short rewrite, or a task where the evaluation criteria are vague.

Why the search needs a useful judge

The system needs a way to compare branches. A judge prompt might check whether a plan satisfies required constraints, whether a puzzle step is legal, or whether a draft outline covers every requested section. When possible, use deterministic checks for properties such as totals, valid moves, required fields, or resource limits. A model’s own score is only an estimate and can prefer a confident-sounding dead end.

Search also has a branching cost. If every partial step creates several successors, the number of paths can grow quickly. A practical design limits how many branches it creates, how many it keeps, and how deep it searches. It should define a stop condition and preserve enough context to know why a branch was kept or rejected. Without those limits, the workflow can consume time and usage without becoming more reliable.

Tree search can also discard a good path early. A promising partial idea may look weak before its later steps are visible. If the task is creative, a narrow scoring rubric can prune unusual but valuable options. Keep a way to inspect rejected branches when the stakes or quality bar justify it.

For more on planning workflows and how tree search relates to agents, see the AI Agents lesson on planning, executors, DAGs, and Tree of Thought.

ReAct: act, observe, then choose the next step

ReAct combines reasoning with actions. The model identifies a useful next step, a system invokes a tool or interacts with an environment, and the resulting observation informs what happens next. This loop can repeat until the task is complete or a stopping rule is reached.

Imagine asking for the opening hours of a local museum today. If the model has no current information, another internal attempt cannot make the answer current. A ReAct-style workflow might search an approved website, inspect the page returned by the tool, and answer with the source and date checked. The action supplies new evidence from outside the original prompt.

The ReAct paper studied interleaved reasoning and actions on question answering, fact verification, and interactive decision tasks. It describes reasoning traces as a way to track and update a plan, while actions let the model gather information from external sources or environments. In a real application, the tool connection and execution loop are part of the system. A prompt alone cannot browse a website, book a ticket, or change a file.

This difference matters because a tool call may have consequences. Searching a read-only source has a different risk from sending an email, purchasing something, or deleting a record. A production workflow should limit which tools are available, validate their inputs, ask for confirmation before consequential actions when appropriate, and inspect the tool result before claiming success. OpenAI’s tools guide describes the API mechanism for connecting models to tools; exact implementation details vary across platforms.

ReAct is useful when the task depends on current or external information, or when an action changes the environment and the next step depends on what happened. It is unnecessary for a task the model can complete from supplied information. Each tool interaction can add latency and create new failure points: a search result can be stale, a tool can fail, or an observation can be misread. Decide what evidence is enough and when the workflow must stop.

The AI Agents lesson on ReAct and chain of thought examines this loop in more detail. As in the previous lesson on chain of thought and thinking models, treat a written explanation as a useful summary to inspect, not as guaranteed access to a model’s private reasoning or proof that the result is correct.

Compare the extra work before adopting it

Each technique spends effort in a different way:

When possible, start with a direct prompt that states the goal, context, and success criteria. Then test one added technique against that baseline. Use the same representative inputs and judge both versions against the same criteria. Count failed attempts, not just impressive examples. If the advanced workflow produces no useful improvement, keep the simpler one.

For a factual question, improvement might mean fewer unsupported claims and more correct citations. For a planning task, it might mean satisfying all required constraints. For classification, measure exact label agreement against a reviewed set. Include cost and time in the result: an extra process that makes a tiny quality difference may be a poor trade for a high-volume task.

Do not combine every technique by default. You could sample multiple branches, vote, call tools, then sample again, but each layer makes the result harder to debug. Add one source of complexity at a time. Keep clear logs of the prompt version, candidate outputs, checks, actions, and final selection where your application’s privacy practices allow it.

Mistakes beginners make

1. Assuming a majority is correct. Several answers can share the same misconception. Use an independent check when one is available.
2. Voting on answers that do not mean the same thing. Normalize formats and define a combination rule first.
3. Using Tree of Thoughts without a branch test. If no useful criterion can score partial progress, search may expand guesses rather than improve the result.
4. Letting search grow without limits. Set a branch budget, depth limit, and stopping condition.
5. Calling a prompt “ReAct” without a real action loop. The system needs an actual tool or environment, plus a way to process its observation.
6. Giving a model powerful tools without boundaries. Restrict actions and check results, especially when a tool can change data or affect another person.
7. Using advanced methods before testing a baseline. A direct prompt may already pass the task’s requirements at lower cost.
8. Treating a persuasive rationale as evidence. Verify factual claims, calculations, and actions against sources or checks suited to the task.

Recap and try it yourself

Self-consistency compares several complete attempts and selects by agreement or another check. Prompt ensembling changes the framing across attempts. Tree of Thoughts explores partial solutions as branches and evaluates which to extend. ReAct links model steps to actions and observations from tools or an environment. All four patterns can add cost, and all can fail if their comparison, evaluation, or tool handling is weak.

Try this small experiment with a task you can verify, such as classifying a dozen short product comments into a fixed set of labels:

1. Write a direct prompt and define what counts as a correct label.
2. Run it on the same examples and record the results.
3. Try three differently worded prompts with the same labels. Compare their labels and note disagreements.
4. Check both approaches against your reviewed answers. Count accuracy, disagreements, time, and calls.
5. Decide whether the ensemble caught errors often enough to justify its extra work.

Do not use generated agreement as the answer key. Your reviewed examples are the reference for the experiment. If you cannot explain how you would verify an output or judge a branch, first improve the task criteria. Often the best advanced technique is the one you can measure and keep under control.