Plans
An agent's intent expressed as a reviewable artifact instead of a wall of text.
A plan is what an agent says it's about to do, expressed as a structured artifact your team can skim. Steps, files affected, scope estimate, and the context that shaped the plan. Unlike sessions, plans live on the platform so you can review, comment, and reference them later.
Status machine
A plan moves through:
| Status | Meaning |
|---|---|
draft | Agent created it. Not yet submitted for review. |
pending_review | Submitted. Reviewers can see it in their inbox. |
approved | Reviewer hit Approve. Agent reads the new state and continues. |
rejected | Reviewer hit Reject. Run ends or branches per the workflow. |
superseded | A newer revision replaced this one. |
Approval flow
A plan in pending_review lands in the inbox of whoever the workflow's policy says reviews this kind of plan (see Inbox routing). Reviewers get three primary actions:
- Approve moves the plan forward. The daemon reads the new state via its workflow-run subscription and continues the run.
- Request changes opens a feedback thread. The plan stays
pending_reviewuntil the agent revises. - Reject ends the plan. The workflow chooses whether to branch or stop.
Each transition writes an immutable row to the audit log.
Revisions
Every change to an in-flight plan creates a new revision. Older revisions are preserved so you can read what you saw at the time you reviewed. The UI shows the diff between revisions.
That's what lets you say "approve the latest revision" without losing the trail.
Feedback
Reviewers can leave threaded comments on specific parts of a plan. Each thread can be:
- Resolved when the agent addresses it
- Reopened if the resolution is wrong
- Applied as a suggested edit (one-click for simple text changes)
Sharing
By default a plan is visible to anyone with access to the resource that owns it. To share a plan further (with a guest reviewer, with a different team), add a share entry from the plan detail page.
Worktree primitives
Rolling a plan back, retrying on a different branch, or squash-merging the result are operations on the daemon's worktree. They use the WebSocket actions rollback, branch-retry, squash-merge and surface in the vpd worktree commands.