Plans

When a request is small and unambiguous, the agent does it. When it is large, or when doing it would settle a question you have not answered, the agent writes a plan instead: a short document stating what it understood, what it proposes to build, and what it needs decided.

You can also ask for one directly. A task offers Plan beside Run in Agent, and pressing it asks for the proposal rather than the work.

Why a document instead of an attempt

Scope is cheapest to change before anything is built. A plan costs one short read; the alternative is reviewing a large diff written from the wrong reading of your request, then paying again to undo it.

It is also the honest form of the agent’s uncertainty. “I can build this two ways and they imply different things later” is useful before the fact and worthless after.

What is in one

A plan has four layers, and they are read in this order:

• The summary. What the agent believes you asked for, in its own words. The first thing to check, because a misunderstanding shows up here.
• The decisions. The questions it cannot answer for you: trade-offs, anything that affects data you already have, anything visible to your users.
• The steps. The work broken into slices, each sized in points, in the order they would be done.
• The approach. How it intends to build it, technically. Told, not asked; it sits collapsed and you never have to open it.

What you are asked, and what you are not

Not every choice inside a plan is yours. A choice with a visible consequence (pricing, what your users see, what happens to data you already have) is put to you. A purely technical one you have no basis to choose between, and which can be changed later, is made for you and shown under Technical choices we made for you so nothing is hidden.

The exception is irreversibility. Anything that cannot be undone once real data exists is asked in plain language whatever its nature. An owner never told about an irreversible choice has not been spared a technical question; they have been denied a decision that was theirs.

Deciding

A plan is accepted, changed, or rejected. Accepting it turns it into work; changing it is usually faster than rewriting the original request, because you are editing a shared understanding rather than starting one. Answering nothing and confirming is a valid choice too: the recommendations become the answers, recorded as defaults rather than as your decisions.

A plan left undecided blocks nothing else, but it does mean the agent is holding back on something it thinks is worth doing.

Automated tests

When a plan changes what a feature does, from the Build stage on, one of its questions is Add automated tests?, with a recommendation like any other. Say yes and the plan gains a last step, Write automated tests, which writes tests that check the decisions you just made, so a later change that breaks one of them is caught. Say no and that step disappears from the plan and from its size. You can still add automated tests for the feature later.

Building it

Once a plan is agreed it stays attached to its task, and you can run the whole thing or one step at a time. A step run is scoped: the agent gets the plan as context and that one step as the work, so what comes back is one reviewable change rather than everything at once. Steps tick off as the runs that did them complete, and the task shows how far along it is.

Where the decisions end up

They stay on the plan, on its task. That is the whole record, and there is no separate page listing them. Alongside the decisions the task keeps the plan’s version history, so a decision you later changed your mind about shows what replaced it and why.

What matters more is that the agent carries them. Every answered decision is part of the context of every later request: before building something that touches a decision you already made, the agent checks it, cites it back to you, and, if the new request contradicts it, says so and proposes a replacement plan rather than quietly overwriting the old answer.

That is why the record does not need browsing. After a hundred plans nobody remembers what was settled about invoicing eight months ago, and nobody should have to: the agent looks it up when it becomes relevant, which is the only moment the answer matters.

A decision outlives the task it was made for. Delete the task and the commitment still binds, and the agent will still raise it, though there is no longer a task to open.

Where the line sits

Plans exist for the same reason ownership zones do: some decisions are yours, and the agent is expected to stop and ask rather than choose quietly.

Next: Ownership zones explained · Tasks