safe-write-operations

name	safe-write-operations
description	Reference — rules for safely executing write/destructive operations against ad accounts. Always loaded into the performance-marketer agent.
user-invocable	false

Safe write operations

Calls to run_write_operation can spend money, pause campaigns, change budgets, edit live creatives, send emails, or charge customers. Treat every one as a production change.

When this protocol applies

The trigger is the requires_approval: true flag on the operation in the find_operations response. If requires_approval: true, you must use run_write_operation and must follow the four-step protocol below. If requires_approval: false, use run_operation and skip this protocol — no confirmation needed.

The four-step write protocol

Always follow this exact sequence before calling run_write_operation:

1. State the change in plain English. Include the platform, account, object name/ID, and what will change. Example:

   "I'm about to pause the Google Ads campaign 'Brand — US Search' (ID 1234567890) in account Acme US (MCC 999-888-7777). This will stop spend immediately."

2. State the blast radius. What spend, traffic, revenue, or audience is affected? Pull a quick number from run_operation if you don't know.
3. Ask for explicit confirmation. Wait for a yes. "Looks good", "go ahead", or "do it" all count. Anything ambiguous = ask again.
4. Execute, then verify. After the call returns, fetch the object's current state with run_operation and confirm the change landed.

Hard rules

• Never batch more than 5 write operations without re-confirming. If a workflow needs 20 pauses, do the first 5, summarise, ask "continue with the next batch?".
• Never delete unless the user said "delete" (not "remove", not "pause"). Prefer pause/disable over delete every time.
• Never change budgets by more than 50% in a single call without an extra confirmation step. Big budget moves are easy to fat-finger.
• Never run a write operation immediately after a model-invoked discovery. The user must have asked for the change in their own words first.
• Never assume a connection. If the user has multiple Google Ads accounts and didn't specify, ask.

Always check before executing

• "Will this reset learning?" On Meta, budget shifts > 20%, audience changes > 10%, placement changes, optimization-event changes, and major creative swaps reset the ad set's learning phase (~7 days of degraded performance). On Google Ads, switching bid strategies resets learning (~1–2 weeks). Warn the user explicitly when a planned change will trigger a reset.
• "Does this change require fresh ID lookup?" Structural changes (creating a new RSA, replacing a Meta creative, creating a new ad set) return new IDs. Don't reuse stale IDs from earlier in the conversation after a structural change — re-fetch.
• "Is there a dedicated op for this?" On Google Ads, gads_mutate is the last-resort generic. If a dedicated op exists (e.g. gads_update_campaign_budget), use it — clearer intent, better validation, fewer footguns.

When run_write_operation errors

• Auth error → user must reconnect at https://www.markifact.com/app/connections. Stop, don't retry.
• Validation error → re-fetch the operation schema with get_operation_inputs, fix the payload, ask the user to confirm the corrected call before retrying.
• Rate limit / quota → back off, do not retry in a loop.