skip to content

The Program Is the Plan


The first generation of tool-using agents treated tools like favors. The model asked for one search. Then another. Then a page fetch. Then a ranking step. Then a summary. Every step returned to the model, added more text to the context, and asked the model what to do next.

That is a reasonable way to make a demo legible. It is a bad way to run a workflow.

Many agent tasks are not conversations. They are little data pipelines pretending to be conversations. Search across ten queries. Read twenty pages. Deduplicate the results. Filter by source type. Extract dates and claims. Rank candidates. Keep evidence. Return the answer with citations. Nothing about that shape requires a model to sit in the middle of every operation like a nervous project manager.

The better abstraction is to let the model write the path once, then let the system execute it under control.

This is not the same as giving the agent an unrestricted shell. The important word is bounded. The system exposes small primitives: search these queries, read these URLs, parse these fields, rank these candidates, save this intermediate state, cite this evidence. The model composes them into a program. The host decides what the program is allowed to touch, how far it can fan out, which sources are allowed, what gets logged, how retries work, and what evidence must survive.

In that design, the program is the plan. It is not an implementation detail hidden under the answer. It is the thing that should be inspected.

A serial tool loop hides the plan inside a sequence of model decisions. You can read the transcript afterwards, but the strategy is smeared across turns. The model searched because the last result looked thin. It fetched because the next prompt asked it to. It filtered because some accumulated context suggested a direction. The plan exists, but only as residue.

A generated program makes the plan concrete. It says, in one place, how the work will proceed. It can be logged, replayed, diffed, constrained, and challenged. If it fans out too widely, that is visible. If it trusts the wrong source class, that is visible. If it drops a candidate too early, that is visible. If it fails halfway through, the failure belongs to a step in a program rather than to a vague loss of agent momentum.

This is why the control question changes. The point is not whether the model used a tool. The point is whether the system can show the tool path that produced the answer.

For simple tasks, a direct tool call is still right. If the agent needs the weather, call the weather tool. If it needs one file, read one file. Turning everything into generated code would be another kind of theatre. The pattern earns its keep when the task has shape: fan-out, filtering, joining, ranking, evidence handling, intermediate state, recovery.

The danger is that generated code sounds more controlled than it is. A program can be inspectable and still unsafe. It can be deterministic and still wrong. It can faithfully execute a bad plan. It can over-search, under-filter, leak context, cite weak sources, or turn a partial failure into a confident answer. Moving from tool calls to programs does not remove governance. It relocates it.

The governance moves to the primitive boundary. What operations exist? What arguments are allowed? What source classes are reachable? What counts as evidence? What state is retained? What failure stops execution? What must be reviewed before the answer is trusted? The model can write the plan only because the system has already decided what kind of plan is allowed to exist.

This is the same lesson agent systems keep teaching from different angles. Intelligence is not the control surface. The harness is. The trace is. The evidence path is. The permissions are. The model can generate movement, but the system decides which movements are meaningful, permissible, and reviewable.

The old tool loop made agents feel conversational. The next interface will make them feel more like temporary software. Not software in the grand product sense. Software in the smaller and more useful sense: a bounded program assembled for one piece of work, run under policy, leaving behind enough evidence that another person or system can understand what happened.

That is a much better bargain. Do not ask the model to beg for one tool call at a time when the work has a structure it can express. Ask it to write the structure. Then make the structure visible enough to govern.