After an AI agent changes your ads: how to check the change went in as intended

Translated from the Japanese original on mureo.jp.

When you hand ad changes to an AI agent, a report comes back at the end of the work: “I updated the budget,” “I created the ad.” Can you treat that report as evidence that the change went in as intended?

When we looked for first-hand records from people who delegate writes, we kept finding cases where they stopped at exactly this point. When we researched Japanese-language posts on X (formerly Twitter) on October 23, 2026, three people who had narrowed the scope they delegate all gave the same trigger: “a gap between the AI’s report that it was done and what actually happened.” For one, the AI pressed Enter in an input field and the budget for one store ended up at an unintended amount. For another, an AI they had asked to prepare posts touched the paid ad creation screen, and while it reported that nothing had been submitted, a charge of ¥155 went through and the card company got in touch. The third wrote that tasks the AI said it “can do” kept turning into “couldn’t do” later. All of these are summaries of posts; we have not verified that the accounts are real or what businesses they run.

What the three chose as a remedy was not to stop using AI. It was to add one step where a person checks after a change. We could not find an article, though, that describes what to check and how. How to check the numbers an agent reads is covered in Can you trust the ad numbers an AI agent gives you? This article is the follow-on to that: checking after a write. We go in order through how to split what you check, the reads to use for checking, the day to judge the result, and how to tell which changes cannot be undone.

Why the report that it is done is not a check

An agent’s “I made the change” usually means that the platform’s API returned success, or that the operation on screen went through to the end. That means the request for the change was accepted, not that things are now in the intended state.

For example, when you run an update through the Google Ads API, it returns the name of the resource you updated. For a Meta update, it is common to get back a short response indicating success. Neither contains whether the value after the update was what you intended. If the requested value itself was wrong, the success response reports the success of the wrong value. Google Ads handles amounts in millionths (micros), so where ¥1,500 should be written as 1500000000, a slip of one digit means a budget ten times larger succeeds correctly.

The other reason is that the party making the report cannot stand in a position to inspect its own work. The agent rereads whether the operation it ran fit the goal with the same understanding it had when it ran it. If that understanding was wrong, the rereading passes through the same mistake. So the check is done with a read separate from the path used to make the change.

Split what you check into three

“Did it go in?” looks like one question, but there are three things to check, and they go wrong separately.

Value: whether the item you changed has the intended value. This covers the budget amount, the bid cap, excluded terms and the wording of ad copy. Look at the value read back after the change, not the value you requested.

State: whether the changed object is running in the intended state. Meta ads have, apart from the status you set yourself, an effective_status that shows the actual delivery state. Even if you meant to turn an ad on, it may not be delivering for reasons such as being in review, being disapproved, or the parent campaign being paused. Check that these two do not disagree.

Scope of impact: whether the change went in only on the intended target. This is the kind of gap where you meant to change the budget of one ad set, and it went into an ad set with the same name in a different account. The ¥155 case above is a gap of this kind. That it had touched a screen it should never have touched does not show up in the report that it was done.

Of the three, the value you can see by reading it back. The state may only become clear once delivery starts. The scope you cannot see without taking the difference between before and after the change.

The reads to use for checking

For the reads that check, do not use the permissions you used for the change; use read-only permissions. It is the same thinking as the three places to stop writes in Start your ad MCP read-only: if the checking side has the power to write, it can change the state in the middle of checking.

There are five steps.

Record the values before the change: put the target of the change, the value before the change, the state before the change and the most recent numbers on one line. This becomes what you compare the read-back values against later.
Read the target back right after the change: retrieve the target itself, not the response. Line up the value and state next to the intended value.
Check the scope with a diff: pull the change history for the whole account and confirm that only the lines for the changes you made have been added. If there are lines that should have been added and were not, or lines for unexpected targets, the scope is off. How to pull the change history and its limits are in Keeping your own change log for ad accounts.
Look at the delivery side after some time: the state changes as review and the start of delivery happen. Even if there is no problem right after the change, decide the times to read it again, a few hours later and the next day.
Line up spend against the daily budget: when you have touched a budget, line up the next day’s spend against the daily budget. Spending past the daily budget is normal behavior, and in our own delivery there was a day when an ad set with a daily budget of ¥1,500 spent ¥2,520 (Why ads spend more than the daily budget). To tell whether the excess is within what the platform allows or a slipped digit, write down in numbers how many times the daily budget it was.

What went wrong in our operations when we skipped the check

In agent work that reads ad and CRM numbers, we have had four cases that went wrong when the check was skipped: a case with two analytics properties, a case where CRM creation timestamps were in UTC, a case where 0 of 5 new contacts came via our own site, and a case where the MCP refused a query for a different workspace. The details are in the earlier article. In none of them did the agent’s report show any sign of an anomaly; they were only found by reconciling against a separate read.

After a write, the situation is the same. The wording of the report hardly differs between a success and a success that drifted from the intent. The only way to tell them apart is to read the target, not the report.

Decide the day to judge at the time of the change

Even when the value and state are right, whether the change worked is a separate matter. Changes such as raising a budget or adding exclusions only show up in the numbers after days or weeks.

Before making a change, write down the day you will judge its effect, the metric you will look at and the direction you expect. This is to stop yourself from looking at the numbers afterward and “deciding it worked.” In mureo, the change record carries the expected effect (the metric, and whether it should go up or down), and the numbers before the change are saved as the baseline. The judgment is not made by looking at a screen and getting a feel; it mechanically compares the baseline numbers with the current numbers and returns one of improved, worsened or inconclusive.

That many judgments come out inconclusive is anticipated in the spec. If the difference before and after the change is within a set margin (10% by default), it is treated as day-to-day fluctuation and marked “inconclusive.” While conversions have not reached 30, it does not judge on CPA either. In small-budget ad ops, many changes end inconclusive. That is not a failure of judgment but the answer that there are not enough numbers yet. Do not force a conclusion; push the review date back.

Check whether you can undo it before you run it

When a check turns up a gap, the next question is whether you can undo it. It is better to know whether a change can be undone before you run it, not after.

mureo has a mechanism that, for each recorded change, checks without executing anything whether an undo operation is available. It returns one of can be undone, can be partly undone or cannot be undone, along with the operation that would be run to undo it and any caveats. When several changes were run together, it also shows how far the whole set can be undone. Even when you run things by hand, if you set aside deleting ads and changes made outside the platform’s UI as things that cannot be undone, before making the change, it changes how flustered you are when a check turns up a gap.

One more thing: changes that came in from outside your own path cannot be undone. There is a feature to take externally made changes into the record, but at the point they are taken in there is no value from before the change, so no undo operation can be built. Depending on the platform, the change history may not be importable at all. In that case, read it not as “nothing has happened” but as simply not being visible.

Which changes can be undone on the platforms you use, and how far the checking can be automated, vary with your team and the combination of platforms. If you have stalled at the stage of putting together the checking steps, get in touch with the platforms you use, the kinds of changes you hand to the agent, and the cases that have gone wrong so far.

Where checking tends to trip up

Reading success in the response as a check: it only shows that the request for the change was accepted. Judge by the value retrieved from the target again.

Not putting the requested value and the read-back value in the same table: if you look at only one of them, you will not find a slipped digit. Line them up and compare.

Skipping the scope check: even when the value is right, it may also have gone in on another target. Look at the number of lines in the change history.

Looking at the delivery state only once, right after: it changes later with review and the start of delivery. Look again a few hours later and the next day.

Reading inconclusive as “it did not work”: there are just not enough numbers. Decide a review date and push it back.

Frequently asked questions

If an AI agent reports “I made the change,” can I just trust it?

The report only guarantees that the request was accepted. Retrieve the target again with a read, line it up with the values you recorded before the change, and check the value, the state and the scope of impact.

How much time does checking take?

Reading the value back and checking the change history take a few minutes right after the change. What takes time is checking the state; because you wait for review and the start of delivery, decide the times to look again, a few hours later and the next day.

Can I hand the checking itself to AI as well?

You can, as long as it uses read-only permissions and retrieves things again through a separate path. If you have it read in the same context as the agent that made the change, it inherits the same misunderstanding, so keep the checking instructions separate from the change instructions, and give it the baseline values to compare against.

How long should I wait to judge the effect?

It depends on the metric. Clicks and impressions can be read within a few days, but metrics that need a count of conversions, such as CPA, may not be judgeable in small-budget ad ops until they reach 30. Decide the day to judge and the metric before the change.

What should I do when a change cannot be undone?

A change that cannot be undone can be set back to the same value if you recorded the original. If you do not have the original value, identify the time and target from the change history and fix it by hand in the platform’s UI. For the kinds of changes that cannot be undone, run things so that a person checks the content before they are executed.

Summary

An AI agent’s report that it is done only shows that the request for the change was accepted; it is not evidence that the change went in as intended. Split what you check into the value, the state and the scope of impact; record the values before the change, read the target back right after, check the scope with a diff of the change history, and look again once delivery is running. Run this sequence with read-only permissions.

For judging the effect, decide the day and the metric before the change. Take an inconclusive result while the numbers are short as a reason to push the date back. If you also sort out whether a change can be undone before running it, there is less to do when a check turns up a gap.