Google and Meta Never Disagreed About Guardrails. They Disagreed About Sequencing.

I drafted a version of this piece with a different argument. It was built on the observation that Google and Meta had taken opposite positions on whether an AI agent should be allowed to change your ad account, Google shipping read-only, Meta shipping write, and it concluded that one of them was going to turn out wrong.

That framing did not survive fact-checking, for the best possible reason. The question had already resolved, and the resolution is more interesting than the disagreement was.

Here is the actual sequence.

The timeline

Google Ads MCP server: read-only. Google's developer documentation labels the release mode plainly, and the current docs say it harder than they used to:

"This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets."

The release-mode label, "Mode: Read-only (current release)", leaves the door visibly open for later.

Meta ads AI connectors: write, on April 29, 2026. Open beta, exposing Marketing API tools through a sanctioned endpoint. Reporting, yes, but also "creating and editing ads, ad sets, and campaigns using natural language," plus catalog management.

Meta ads MCP server rules: governance, on July 16, 2026. From Meta's own announcement:

"We're also launching ads MCP server rules, giving anyone with full control of a business portfolio the ability to govern what AI agents can do on their ad account, from budget changes to catalog updates."

So Meta did add guardrails. Approval boundaries, scoped by portfolio, covering exactly the actions that worried people, budget changes and catalog updates.

Nobody was wrong. That is the finding.

What the two companies actually disagreed about

Both platforms arrived at the same destination: agents acting on ad accounts need governance, and that governance belongs to whoever owns the account rather than to the agent vendor.

They disagreed about the order of operations.

Google shipped the constraint first. Read-only is a guardrail that exists before there is anything to guard. The capability comes later, presumably when they are confident about what a safe write looks like. The cost of this approach is obvious: the product is less useful for a while, and third-party servers fill the gap with less scrutiny.

Meta shipped the capability first and the constraint eleven weeks later. From April 29 to July 16, advertisers had write-capable agents and no portfolio-level rules to govern them. The cost of this approach is also obvious, but it is easier to miss, because it is paid by whoever happened to be in production during those eleven weeks.

That gap is the thing worth studying. Not who was right.

The gap is where the bill comes due

"Ship it, then add controls" is a legitimate strategy. It is how most software gets built, and it is often correct, controls designed against real usage tend to be better than controls designed against imagined usage. Meta's rules are portfolio-scoped and action- specific in a way that suggests they learned something from watching.

But the strategy has a cost, and the cost has a specific incidence. It is not paid by the platform. It is paid by the accounts that were live during the window, in a currency that does not show up on anyone's roadmap: the changes that were made, by agents, that nobody had a mechanism to review.

Nothing here suggests that went badly. There is no public evidence of widespread damage during Meta's eleven weeks, and I am not asserting any. The point is narrower and more durable: during that window, the mechanism to catch a problem did not exist, and whether that mattered was determined by luck and by individual advertisers' own discipline rather than by platform design.

The same will be true of the next gap, on whichever platform opens it.

What this changes about how to evaluate an agent integration

The useful question is not which philosophy you agree with. Both are defensible and you do not get a vote.

The useful question is: am I inside somebody's gap right now?

That has a concrete answer, and you can work it out per surface:

Does the capability exist before the governance does? If a platform has shipped agent write access but has not shipped account-owner rules to constrain it, you are in a gap. That is not a reason to avoid the tool. It is a reason to supply the missing control yourself, scoped credentials, a review cadence, a change log you actually read.

Who holds the governance when it arrives? Meta's answer is anyone with full control of a business portfolio. That is the right shape: control lives with the account owner, not the agent. When you evaluate any agent integration, find out who can set the rules. If the answer is "the agent vendor," that is a different product than the one you think you are buying.

Is the read-only label permanent or provisional? "Current release" is not a philosophy. It is a version number. Google's read-only stance should be re-checked, not assumed, and a workflow built on the assumption that it will stay read-only forever is building on a label that explicitly says otherwise.

The part I got wrong, and why it is worth saying

My original framing was that a disagreement this sharp had to resolve with somebody losing. That is a satisfying shape for an argument and it was the wrong shape for this one.

Platforms in the same market under the same pressure tend to converge, because they are responding to the same constraints. What differs is timing, and timing is not a minor detail, it determines who absorbs the risk of the interval. The interval is where the interesting things happen, and it is invisible if you are busy scoring the debate.

Google and Meta both think you should be able to govern what an agent does to your ad account. One of them made you wait for the capability. The other made you wait for the control.

Check which one you are waiting on right now.