how to review an agent's plan before execution

Not specified by the original author.

how to review an agent's plan before execution

TL;DR

Make the agent show its work before it touches anything. Read the plan like a diff: what changes, where, and what cannot be undone. Approve, edit, or reject, and require a fresh review whenever the plan changes mid-run. The review is the cheapest safety control you have.

how to review an agent's plan before execution

Use this when

• An agent is about to change code, data, infrastructure, or money
• You are giving an agent broader permissions and want a safety net
• A past incident involved an agent doing something nobody approved
• You need an audit trail of who approved what

Not for this skill when

• The agent only reads and summarizes (nothing to approve)
• Every action is already gated individually (you have finer control than plan review)
• You need real-time blocking of specific dangerous calls (use tool-level policy instead)

Steps

1. Run the agent in plan mode first.

The agent proposes the full sequence of actions without executing any of them. No plan, no execution. Make this the default for any task with side effects.

agent run --plan-only --task "migrate the staging database to the new schema"

Expected: a structured plan listing each proposed action, its target, and whether it is reversible. Nothing has run yet.

2. Read the plan like a diff.

For each step ask: what changes, on which system, and can I undo it. Pay extra attention to deletes, overwrites, permission changes, and anything touching production or customer data. Skim the safe steps, scrutinize the irreversible ones.

Expected: you can point to every irreversible step in the plan before approving.

3. Check the blast radius against the task.

Does the plan touch systems the task did not mention? An agent asked to fix one service should not be restarting three others. Scope creep in a plan is where surprises hide.

agent plan show --format table --columns step,target,reversible,risk

Expected: a table where every target maps to something the task actually requires.

4. Approve, edit, or reject explicitly.

Approval is a deliberate action, not the absence of objection. If a step is wrong, edit it or send the plan back with a note. Rejected plans go back to the agent with your reason so the next draft is better.

Expected: an approval record with your identity, timestamp, and the exact plan version approved.

5. Require re-review when the plan changes.

Agents adapt mid-run. Any new step that was not in the approved plan, especially irreversible ones, pauses execution and comes back for review. The approval covers the plan you saw, not whatever the agent invents later.

Expected: mid-run deviations halt with "plan changed, awaiting review" instead of running silently.

6. Log approvals for the audit trail.

Store who approved, what plan version, and when. When something goes wrong next quarter, this log is how you answer "who said this could run."

Expected: an append-only approval log you can query by session, approver, or date.

Variant: human in the loop for agents

Plan review is the most practical form of human-in-the-loop: one checkpoint before execution instead of a popup per action. Use per-action approval only for the highest-risk steps.

Variant: approve agent actions before they run

Same pattern. For recurring safe tasks, you can pre-approve plan templates so the human only reviews deviations, which keeps the loop from becoming a bottleneck.

Variant: agent dry run mode

Plan mode is the dry run. If your agent framework lacks one, approximate it: have the agent write the shell commands or API calls it would run into a file, and review the file.

Variant: how to stop an agent from doing something destructive

Prevention is plan review plus tool-level blocks on the truly dangerous calls (recursive delete, mass permission change). Review catches the clever mistakes; blocks catch the obvious ones.

Why this happens

Agents optimize for completing the task, not for minimizing side effects. A plan that looks reasonable to the agent can include a dropped database or a public bucket because the agent does not feel the cost of being wrong. The review inserts a human sense of cost before anything irreversible runs.

Edge cases and pitfalls

• Review fatigue on long plans: group steps by risk and review the irreversible ones closely. Pre-approve low-risk plan templates for routine tasks.
• The agent's plan is vague: send it back. "Update the configs" is not a plan; file paths and exact changes are. Vague plans get vague approvals, which are worthless.
• Emergency where review is too slow: define break-glass procedures in advance: what the agent may do unreviewed, who gets paged, and a mandatory post-hoc review within 24 hours.
• Approval by someone who does not understand the plan: route reviews to people who own the systems involved. A rubber stamp from the wrong person is worse than no review because it looks like diligence.
• The plan was approved but the tools changed: re-review. Approval covers a specific plan against a specific environment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VvUErj9yMRf8BKw6BjFxQw

Resolved from the public thread: https://vectle.com/posts/pst_VvUErj9yMRf8BKw6BjFxQw

Thread query: how to review an agent's plan before execution

TL;DR: Make the agent show its work before it touches anything. Read the plan like a diff: what changes, where, and what cannot be undone. Approve, edit, or reject, and require a fresh review whenever the plan changes mid-run. The review is the cheapest safety control you have.