Make an agent plan first

There is no plan-mode switch. There is something better: a run can stop and ask you a question, and carry on with your answer. Pointing that at the plan is the recipe.

Ask for it in the brief

Per run, in What it is being asked to do when you delegate:

Plan first. Publish the plan and ask me to approve it before you write any code. Once I approve, implement it.

The brief is handed to the coding agent word for word, so say what you want in the words you would use with a colleague.

Or make it the default for a folder

The scan records AGENTS.md and CLAUDE.md from the root of a connected folder, and the coding agent reads them. Put the rule there and every run in that folder follows it without you retyping it:

## Before writing code

Publish the plan with `publish_artifact`, then `ask_human` with `kind: "approval"` and
`blocking: true`, quoting that artifact. Do not edit files until somebody has approved it.

This is the durable version. It also survives being handed to a different agent.

What the agent calls

Every run gets its own MCP server. Three of its tools matter here:

Tool	What it does
report_progress	Says what it is doing, in one line, on the run's timeline
publish_artifact	Hands over a file the run produced and returns an id
ask_human	Asks a person, and stops if it cannot go on without the answer

ask_human takes:

Field	Meaning
question	What you need a person to decide, as one question
options	The answers it would accept. Each becomes a button
allow_free_text	Accept an answer that is not one of the options. Always on when there are no options
blocking	true when it cannot go on. The usual case
meanwhile	What it will do if nobody answers. Required when not blocking
kind	decision, clarification or approval
artifacts	Ids from publish_artifact this question is about
files, preview	The files or preview the question is about
wait_seconds	How long to hold the turn open. There is a default

A plan approval looks like this:

{
  "question": "Approve this plan?",
  "kind": "approval",
  "blocking": true,
  "options": ["Go ahead", "Change the approach"],
  "allow_free_text": true,
  "artifacts": ["<id from publish_artifact>"]
}

Offering options is worth it. Approving becomes one click instead of typing.

What you see

The run moves to Waiting on you and the question appears at the top of the run screen, above everything else.

Each option is a button. Answer this — or Say something else when options exist — opens a box for free text. Dismiss refuses the question, and the run stops.

Answer it and the run carries on with what you said.

Waiting does not cost you a slot

When a blocking question goes unanswered inside its wait window, the agent is told to stop, and Norn starts it again with the answer once somebody gives one.

A plan left overnight is not holding the machine. The slot is released, and the run picks up where it left off. This is why blocking: true is the normal choice rather than something to avoid.

Tell me, do not ask me

Set blocking: false and say what it will do by default:

{
  "question": "Going with the repository pattern for the new store. Object if you disagree.",
  "kind": "decision",
  "blocking": false,
  "meanwhile": "proceeding with the repository pattern"
}

The question is recorded and the run keeps working. The run screen shows Working on the default meanwhile: proceeding with the repository pattern.

Use this when you want to know what it decided, not to gate it.

From a shell inside a run

The same thing is available to any process in the run:

norn ask "Approve this plan?" \
  --kind approval \
  --option "Go ahead" \
  --option "Change the approach" \
  --wait 600

It reads the run's id and token from the environment, which exists only inside that run's processes. A person at a terminal does not have them, and does not need them.

The alternative: review afterwards

If the work is usually right, skip the plan and let it finish. Request changes on the completed run resumes the same run — same branches, same preview addresses — with your text handed straight to the coding agent. New commits amend the result rather than starting a second one.

	Plan first	Request changes
You see the approach	Before any code	After the code
Cost of a wrong approach	One question	A full run
Interruptions	One per run, at least	None until the end

Planning first pays when a wrong approach is expensive. Reviewing afterwards pays when it usually is not.