Guide
How the autonomy loop drafts
The always-on operator never stops reading your accounts. What it produces is always a draft — never a live change. Here is the loop, step by step.
Propose-only, always
The autonomy loop is the part of SpendSignoff people mean when they say "always-on operator." It runs continuously against your linked accounts. But "autonomy" here means autonomy to read and draft, not autonomy to spend. In V1 there is no autopilot — the loop has no path to push a change live.
The loop, one pass at a time
Each pass is read → evaluate → draft → queue. It never reaches the account.
Read the current state
The loop reads spend, pacing, structure, and performance from each linked account using mcp.read. It is working off live data, not a stale snapshot.
Find a change worth proposing
It looks for the moves it is allowed to draft — budget reallocations, bid changes, pacing fixes. If nothing is worth changing, it drafts nothing.
Stage a draft
Each proposal becomes a draft via propose_change: a before → after diff with a projected impact, scoped to one account. The draft is inert.
Drop it in the approval queue
The draft lands in your queue and waits. It does not expire into action — it waits for you to run Approve & push live → Confirm, or it goes STALE as the account moves on.
Why the loop cannot run away
What stops the loop
- The circuit breaker trips on anomalous platform responses or pacing and pauses drafting until the account is healthy again.
- A draft the loop built goes
STALEthe moment the account state it captured no longer holds — you re-draft rather than push an outdated value. - Unlinking an account or revoking the read OAuth ends the loop for that account immediately.
Next
Safety
Draft-before-live, propose-only, the daily envelope, and the circuit breaker.