Agent Planning: The Language of Planning

Overview

An agent's conversation is a trajectory — and back in Module 1 we met chain of thought: make the model write correct reasoning first, and the right answer becomes the probable continuation. Planning is chain of thought for action. Have the agent write its plan into the conversation before its first action, and every action after it is predicted following a document that already contains the path. The tool list gave the agent its language of action; this lesson begins a language of planning — words like write_plan and think that put reflection itself into the conversation, the way science builds thinking into research by demanding a hypothesis before the experiment. In this lesson: why planning first works, why the plan should be written through a tool, and how to design the planning vocabulary.

Think first: the plan is chain of thought for action

Remember the ferry problem. Forced to jump straight to the answer, the model slipped; asked to think step by step, it wrote a correct chain of reasoning — and the right answer became nothing more than the continuation of a correct document. Planning is the same move, one level up:

Watch it work. The task: a small data-analysis package has a failing test suite. The tools are the file system and the test runner — and the only thing that will change between the two runs is one sentence.

One more tool rides along in both runs, and it looks like it does nothing: think( thought ). Call it, and the computer just replies "OK." It exists because the conversation alternates — after the agent speaks, the computer must answer before the agent may speak again — so an agent cannot follow a paragraph of reasoning with a tool call in the same breath. When it wants to reason between actions, it calls think, and the OK keeps the conversation taking turns. File that odd little tool away: the next lesson is entirely about it.

Now the same task — plus one new tool, and one added line. The tool is write_plan( plan ): the way the agent plans is by calling a tool that writes the plan down.

And because the plan is just words, it is revisable the moment the world disagrees. If step 5 had come back still failing, the right continuation is not stubbornness — it is another write_plan call, replacing the hypothesis that just failed. A plan is a hypothesis about the future; every result that comes back is evidence about whether to keep it.

Hypothesis, evidence, revision

The note under Example 2 said the agent "wrote itself a little scientific method." Take that seriously, because it names what planning actually is. Science is not a collection of unusually smart people — it is a format for thought, built into a community's conversation. A paper must state its hypothesis before its results. A method must be written down where others can check it. Being wrong has a prescribed answer: revise, in writing. The format does the disciplining, and ordinary minds working inside it do extraordinary work.

That is exactly the move we just made on the agent's conversation. We did not make the model more intelligent. We gave its conversation words for reflection, and demanded they be used:

Why a tool, and not just a message?

The agent could have simply said its plan — the trajectory effect would be identical, since either way the plan is words the model re-reads. So why route it through a tool? Because a message only puts the plan in the conversation, and the conversation is rented space with a hard limit. A tool call does something a message cannot: if it writes it, it saves it. The plan now also lives in plan.md — outside the conversation, in the durable world.

You have met this move before: the journal between conversations, the handoff you write to your future self. The plan is the first thing worth writing down, because it is the one document that says where the whole task is going — and the conversation, with its edges and its meter, is the wrong place for anything you cannot afford to lose.

The plan is a first-class artifact

Once the plan exists outside the conversation, something bigger than durability opens up. A conversation is one big prompt — so a plan that lives in a file can be injected into any prompt we like. It stops being a passage in one transcript and becomes a first-class artifact: a document that can move between conversations, between models, and between readers.

Each row is the same move: the plan seeds a new trajectory with an old one's judgment. The reasoning was paid for once — by a person, by an expensive model, by a long exploration — and the artifact carries it wherever a conversation needs it next.

What should the tool be named?

We called it write_plan — but that was a design choice, and you know from the tool design case studies what's at stake in it: the name is the policy, and the tool set is a language. There are several ways to speak "planning," each with its own consequences:

The planning-mode design has a quiet superpower: the agent loop can see which mode the conversation is in, and route it to different models. Planning is where the judgment concentrates — so spend a more intelligent, more expensive model on writing the plan, and let a cheaper, faster model execute the steps. The mode boundary in the tool set becomes a cost boundary in the loop.

The to-do design adds something else: status. The agent doesn't just have a plan — it records where it is in the plan, updating each item as it perceives progress. Now the saved artifact tells anyone who reads it — the agent that resumes after a crash, the human peering in mid-run — not only where the task is going, but exactly where it stands. A set of tools for planning and for tracking the plan is one of the most useful vocabularies you can hand an agent.

The grammar can demand thought

There is one more place to put planning words, and it may be the most powerful: inside the tools themselves. Parameters are the grammar of the language of action — and we write that grammar, so we can write contracts into it. A tool can require a rationale parameter: now the tool cannot be called without a stated reason. And we can go further — require the same thinking parameters on every tool:

Engineering a style of thinking

Step back and look at the design space this opens. Tool design and loop design together are a mechanism for forcing the conversation to think in a particular style — reflection made structural, not requested:

And this is just scratching the surface — because the language of planning can itself be planned. Nothing says the contract must be fixed: the loop can detect things about the task, or hand it to another agent to read first, and choose the thinking style the task deserves. A routine task gets a light grammar and no mandatory reflection; a destructive or ambiguous one gets hypothesis parameters, a required plan, and reflection every third loop. The parameters, the cadence, the required words — all of it can adapt, per task, chosen by judgment. There is an infinite number of ways to design the language of planning, and to design it dynamically — what you have seen here is the start of a design space, not the end of one.

Two threads now lead onward. The think tool that kept appearing between actions is the next lesson's whole subject: where thought lives inside the loop, and how the loop can control it. And the lesson after asks what happens when a plan becomes so fully specified that it stops needing the conversation at all — and leaves it, as code.