Reasoning and planning

Reasoning is a model working through a problem in visible steps before it commits to an answer. Planning is the model deciding a sequence of actions to reach a goal. Both make a model markedly better at hard tasks, and both have a hard ceiling: they can only ever be as good as the facts the model is given to reason over.

Answering all at once versus thinking first

A language model produces text one piece at a time, each piece chosen from everything written so far. If you ask a hard question and demand the answer immediately, the model has to commit to the first words of its answer before it has done any of the work the answer depends on. That is like being asked a tricky arithmetic problem and having to blurt the total before you have added anything. Sometimes you are right. Often you are not, because you never gave yourself room to work.

Reasoning, in this setting, means letting the model write out its work before it writes its conclusion. Instead of jumping to an answer, it lays down the intermediate steps: it names the parts of the problem, handles them one at a time, and only then states the result. Because each new piece of text is chosen in light of everything already written, the steps it just wrote become something it can lean on for the next step. The model is, in effect, giving itself a place to think, and then reading its own thinking as it goes.

The effect is easiest to see with a small puzzle. Ask a model, in one breath, to solve a word problem with several stages, and a model that answers instantly may get it wrong. Ask the same model to work through it step by step, and it far more often gets it right. Nothing about the model changed. What changed is that it was allowed to break a hard thing into a chain of easy things, and to write each easy step down where it could use it. The steps are not decoration. They are the work.

Why writing the steps helps at all

It is worth being precise about why this works, because it is not obvious. A model has a fixed amount of computation it spends producing each piece of text. When it must answer a many-stage problem in a single leap, all of those stages have to be crammed into that one fixed budget, and something gets dropped. When the model instead writes a step, then another, then another, each step gets its own fresh budget of computation. The problem is spread out over many small, cheap decisions instead of one large, overloaded one.

There is a second reason, and it is the same reason a person shows their work on paper. Once a step is written down, the model no longer has to hold it in mind. It can read it back. A partial result from three steps ago is sitting right there in the text, exact, not something the model has to reconstruct. Writing the steps turns the model’s own reasoning into more input for the model to read, and reading is the thing it is best at.

A model that answers instantly must decide everything at once. A model that reasons gives itself many small decisions instead of one impossible one.

This is why so much depends on giving the model room. A reasoning step costs time and text, and for an easy question it is wasted. For a hard question it is often the difference between a right answer and a confident wrong one. The skill is knowing which questions deserve the longer road, and good systems let the model take that road when the problem earns it.

From reasoning to planning

Reasoning works through a problem in the model’s own head, on paper. Planning is the next thing along: deciding a sequence of actions to take in the world. The two are close cousins. Reasoning asks, what follows from what I know. Planning asks, what should I do first, and then what, and then what, to get from here to the goal.

Planning becomes real once a model has tools, which are actions outside itself that it can ask to have run. With tools available, a hard task is rarely one action. It is a route. Suppose the goal is to answer a question about a file that references another file. A sensible plan is to read the first file, notice what it points to, read the second file, and only then answer. The model has to sequence those actions, because the second step depends on what the first one reveals. That sequencing, chosen on purpose rather than stumbled into, is planning.

A plan is not a rigid script written once and followed blindly. The best plans are loose enough to bend. The model sketches a route, takes the first step, looks at what came back, and decides the next step in light of it. Planning and acting are interleaved. This matters because the world answers back, and the answer is often not what the plan assumed.

Decomposition: turning one big task into many small ones

The engine under both reasoning and planning is the same move: decomposition, breaking a task that is too big to do in one go into parts small enough to do reliably. A large task is intimidating precisely because it has many pieces tangled together. Pull the pieces apart and each one, on its own, is usually simple.

Consider the request, “add a new setting to this program and make sure nothing else breaks.” As one lump that is hard to even begin. Decomposed, it becomes a list: find where settings are defined, add the new one there, find every place settings are read, update the ones that need it, then run the tests. Each item on that list is a task a model can do well. The hard part was never any single item. It was seeing the whole as a set of doable steps, and that is what decomposition provides.

Decomposition is also what lets reasoning and planning be checked. A single giant leap either lands or it does not, and if it does not you have little idea where it went wrong. A chain of small steps can be inspected step by step. You can see which step introduced the mistake. That visibility is not only useful to a person reviewing the work. It is useful to the model itself, which brings us to the step that separates a plan on paper from work that actually holds up.

Self-correction: reading the result and changing course

When a model takes an action with a tool, something comes back: the file’s contents, the output of the code, an error message, the search results. That returned text is not just an answer to move past. It is information the model can use to judge whether the plan is working and to fix it if it is not. Using it that way is self-correction.

Picture a model that plans to change a piece of code, makes the change, and runs the tests. The tests fail with an error naming a specific line. A model that reads that error can see what it got wrong, form a new small plan to address exactly that line, and try again. The failure became a signal, and the signal steered the next step. Without reading the result, the model would either declare success it cannot support or repeat the same failing move. With it, the model closes a loop: act, observe, adjust, act again.

This loop is where planning stops being a guess and starts being a method. The plan does not have to be perfect at the outset, because each observation corrects it. A rough plan plus honest reading of results usually beats a detailed plan followed without looking. But notice the quiet assumption under all of it: the loop only works if the results the model reads are true and relevant. If the error message points at the wrong line, or the file it read was not the file that actually runs, the model will correct itself confidently in the wrong direction. The quality of self-correction rests entirely on the quality of what comes back.

Reasoning cannot rescue missing or wrong facts

Here is the limit that ties this whole subject together, and it is the most important thing on this page. Reasoning is a way of drawing correct conclusions from what you know. It is not a way of knowing more than you were given. If a fact the problem depends on is missing, no amount of careful step-by-step thought will supply it. If a fact is wrong, careful reasoning will carry the error forward, flawlessly, to a wrong conclusion. There is an old phrase for this in computing: garbage in, garbage out.

Take a model reasoning about which parts of a program a change might affect. Its reasoning may be impeccable. But if it was told, or assumed, that a certain function is used in only one place when it is actually used in twenty, the whole careful chain is built on a false premise, and the conclusion, “this change is safe,” is false too. The model did not reason badly. It reasoned correctly from a bad fact. From the outside, a confident wrong answer and a confident right answer look identical, which is exactly what makes bad facts so dangerous.

Reasoning turns facts into conclusions. It cannot turn missing facts into knowledge, and it cannot turn wrong facts into right ones. It only makes whatever you fed it more consequential.

This reframes what improving a model’s answers really takes. It is tempting to think the way to get better answers is always a better reasoner. Often the larger gain is better facts. A model of ordinary reasoning working from accurate, complete, relevant information will beat a model of excellent reasoning working from a guess. The two are not in competition, but they are not the same lever, and when the answers are wrong the first question should be not “did it think poorly” but “what was it thinking about, and was that true.”

The interplay of reasoning and context

Put the two halves together and a simple relationship appears. The everything a model can see while it works, the question, the earlier steps, the tool results, the facts it was handed, is called its context. Reasoning is what the model does with that context. The final answer is a product of both. Improve the reasoning and you get more out of a given context. Improve the context and you raise the ceiling on what any reasoning can reach.

Because they multiply rather than add, the weaker of the two tends to set the result. Superb reasoning over thin, uncertain context still produces uncertain answers, because there was little solid to reason from. Rich, accurate context handed to a model that never bothers to reason produces a pile of good facts and no conclusion. The strongest results come when a capable reasoner is given a complete and trustworthy picture, and then takes the time to work through it in steps.

This is why so much effort in practice goes not into the model’s thinking but into what the model is allowed to see. Deciding which facts to place in front of a model, making sure they are true, keeping them relevant, and leaving out the noise, is its own discipline, and it is the thing that most reliably lifts a reasoning model’s real-world results. That discipline is the subject of the context layer, and the specific case of using reasoning and planning to read, change, and run code is the subject of agentic coding.