How it works
Plan Mode separates deciding what to do from exercising the authority to do it. The harness places the agent in a distinct phase with a narrower tool surface, typically allowing context inspection, search, dependency discovery, and proposal construction while denying writes, deployments, messages, purchases, and other consequential operations.
A useful Plan Mode control loop is:
- Assemble the task, relevant state, constraints, and available capabilities.
- Permit only the observational tools required to reduce uncertainty.
- Produce a bounded proposal: intended changes, affected resources, assumptions, risks, validation steps, and requested permissions.
- Check the proposal against policy, current state, and any required approval condition.
- Transition to execution with an explicit grant, or return the proposal for revision.
The transition matters more than the prose. A plan should not silently become executable merely because the model says it is ready. The harness must change the permitted action set and record that change.
Planning can also alter the world if its tools have hidden side effects. A database console that claims to support inspection may accept writes. A browser may submit forms during navigation. Plan Mode therefore depends on enforced tool permissions, not names such as “read only” or instructions telling the model not to act.
Why it matters in an agent harness
Agentic work often combines uncertain reasoning with high-impact tools. Without a phase boundary, exploration and execution happen in the same trajectory. The agent can discover a plausible approach and immediately apply it before the operator or harness has inspected its assumptions. A mistaken interpretation becomes a changed repository, sent message, deleted record, or production deployment.
Plan Mode creates a point where intent becomes legible before effects occur. The proposal gives the harness an object it can evaluate. Policy checks can compare requested actions with delegated authority. An operator can inspect a proposed migration or file set. Automated checks can reject missing rollback steps, excessive scope, or credentials that exceed the task.
This boundary also improves failure containment. The planning phase can uncover ambiguity, conflicting state, or missing prerequisites without consuming execution authority. If the task is unsafe or underspecified, the run can stop while the system remains unchanged. If execution proceeds, the plan provides a baseline for detecting drift between proposed and actual actions.
The plan is not a guarantee. Models can omit dependencies, misunderstand state, or produce plans that sound precise without being operationally complete. Production harnesses should treat it as a proposal under evaluation. They should also revalidate volatile assumptions at execution time. A plan based on an old branch, stale inventory, or expired permission may no longer be safe when authority is granted.
Observability improves when phase transitions are recorded. A trace can show what the agent knew while planning, which actions it requested, who or what authorized execution, and where the resulting trajectory diverged. That distinction is useful during incident review because it separates a reasoning error from an authorization or enforcement failure.
Plan Mode vs approval gate
Plan Mode and an approval gate solve different parts of the control problem. They can be combined, but neither implies the other.
| Control | Primary function | Does it require a person? | What it must enforce |
|---|---|---|---|
| Plan Mode | Constrains the agent while it explores and proposes work | No | Planning permissions remain narrower than execution permissions |
| Approval gate | Decides whether a proposed transition may proceed | Not necessarily | Execution remains blocked until the approval policy is satisfied |
A harness may run Plan Mode and then authorize execution automatically when deterministic checks pass. It may also require human approval for a direct action without asking the agent to produce a full plan. The design decision is whether uncertainty needs a constrained reasoning phase, whether authority needs a gate, or both.
The dangerous implementation is a textual approval convention inside one unrestricted session. If the agent already holds write-capable tools, asking it to “wait for approval” does not establish a permission boundary. It establishes a behavioral expectation. That may help model behavior, but it does not contain failure.
The Rifty take
We treat Plan Mode as an authorization boundary with a planning artifact, not as a special tone of model output. We optimize for a small, inspectable transition from proposed work to permitted work, and accept the latency of revalidation when state may have changed. If the same unrestricted capabilities exist on both sides, the boundary is mostly decorative.
Common failure modes
- Prompt-only enforcement. The system tells the model not to make changes but exposes the same mutating tools throughout the run.
- Side-effectful inspection. Tools classified as observational can submit, acknowledge, lock, create, or otherwise mutate external state.
- Vague proposals. The plan names a goal but omits target resources, permission needs, validation, failure handling, or rollback conditions.
- Authority leakage. Credentials or tool sessions available during planning allow actions beyond the phase contract.
- Implicit transition. Execution begins when the model declares the plan complete rather than when the harness records an authorization decision.
- Stale-state execution. The harness approves a plan, waits, and later executes it without checking whether dependencies or targets changed.
- Unbounded discovery. Planning can inspect unrelated secrets, systems, or customer data even though it cannot write to them.
- Plan-execution drift. Actual tool calls exceed the approved resource set or substitute a materially different method without reopening the gate.
- Approval without evidence. The reviewer sees polished prose but not the relevant diff, targets, current state, or expected validation results.
Frequently asked questions
Is Plan Mode a security boundary?
Plan Mode is a security boundary only when the harness technically restricts capabilities during the phase. A prompt that asks the model not to write is a behavioral control, not enforcement. The boundary should be implemented through tool exposure, scoped credentials, authorization checks, or an equivalent mechanism outside the model.
Which tools should an agent receive in Plan Mode?
The agent should receive only the tools needed to understand the task and construct a bounded proposal. Common categories include repository inspection, search, state queries, and dependency discovery. Each tool still requires review for hidden mutations, excessive data access, credential leakage, and operations that become consequential despite appearing observational.
What should happen if state changes after a plan is approved?
The harness should revalidate assumptions that affect safety or correctness before execution. If targets, dependencies, permissions, or expected versions have materially changed, the approved proposal is stale. Execution should fail closed, regenerate the affected part of the plan, and pass through the applicable authorization decision again.
When is Plan Mode unnecessary?
Plan Mode may be unnecessary when actions are low impact, tightly deterministic, independently validated, and easily reversible within an already delegated scope. Even then, the harness still needs explicit permissions and execution limits. Removing the planning phase should be a risk decision, not a reason to give the agent unrestricted authority.