Plan Mode
Structured planning before execution — the agent proposes, you accept, then a fresh context fork actually runs the work.
Plan Mode is a deliberate pause between "the agent has heard your request" and "the agent starts changing things". It splits work into two phases:
- Plan: the agent proposes a structured plan you can read, refine, and approve.
- Execute: a fresh context picks up the approved plan and carries it out, with the plan as durable state.
The split is intentional. Long-running execution agents tend to accumulate scratch context that has nothing to do with the actual task; when something goes wrong on step 12, none of that scratch helps. Plan Mode keeps the planning context separate from the execution context so the executor starts with exactly the relevant input and nothing else.
What you see in Plan Mode
In Plan Mode, the agent:
- Asks clarifying questions if your request is ambiguous, and saves the answers.
- Reads the relevant code, docs, or external references.
- Produces a plan with: goal, the files it intends to change, the sequence of steps, and verification criteria.
- Stops. It does not start editing.
You can:
- Accept the plan as-is.
- Send corrections (e.g., "split step 3 into two", "skip step 5", "add a rollback note for step 7").
- Reject and re-plan.
What happens after acceptance
When you accept a plan, Syntax forks a fresh execution context primed with the plan as the canonical input. That executor doesn't see the back- and-forth from the planning phase — it sees only the final approved plan plus whatever runtime context it builds itself. This is one reason plans tend to execute cleanly even when the planning conversation was messy.
Why this matters
- Reviewability. A plan is something you can scroll, share, paste in a PR description, or hand off to a teammate. A 10,000-token chat log isn't.
- Determinism. Two executors given the same plan should produce similar outputs. If yours don't, that's a signal worth investigating.
- Failure containment. If the executor goes off the rails on step 9, it's much easier to resume from step 9 (with the original plan) than to reconstruct the intent from a tangled conversation.
When Plan Mode isn't the right answer
Trivial one-shot tasks ("rename this variable", "format this file") don't need a plan. Plan Mode is most valuable for multi-file changes, investigations that span several systems, or anything you'd want a written reference for after the fact.
How to invoke
In supported harnesses, Plan Mode is a setting or a slash-command. The desktop app exposes it as a toggle on the session view. Syntax CLI accepts it as a flag.
Related concepts
- Agent Handoff — what happens when a long execution context fills up.
- Runtime Modes — the gating layer that decides which tool calls run unattended.