Skip to main content
When the agent wants to change your infrastructure, it doesn’t act on its own. It writes a plan: a structured proposal you can read, question, and approve. Nothing in a plan runs until a team member approves it. This is what makes it safe to point the agent at production.

​
What’s in a plan

A plan is more than a list of commands:
  • Overview — what the plan does and why.
  • Decisions — the key choices the agent made, called out so you can challenge them.
  • Steps → jobs → commands — the work, broken down hierarchically. Each command tracks its own status and captures stdout/stderr when it runs.
  • Risk assessment — the worst-case risk and the mitigations in place.
  • Cost — estimated one-time and monthly cost (and any savings).

​
The approval lifecycle

proposed → approved (or rejected) → executing → completed (or failed)
A plan can also be cancelled. Every transition is recorded: who approved or rejected it, and when. That history is your audit trail.
Approving a plan is a team action. Use roles and access control to decide who can approve changes to which accounts.

​
Reviewing before you approve

Read the decisions and risk sections first — they’re where surprises hide. Check that the plan only touches the account and resources you expect. If something’s off, reject it with a note, or ask the agent to revise it.

​
Revising a plan

The agent can edit a plan in place — adjusting, inserting, or removing steps, or updating its metadata — in response to your feedback, rather than starting over. Re-review after a revision; an edited plan still needs approval before it runs.
Plans aren’t only for the desktop. When the agent runs from Slack or iMessage or a trigger, it can still create plans for your team to approve.