Anyone who has worked on a serious software project knows the difference between a plan and a commitment.
A plan may say that the team will migrate a database, replace a component, add an approval step or retire an old integration. A commitment says who has authorised the change, what has to happen first, what must not be broken, how the work will be checked and who is allowed to decide that the plan has changed.
The words can look almost identical in a project document.
The difference lies in the machinery around them.
A plan living in a shared folder is useful. A plan linked to a change-control process, a budget, tested acceptance criteria, a production gate and named responsibility has a different status. One is a piece of information. The other changes what people are permitted to do.
AI agents are beginning to expose this distinction rather sharply.
Many coding agents and workplace assistants create a plan before they act. They inspect the task, list the steps, identify files to change and tell the user what they intend to do. It is a welcome habit. A visible plan makes an opaque process easier to inspect. It lets a user correct the course before the machine has spent an afternoon altering the wrong corner of a codebase.
Then, sometimes, the agent wanders off.
It begins with a reasonable plan, encounters an unexpected error, notices an adjacent problem, and starts working on something else. It may still produce useful work. It may even explain its departure fluently. But the plan, which looked like a contract five minutes earlier, has turned out to be a paragraph in a context window.
The agent has not rebelled or had second thoughts. Its plan was never more than a paragraph in a context window, and the design gave that paragraph no force when circumstances changed.
The preceding essay set out the practical controls that make an agent’s error survivable. This one asks a narrower design question: what happens when the agent’s own apparently careful plan is merely another piece of text it may later set aside?
A plan is often just another tool result
The paper behind this series makes a useful observation about current agents. Planning tools commonly store the agent’s plan as text in the context. In many systems that makes the plan, in effect, tool output: information the model can read alongside web pages, file contents, error messages and previous conversation.
That is convenient. It is also a strange place to put something we want the model to treat as a durable commitment.
The authors suggest that models may be biased to treat tool text as temporary data rather than as an instruction carrying continuing authority. They propose that a dedicated planning role might teach a model to distinguish “this is a plan I must honour unless it is formally revised” from “this is a document I have just looked at.”
That proposal is an open research direction, not an established cure. But it identifies the problem cleanly.
We routinely ask one stream of text to do too many jobs.
A user request is in there. The model’s earlier answer is in there. A plan is in there. A tool has returned a list of files. A compiler has produced an error. A web page has supplied external information. A retrieved document may contain a completely different request. The model receives all of this as context and must produce the next useful step.
The plan may be important to us. The question is whether it has been given a form the system can reliably recognise as important.
The fiction of the project plan
Software managers have seen a human version of this for decades.
An organisation declares that it has a project plan because there is a spreadsheet with milestones. Then the real work begins. A vendor slips. A requirement changes. A senior executive makes a promise to a client. Somebody discovers that the old system nobody was supposed to touch is holding the whole thing together with a piece of string.
The spreadsheet does not force anybody to respond well. It does not settle a dispute. It does not approve a new scope. It does not stop somebody from pushing an untested change late on Friday afternoon.
Good delivery is not achieved by writing a better plan. It is achieved by making the plan part of a system of responsibility, review, feedback and correction.
That lesson transfers neatly to agents.
It is useful for an agent to state its plan. But a sentence such as “I will modify only these three files, run these tests, and ask before making a breaking change” is not itself a control. If the system gives the agent broad write permission across a repository, the plan has no force outside the model’s own next-token prediction.
A good agentic system should not ask the model’s prose to carry the entire burden of governance.
What should be a plan, and what should be a rule?
Some parts of an agent’s work genuinely belong in a plan.
Which files should be read first? What possible approaches exist? Which tests are relevant? Is a migration likely to be needed? These are questions that benefit from language, reasoning and revision. A model may be very useful in exploring them.
Other things should not be left in the same category.
“Do not deploy to production.”
“Do not alter customer records.”
“Do not send external email.”
“Do not access files outside this project.”
“Do not make this change without the user seeing the exact diff.”
These are not suggestions about a good workflow. They are constraints. A system that cares about them should enforce them through permissions, separate environments, approval gates and auditable tools.
The distinction is ordinary engineering. We do not rely on a developer’s project plan to prevent a production database from being deleted. We use access control, backups, separation of duties and review. We should not rely on an AI agent’s planning text for the same purpose.
The agent can propose a production change. It should not be able to carry it out merely because it has written an articulate paragraph explaining why it now seems sensible.
The useful kind of friction
There is a strain of AI marketing that treats every pause as a fault.
The ideal assistant is meant to take a broad request, decide what it means, perform all the necessary actions and return only when the work is finished. A request for clarification is an embarrassment. A review step is friction. An approval gate is an admission that the system has not yet become clever enough.
This is a childish picture of work.
In real organisations, the most expensive mistakes often happen because someone moved too smoothly from an ambiguous intention to an irreversible action. Good people ask questions. Good teams use checkpoints. Good systems make it easy to recover from a wrong turn before it becomes a catastrophe.
An agent that pauses before sending an external email or changing a database is not necessarily less capable than one that does everything automatically. It may be operating under a better definition of success.
The same applies inside a software project. An agent should be able to discover that the original plan is wrong. Plans need revision. But the revision should be visible.
A healthy workflow might look like this:
the agent produces an initial plan and identifies its assumptions;
it works within a narrow, reversible environment;
if new evidence materially changes the plan, it says so plainly;
it records the proposed revision rather than silently drifting;
significant changes need user approval before they affect shared or external systems;
tests, diffs and logs make the result inspectable.
None of this requires us to pretend that an AI agent has a conscience. It requires us to recognise that it is working with fallible interpretation in a context that changes as it works.
Why silent drift matters
A plan is not valuable because it predicts every detail of the future. It is valuable because it makes departures visible.
If a project team changes direction, the question is not whether change is permitted. Of course it is. The question is whether the people who carry the consequence know that the direction has changed, why it changed and what now needs to be checked.
The same should be true of an agent.
Suppose you ask an agent to tidy a report and it discovers a broken data import. It may be useful for it to point this out. It may be useful for it to propose a repair. It should not quietly become a data-migration project, rewrite the import process and send the corrected report to clients because it has inferred that this is the helpful thing to do.
The machine has not disobeyed in a human sense. It has followed a new local pattern in its context. But the user has lost the benefit of a shared plan.
This is another version of the central lesson of the series. Text can look more authoritative than it is. An agent’s own written plan can look more binding than it is. If the surrounding system has not made that distinction real, we are relying on appearance.
The next design question
The researchers behind Prompt Injection as Role Confusion ask whether roles should become more deliberate. Instead of a small inherited set – system, user, assistant, tool and perhaps reasoning – might agents need a distinct role for a plan, an evaluation, a policy or an approval?
It is an interesting question, although a role label alone will not solve the problem. We have already seen that labels can be misread or given less weight than the text surrounding them.
Still, naming the job matters. A plan is neither a user request nor a web page. An approval is neither a suggestion nor a style cue. A policy is not merely an earlier paragraph the model may or may not continue to respect when the context gets busy.
The deeper answer will probably involve both better model structure and old-fashioned system design. A model may learn to treat a plan differently. The application must also enforce the points at which a plan becomes a commitment: the boundary of permission, the need for consent, the record of a decision and the ability to reverse a mistake.
There is no shame in that division of labour.
Language models are good at producing possibilities. Human beings and conventional systems are still needed to decide which possibilities may become actions.
A plan can be written in prose. A commitment needs somewhere stronger to live.
Further reading: the June 2026 extended write-up for Ye, Cui and Hadfield-Menell’s “Prompt Injection as Role Confusion” proposes a dedicated planning role as an open research direction, noting that planning text is commonly held in tool context. Wallace et al.’s “The Instruction Hierarchy” is a related reference on separating levels of instruction in language-model systems.