Skip to main content
A plan is a reviewable proposal for cloud infrastructure work. It records what will change, the key decisions, execution steps, risk and expected cost. Proposed work in a plan waits for approval before execution.

​
When to expect a plan

Agents are instructed to create a plan when starting a new, non-trivial cloud infrastructure task in the app or Slack, where a review card is available. For example, creating an application’s network, cluster and database is a plan. Deleting or replacing a non-ephemeral cloud resource, such as a database or bucket, also warrants a plan in those channels even if it is a single command. Simple changes and work already covered by an executing plan do not each need another plan. Repository edits, pull requests, tickets, diagrams and research are not cloud infrastructure tasks. External channels and automated turns may have no plan-review surface; do not assume an unattended run will stop at a plan card. State the changes and approval requirements you want in its prompt and use provider permissions to enforce the access boundary.
Plans are an agent workflow, not a provider IAM policy or a universal gate on every write. Use read-only credentials when writes must be impossible.

​
What you review

  • Overview and decisions: scope, assumptions and choices still needing input.
  • Steps, jobs and commands: the work and its recorded progress and output.
  • Risk: possible impact and mitigations.
  • Cost: expected one-time or recurring charges and savings.
Read the decisions and risk first. Check accounts, resources and anything publicly exposed. Reject with a reason or ask the agent to revise the proposal when it is wrong. Re-review changes before approving the revised work.

​
Lifecycle and access

A plan progresses from proposed to approved, executing and completed, or to a rejected, failed or cancelled state. Approvals are attributed and timestamped; execution records show what actually ran. A failed plan is not proof that every prior command was rolled back. Administrators and Editors can act on plans; Viewers cannot. A plan approval does not give someone access to an account they could not otherwise use, or widen the selected connector’s provider permissions. See Access control.

​
Runtime permission prompts

Auto Mode and Full Access govern individual actions such as shell commands and tool calls. The runtime decides when to request permission. Auto Mode shows those requests; Full Access approves the available permission requests automatically. A command prompt and a plan card are separate decisions, and approving one is not a blanket approval of unrelated work. An IAM denial is different again: neither a plan nor Full Access can add missing cloud permissions. See Cloud permission errors.