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. |
in_review | Submitted. Reviewers can see it in their inbox. |
changes_requested | A reviewer asked for changes or left blocking feedback. |
approved | Reviewer hit Approve. Agent reads the new state and continues. |
Approval flow
A plan in in_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 moves to
changes_requesteduntil the agent revises or the owner updates it. - Comment leaves non-blocking feedback without approving the plan.
Each transition records an audit event so the run detail can show who decided, when, and what changed.
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
Plans are explicit resources. A creator can keep a plan private or share it with a user, team, or share group inside the organization. For trusted-edge encrypted plans, sharing has two parts: the ACL entry that lets the recipient discover the plan, and a wrapped body-key grant that lets the recipient's trusted edge decrypt the body.
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.