Why every change is a draft

Say a daily budget on a campaign is different this morning from what it was last night. A log will tell you it changed, when, and probably by which integration. What it will not tell you is what the value was before, what else moved in the same act, what the software checked before it acted, whether anything cleared it or whether it simply ran, and what it would take to put the account back.

Each of those is a separate omission, and they compound. Without the before state you cannot undo the change without going and looking it up somewhere that may no longer have it. Without the grouping you cannot tell whether this was one deliberate act or one row of a larger one that half-applied. Without the checks you cannot tell whether the change was validated or merely attempted. Without the authority you cannot tell whether the change was wanted.

That last one is the one that matters as soon as an agent is involved. A log entry saying an integration changed a budget is compatible with two very different worlds: one where you asked for it, and one where a model decided on its own that it was a good idea. If the record cannot distinguish those, it is not a record of anything you needed recorded.

So the unit is not the change. It is a change request: a row written before anything is applied, carrying what it would do, the state of the thing it would do it to, the checks it passed, the group it belongs to, and the authority that cleared it.

Written before, rather than after, is the whole difference. A record written afterwards is a description. A record written beforehand is the thing that gets acted on, which means it can be read while reading it is still useful, edited without starting over, refused, or approved as a batch. Whatever eventually reaches a platform reads that row, and nothing has a second route.

The grouping is the second half. A campaign, the group inside it and the ad inside that are three changes and one intention, and they should succeed or fail as one intention. So a batch is drafted as a unit, each child pointing at the entry that creates its parent, and it is cleared as a unit. A run that stops partway is resumable from the rows that are not yet cleared rather than restartable from the beginning, which is the difference between fixing a problem and duplicating a campaign.

And a create is drafted with the entity paused, so the structure and the decision to start delivery are two rows carrying two authorities rather than one act with a side effect. That is not caution for its own sake: it makes the expensive decision its own record instead of a consequence of a structural one.

It is worth saying in full what that buys today, because this is the paragraph where it otherwise gets assumed. Reading an account is what a connection does. Changing one starts as a record — the value it would replace, the checks it cleared, the group it belongs to — and finishes only when you or a rule you wrote clears it. What happens after that is not ours to promise: no platform write reaches a customer account until that platform has granted write access. Reaching a platform with a cleared change is in private beta.

Here is where this framing usually gets softened into something more comfortable and less true. The comfortable version is that a person always approves. It is a good line, and we do not use it, because it is not what we built and it would not survive contact with anyone who actually runs accounts at volume.

There are two authorities that can clear a change request. You are one. A rule you wrote is the other. Approved by you, or by a rule you wrote: those are the two, and the row says which one it got.

A rule is not a lesser form of approval; it is approval you gave in advance, in writing, with conditions attached. "Raise a daily budget by up to fifteen per cent on a campaign that has beaten its target for a fortnight, and never past a ceiling" is a decision. Making it once and letting it apply a hundred times is not abdication — it is the reason software is worth having. What would be abdication is making that decision implicitly, by not thinking about it, and discovering it from an invoice.

So the row names the authority. It says when a batch is waiting for a person, and it says when a rule cleared every row of it on the way in. Both are approvals. Neither is a guess. And because the shape is identical either way, the reversibility is identical too: a change cleared by a rule has the same before state and the same available inverse as one you clicked.

This is what we mean by governed autonomy, and it is a narrower claim than it sounds. It does not say the software is careful. It says that every change has an authority you can name, a prior state you can return to, and a record that was written before the fact rather than reconstructed after it.

The temptation with a reversible system is to build a rollback: a special path that puts things back. We did not, and the reason is worth stating.

A rollback is a change that does not follow the rules the original change followed. It skips validation, because the state it is restoring was valid once. It skips the gate, because it is only putting things back. It skips the record, because it is an undo rather than a change. Every one of those exemptions is reasonable in isolation and catastrophic in combination, because the rollback path is exactly the path that runs when somebody is panicking.

So an undo is a change request like any other: the inverse of the change it reverses, drafted at the same gate, validated by the same guardrails, cleared by one of the same two authorities, and recorded the same way. It is slower to describe and there is nothing special about it, which is the point. There is one path to an ad account and everything travels it.

Honesty about the price: it costs a step. An agent that could change a budget directly instead writes a row, and something has to clear the row. On a workspace with no rules written yet, that something is you, and it is a real interruption.

What it does not cost is the reading. Most of the hours an account consumes go into working out what happened — which of eighty live ads is carrying it, which change explains this week's number, what the last sync actually picked up. Nothing about drafts touches that, and that is the work an agent with read access removes. The gate sits between deciding and applying, which is a much smaller part of the day than the part before it.

The other thing it buys is the ability to hand an agent more rope over time without a leap of faith. You start with a key that can only read. You add drafting and watch what arrives in the queue for a fortnight. You write a rule for the class of change you kept approving unchanged, and the rule clears it from then on, with its name on every row. Each step is small, each one is legible in the record, and any of them is reversible — because the unit underneath all of it never changed.

If you want to see the shape rather than read about it, the setup walkthrough in Connect Claude Code to your ad accounts goes from a key to a drafted batch, and the rest of the agent setup guides cover the scopes that decide what a client can put in front of you at all.