Unlike most PPC automation tools, Claude Ads never pushes a change live as a side effect of a conversation. Both /ads launch and /ads optimize default to --draft, which produces a complete mutation plan you can read, question, and approve before anything touches an ad account. Applying that plan is a separate --apply step that works only for operations explicitly enabled in a capability manifest, independently tested, and approved by you.
That is the whole model in three sentences. The rest of this post explains why each piece exists, what a draft actually contains, what blocks an apply, and why permanent deletion is deliberately not part of the contract.
Why PPC automation tools should default to drafts
Anyone who has run paid media for a client knows the failure mode: a well-intentioned change goes out at the wrong scope, on the wrong campaign, or at the wrong time, and you spend the next week explaining a spend spike instead of preventing one. Ad platforms make mutations easy and reviews hard. An agent with API access inherits that asymmetry unless the tooling inverts it.
Most PPC automation software falls into one of three categories: rules engines, scheduled scripts, and agent tools with API access. They differ on many axes, but a single axis decides account safety: whether a human approves the exact mutation before it applies.
| Automation category | Who approves the exact change before it applies |
|---|---|
| Rules engines | Nobody at apply time. The rule was approved once; today's trigger was not. |
| Scheduled scripts | Nobody at apply time. Review happened when the code was written. |
| Agent tools with standing write access | Often a blanket grant, not approval of the specific mutation. |
| Claude Ads | You. --apply accepts only a draft plan you approved. |
Claude Ads inverts that asymmetry. The write path is opt-in per operation, and the default output of every execution command is a document, not an API call. A draft costs you a review. A bad apply costs you budget, learning-phase resets, and client trust. Defaulting to the cheap failure is the entire point.
The draft is also where quality control happens. /ads launch --draft loads the validated setup profile, the account snapshot, the campaign plan, the creative manifest, the platform capability manifest, policy findings, and tracking checks before it writes anything. If the inputs are missing account or object scope, an objective, a conversion definition, a budget, dates, targeting, assets, destinations, measurement, or policy eligibility, it refuses to produce the draft. An incomplete launch plan is not a draft, it is a guess, and guesses do not get an approval button.
What a mutation plan contains
A Claude Ads draft is deterministic: the same inputs produce the same plan. Each plan spells out the exact proposed objects, the before and after state, the blast radius, the expected learning impact, an owner, a success measure, a verification window, an idempotency key, an audit destination, and a rollback path.
That list is not ceremony. Each field answers a question a reviewer would otherwise have to reconstruct by hand:
/ads launch --draft
exact proposed objects what will exist that does not exist now
before / after state the diff a client or manager can approve
blast radius what else this change can touch
learning impact whether delivery models reset or degrade
success measure how we will know it worked
verification window when we check remote state after apply
idempotency key why a retry cannot double-create objects
rollback the exact path back to the prior state
/ads optimize --draft works the same way but starts from diagnosis instead of a plan. It loads the latest normalized snapshot, prior decisions, monitoring results, experiment state, conversion lag, economics, and the capability manifest, then identifies the decision and the causal evidence behind it. It explicitly compares three options, no change, an experiment, or a mutation, including learning, policy, tracking, inventory, and opportunity-cost effects, and returns ranked recommendations with confidence levels and success measures. It never optimizes a metric in isolation, and it never treats a fixed CPA multiple, a budget ratio, a benchmark, or a novelty claim as sole authorization to change an account. Approved recommendations become mutation plans only through the same mutation gate that launch uses. You can read the full command contracts at /commands/launch and /commands/optimize.
Capability-gated adapters and the apply step
Draft mode needs no write access anywhere. Apply mode goes through platform adapters that are capability-gated: each mutation type must be explicitly enabled and independently tested before --apply will consider it. There is no generic "write to the account" permission, only specific operations you have turned on.
Then the plan itself is re-checked. Apply is blocked when budget ceilings are missing, when the account state the draft was built on has gone stale, when remote state has changed since the draft, when tracking is incomplete, when policy review failed, or when the adapter for that operation is unavailable. Approval must be explicit and must reference that exact plan, not "yes, go optimize things."
| Question | --draft | --apply |
|---|---|---|
| Touches the ad account | No | Yes, smallest reversible change only |
| Requires enabled, tested adapter | No | Yes, per exact operation |
| Requires explicit approval | No | Yes, for that exact plan |
| Blocked by stale or changed remote state | Not applicable | Yes |
| Blocked by incomplete tracking or failed policy review | Refuses to draft on missing inputs | Yes |
| Verified against remote state afterward | Not applicable | Yes, within the verification window |
| Leaves an immutable audit and rollback record | Plan itself is the record | Yes |
When apply does run, it makes the smallest reversible change, verifies remote state against the plan, and preserves an immutable audit and rollback record. If reality no longer matches the draft's precondition, it stops instead of improvising.
Why permanent deletion is unsupported
Claude Ads refuses to permanently delete campaigns, ad groups, ads, audiences, conversions, or any other account object. Not behind a confirmation prompt, not with a scarier flag. Permanent deletion is outside the supported mutation contract because it cannot be made safe by confirmation: every other mutation in the system carries a rollback path, and deletion has none. A "yes" typed at 5 pm on a Friday does not restore an audience or its accumulated signal on Monday.
Instead, the optimizer offers reversible alternatives that achieve the same operational goal: leave objects paused, archive them where the platform supports it, apply labels, export a backup, and set a retention or later-review date. The same evidence bar applies to smaller destructive-leaning actions too. Search-term and negative-keyword actions require a search terms report, business-relevance evidence, and an overblocking review; without them, the skill asks for the missing evidence rather than inventing plausible-looking negatives.
Where this automation stops on purpose
Drafts-first is a control model, not a guarantee of good judgment. A reviewer who rubber-stamps every plan gets rubber-stamp outcomes. The verification window catches divergence after apply, but it cannot un-spend money spent inside it. And because apply requires per-operation enablement, the first-run experience is deliberately slower than tools that write to your account on day one. That friction is the feature. You are trading a few minutes of setup and review for the ability to answer, at any time, exactly what changed, who approved it, and how to put it back.
Try it
Install Claude Ads from the plugin marketplace and run your first draft against a real plan:
/plugin marketplace add AgriciDaniel/claude-ads
/plugin install claude-ads@ai-marketing-hub-claude-ads
Full setup steps, including credential profiles and adapter configuration, are on the install page. Start with /ads launch --draft, read the plan it refuses to write until your inputs are complete, and you will understand the model faster than any post can explain it.