Terraform Plans as an Agent's Proposal Format
Plans are diffs that humans already know how to review. The agent that emits plans instead of applying changes, and the apply-on-approve flow that closes the loop.
Why plans, not applies
A Terraform plan is a structured diff. Humans already know how to read it; tooling already exists to view it.
Letting the agent emit plans instead of applies inserts a natural review gate. The plan is the proposal; the apply is the action.
Plans are also reversible until apply. The agent can re-run with different parameters; nothing has happened yet.
The propose-then-apply flow
Agent generates the plan via a code path that wraps `terraform plan -out`. The plan file is stored.
Plan summary posted to the team's review channel: resources to add, change, destroy.
Human reviews the plan; approves or rejects. Approval triggers `terraform apply` against the stored plan.
Apply is auditable; the plan it executed is the same plan that was approved. Nothing was inserted between approval and apply.
Constraints on what the agent can plan
Module allowlist: agent can only operate on modules the team has explicitly opted in.
Resource type allowlist: agent can plan changes to known resource types; novel ones require human authoring.
Destroy operations: heavily restricted. Most agent plans should add or change, not destroy.
Safety properties
Plan files are stored with a TTL. Stale plans cannot be applied; the agent re-plans before applying.
Apply is single-use: applying a plan invalidates it. Re-running the same apply requires a new plan.
All plans are dry-run-able by humans before approval. Visibility before consent.
When this pattern wins
Infrastructure changes that are routine but require care. Adding a new monitor, scaling a worker pool, opening a port to a known service.
Changes that are too narrow for a Terraform PR but too wide for a kubectl tweak. The plan-as-proposal sits in the middle.
Changes that need an audit trail. Plans, approvals, and applies are all logged; reproducible from the trail.