Change Ledger
The reason you can let it touch the account.
Every change is captured with the exact state it replaced, so putting it back is a restore rather than a reconstruction. That is what makes the difference between a tool you supervise and one you actually use: when a change is genuinely undoable, approving it stops being a small act of courage. The caution you have been carrying was never about the tool — it was about not being able to get back.
The cost of a reversible mistake is an afternoon. The other kind is a quarter.
Ask anyone why they hesitate before letting software change a live account and the answer is never "I want an audit trail". It is that a bad change on a client account is expensive, visible, and hard to walk back — so the safe move is to do nothing, and doing nothing is its own cost.
- Every change is a decision you have to be sure about
- So the ones you are unsure about wait for a meeting
- Reversing means someone remembering what the number used to be
- The account drifts, slowly, in the direction of whatever nobody dared touch
Caution reads as discipline. It is mostly just a cost nobody has priced.
- You approve it and watch. The old value is held, so Thursday is a real option.
- You test the thing you were unsure about — which is usually the one worth testing.
- Reversing is a restore, not four people reconstructing Monday from memory.
- You can be wrong on purpose, cheaply, which is the only way anyone learns an account.
The ledger does not make you safer. It makes you faster, because being wrong got cheap.
This is the part that sounds like a compliance feature and is not. A team that can undo anything runs more changes, learns the account faster, and stops routing every ordinary decision through a call. The log is the by-product. The behavior it unlocks is the point.
A team that can undo anything runs more changes.
Reversibility is not paperwork. It is what makes a wrong call cheap, and a cheap wrong call is how an account gets learned quickly.
- 1approval between a proposal and a change
- 0changes that arrive without the state they replaced
- ∞undos — reverting a revert is just another entry
A log tells you what happened. It cannot put anything back.
Plenty of tools keep a history, and it reads convincingly right up to the moment you need it. The question is whether the replaced value was captured at the instant of the write — because if it was not, no amount of logging will reconstruct it afterwards.
The before-state, captured at the write
Not "budget changed" but the figure it was, stored at the moment it stopped being true. That is the only thing a revert can actually use, and it has to be taken before the change — never inferred later from a report.
Reversible or not, said before you approve
Some changes a platform will not take back — a bid strategy with no prior manual bid, a placement that cannot return to its automatic default. You are told which kind you are approving while deciding, not when you try to reverse it and find out.
The reversal goes through the same gates
An undo is a write like any other: it re-reads the live account, runs the same guardrails as the forward change, and is logged as its own entry. Reverting a revert works too. Nothing here is a special path that skips the checks.
It is not a button. It is a recommendation you can refuse.
Reversing something is a decision, so it is treated as one. Adgent proposes the inverse change, tells you what it thinks the right call is, and says plainly when the answer depends on something only you know.
If the pause was accidental, this undoes it cleanly. If it was intentional, hold off on approving. I do not know which, and I would rather ask than guess.
Nothing here is a one-way door.
It also catches the changes nobody made.
Ad platforms move things on their own: a recommendation applies itself, a bid strategy flips, a budget reallocates under an automation somebody enabled last year. Those are read from the platforms’ own change feeds, so drift arrives with a date and a source rather than surfacing three weeks later as an unexplained CPA rise.
The honest limit: a platform-side change cannot be undone from here. No before-state was captured, because Adgent did not make the write. What it can do is date it, name it, and offer to set the value back as a change of its own.
"Who changed this, and when?" costs teams more time than almost any other question in a shared ad account, and it is usually unanswerable — so it gets settled by whoever sounds most confident. Here it has a date and a source, including when the answer is the platform itself.
And the before-state is the one thing that cannot be backfilled. Start next quarter and the entries you most want — the bid strategy that flipped at 03:14, the budget that reallocated itself, the setting nobody remembers touching — are already gone, because nothing captured what they replaced at the moment they were replaced. A ledger opened in November cannot restore August. Every month of waiting is a month you can describe but not undo.
Why this matters most on client accounts → How access is scoped →
Read-only → approve → reversible.
Three gates, and a change has to pass all of them. None of these is a setting you have to find and switch on.
A newly connected account has no write access at all. Adgent analyzes, ranks and proposes, and cannot touch anything until execution is explicitly enabled for that account.
Every proposed change arrives with its before-state, what it is expected to be worth, and whether it can be undone. You approve it from the same chat where you found the problem.
One entry at a time, each rollback logged as its own change. The reversal path is tested against the platforms rather than assumed — reverting is a real operation with its own failure modes, and it is treated like one.
Cheap to undo is only half of it. The other half is not doing it at all.
A reversible change is the floor. The layer above it is the one that declines to make the change in the first place when the account's own numbers say it will not work.
Ask it what changed in your account last month.
Point it at an account and it will read the platforms' own change feeds — the automated recommendations that applied themselves, the settings that moved, the dates nobody has. Read-only; nothing is written.
- Every change dated, with its source
- Including the ones nobody on your team made
- Read-only until you switch execution on
The drift in your account from the last thirty days, with dates and sources — usually including at least one change everyone assumed a person made.
Thanks — we’ve got it.
We’ll be in touch within a couple of working days.