The Hidden Risk of Letting AI Manage Ad Campaigns

Here is a loop worth naming.

A scheduled job looks at an advertisement, finds it over its target and cuts the daily budget by a quarter. Two weeks later, the same job runs again. The ad is still over target, so it cuts another quarter. Then it does it again.

Three passes over a $100 daily budget leave the ad running at $42.19. The arithmetic is simple: 100 × 0.75 × 0.75 × 0.75. The important part is what the system did not know. At no point did it know that the first number was $100.

I am the chief technology officer of Trellis, which makes Qore, an advertising automation product. So this is not an argument from a neutral observer. It is an argument for an architectural choice we made, and one I think matters well beyond our product.

The question is narrower than whether artificial intelligence is useful for pay-per-click advertising. It plainly is. The question is what happens between the moment an agent decides to change something and the moment it returns days or weeks later to decide again.

What, exactly, is keeping track?

AI advertising is getting very good at seeing

We reviewed 19 pages that currently rank for searches such as “Amazon PPC MCP server,” “Amazon PPC LLM” and “Amazon PPC AI agent,” including two of our own. Thirteen recommend keeping a human in the loop before a write. Sixteen discuss business context or guardrails. Six mention maintaining a record of changes.

Only one discussed a future run reading that record before acting again. None explained what happens when a run partly fails, when the same write is sent twice, or when an advertising API rejects a request because of a rate limit.

That gap is the reason for this article.

Connect Claude, ChatGPT or another assistant to advertising data through the Model Context Protocol, or MCP, and the questions you can ask become substantially more useful. An assistant can investigate why ACOS moved, identify converting search terms that have not been harvested into exact match, or inspect hourly Amazon Marketing Stream data without requiring someone to build a pivot table first.

Amazon itself has pushed the technology further. Its Ads MCP server, released in open beta in February 2026, includes tools Amazon describes as “orchestrating Amazon Ads capabilities into complete, multi-step operations”. Its campaign tools can coordinate several underlying operations and produce a campaign ready for review and approval.

That matters because one common criticism of MCP — that it merely exposes low-level tools — is no longer accurate.

But Amazon also included a more important sentence in the launch announcement. Paula Despins, Amazon Ads’ vice president of ads measurement, wrote:

“This connectivity alone doesn’t guarantee reliable outcomes, though—especially in advertising, where real-world workflows often span multiple systems and decisions.”

That gets to the heart of the problem. Connectivity gives an agent access. Tools give it capabilities. Neither, by itself, creates a durable history of what the system already did to a particular advertisement.

The missing thing is a record, not a memory

The word memory is used loosely in AI, and that creates confusion.

Claude and ChatGPT both have forms of cross-session memory. Developers can also persist conversation state and tool history through application-managed storage. So the claim that modern assistants simply “forget everything between sessions” is wrong.

The more useful question is what kind of memory an unattended operating system for advertising actually requires.

It needs something much more specific: a record tied to an account and an entity that says what value existed before a change, what the system changed it to, why it made the change, whether the write succeeded, and what a later run should know before acting again.

That is not conversational memory.

It is a ledger.

MCP is the wire

MCP itself does not solve that problem, and it is not supposed to.

The protocol’s documentation has used different language over time around stateful sessions and statelessness. But the distinction that matters here is much simpler: MCP defines no record of what was done to an entity in an advertising account.

The current documentation puts the boundary plainly: MCP focuses on the protocol for context exchange and does not dictate how AI applications use models or manage the context they receive.

That is a sensible design. MCP is the wire. It gives applications a standard way to expose tools and data without trying to become the database behind every system connected to it.

A product built on top of MCP can absolutely maintain a ledger. Qore does. Other products can too. The protocol simply does not require one, define one or require future runs to consult one.

That work belongs to the application.

A transcript is not an operational history

Both Anthropic and OpenAI provide mechanisms developers can use to preserve state. Anthropic’s memory tooling leaves storage under the application’s control. OpenAI’s Conversations API can persist messages, tool calls, outputs and other items across a long-running conversation.

Those tools make durable state possible. They do not decide what that state should mean for an advertising system.

A transcript can tell you that an assistant discussed a campaign last Tuesday. It is not, by itself, a reliable answer to questions like: What was this advertisement’s budget before an automation touched it? Has this same procedure already cut it this month? Did the last write actually land?

Turning a transcript into that answer is application engineering: a record keyed by account and entity, written when a change is made and read before another decision is allowed to act on the same thing.

That is the difficult part. Not because the code is exotic, but because once the record becomes operationally important, the system has to keep it correct.

What Qore does differently

Qore does not simply schedule rules. It schedules agents.

A Qore skill is a named, versioned job given to an LLM agent and bound to a specific advertising account. The skill defines what the agent is trying to accomplish, the data and tools it can use, the constraints it must respect and, when appropriate, the actions it is allowed to propose.

When the skill runs, the result is not predetermined. The agent wakes up, reads the current state of the account, gathers the data the skill calls for, reasons about what it finds and decides what — if anything — should happen next.

That is an important distinction from conventional automation.

A traditional rule might say: If ACOS is above 40 percent, cut the budget by 25 percent.

An agent can be given a broader objective: understand why performance deteriorated, consider the evidence available to it, determine which advertisements actually require intervention and decide what change is appropriate within the boundaries of the skill.

The schedule automates when the agent thinks. It does not predetermine what the agent will decide.

Qore keeps another distinction separate as well: an agent can run automatically without being allowed to apply its decisions automatically. A skill may wake up, analyze the account and produce proposed actions for review, or it can be placed on autopilot and execute those actions without a person present.

That is where persistent state becomes important.

An intelligent agent should not reason only from the numbers it sees today. It should also know what its previous runs already did.

One Qore budget skill therefore includes a data source specifically for the skill’s own past applied changes. Before deciding what to do with an advertisement, the agent can read that history and recover the budget that existed before its earlier intervention rather than treating the already-modified value as a new baseline.

The mechanism is straightforward:

Each time the agent runs, it evaluates fresh account data together with the record of what its previous runs already changed. It can recover the original value, understand its own prior intervention and use that history as part of the next decision.

Return to the $100 example.

After the first run, the agent may decide that the evidence supports reducing the budget to $75. Two weeks later, it does not simply wake up to a $75 budget and mechanically take another 25 percent off.

It sees the current $75 budget, but it can also see that one of its own earlier decisions produced that number and that the original baseline was $100. The next decision is made with both pieces of information.

That is the distinction this article is about.

The goal is not merely to automate advertising decisions. Rules engines have been doing that for years.

The goal is to let an intelligent agent repeatedly observe, reason and act on an account while preserving enough history that every new decision understands the consequences of the decisions that came before it.

There is also an additional threshold in the version of this skill running in our own account that determines how much the evidence must change before the agent should intervene again on the same advertisement. That setting has not yet reached the public template; the history data source has.

What is available today is the foundation: an LLM agent making a fresh decision on each run, with access not only to the account as it exists now, but to the record of what that agent already did to it.

Why approval is not enough

Human approval remains important. It protects against a bad single decision.

But it solves a different problem.

If a system proposes a 20 percent bid reduction that looks reasonable, a reviewer may approve it. Two weeks later, the same reduction may still look reasonable. The danger is not necessarily that either decision is obviously wrong. It is that the second decision may be acting on a value the first decision already changed.

That is why the more interesting questions for unattended automation are:

• What did this system already do to this entity?
• What was the value before it started changing it?

Those are systems questions, not model questions.

Sometimes the right action is no action

There is another reliability problem that becomes more important when no one is watching: missing information.

On Sept. 4, I opened Qore’s Ask Q interface against a sandbox organization and submitted this instruction:

Lower the bid by 20% on my highest-spend keyword, and pause any campaign that spent over 100 dollars in the last 14 days with zero sales. Make the changes.

The system did not execute it.

It stopped because “highest-spend keyword” was underspecified. Highest spend over 14 days? Thirty? Ninety? All time? Different windows can produce different keywords, and therefore different writes.

Qore returned a required clarification field asking which time window to use before it would continue.

In a live conversation, an assistant can often choose a reasonable default and explain the assumption. The person reading the answer can correct it.

An unattended run at 9 a.m. has no such audience.

If a missing input determines what gets changed, choosing a default is no longer just conversational convenience. It is an operational decision.

I stopped the test at that point rather than submit a real bid change. The example therefore demonstrates a blocking clarification mechanism, not a completed live write.

Rules engines have the same problem

None of this began with large language models.

Consider a traditional automation rule: if ACOS is above 40 percent over the previous two weeks, cut a budget by 25 percent.

The rule contains a metric, a window and an action. Unless the product adds state explicitly, nothing in that rule says, “I already did this two weeks ago.”

That is how a $100 budget can become $42 without a language model ever being involved.

Good agencies have handled this problem for years with spreadsheets and operating discipline: preserve the original value, record the date and reason for a change, and make sure the next person checks the history before applying another one.

That works.

The advantage of putting the ledger into the system is not that the system is smarter than the spreadsheet. It is that the bookkeeping occurs as part of the action itself rather than depending on somebody remembering to maintain a separate record.

If three accounts and a spreadsheet work for you, that may be all you need.

Where Qore goes next

The foundation is already in place: a Qore skill can remember what it changed, recover the value that existed before the change, and use that history when it decides what to do next.

The next step is to make that operational memory broader, more connected and easier to act on.

• A unified action history. Conversation-driven actions and scheduled skill actions are visible today, but in different places. We are working toward a single account-level view that brings those changes together into one chronology.
• Deeper coverage across marketplaces. Qore supports both Amazon and Walmart today, with the most mature automation workflows currently on Amazon. The same operating model is expanding across marketplaces as those capabilities mature.
• A deliberate boundary between reading and writing. Qore’s MCP server is read-only by design. External assistants can explore and analyze account data freely, while writes flow through the part of Qore built to record, govern and track them. That separation is an architectural choice we intend to preserve.
• From skill-level history to account-level awareness. Today, a skill has a durable record of the changes it made itself. The larger opportunity is to reconcile that history with changes made by people, other automations, rules engines and bulk uploads. The goal is a complete account-level ledger, regardless of who or what made the change.
• Progressive trust for autopilot. Autopilot is off by default because automation should earn trust through observed behavior. A new procedure can run in review mode first, then move toward unattended execution once the operator is comfortable with how it behaves.
• A path toward reversible actions. Qore already versions skills and allows previous versions to be promoted back to live. The natural next step is to extend that thinking to account actions themselves, making it easier to understand and, where possible, reverse the effect of a prior change.

The most important evolution is the move from procedure-level memory to account-level state.

A skill already knows what it did. The system we are building toward knows what happened to the account — whether the change came from a person, a rule, a bulk operation or an agent — and gives every future decision access to that history.

That is the larger idea behind the ledger. Not simply remembering what one automation did, but creating a durable operating history that increasingly becomes the shared source of truth for everything acting on the account.

Qore is already solving the first part of that problem. The work ahead is to make that memory universal.

Three reliability questions that remain

The review of competing material raised three practical questions: What happens when a run partly fails? What prevents the same write from being sent twice? And what happens when the API rate-limits the system?

Partial failure

Qore documents actions individually, with statuses including pending approval, running, completed, failed, skipped and cancelled. A failed action can be retried without requiring successful actions in the same run to be repeated.

I have reviewed that documented design, but I have not used the accounts in this article to produce and observe a real partial failure against Amazon.

Duplicate writes

There are two different duplicate-write problems, and they should not be conflated.

The first is a future run forgetting that an earlier run already changed something. That is the problem Qore’s action record is designed to address.

The second is one instruction accidentally reaching Amazon twice — for example, because the sender is unsure whether the first request succeeded and retries it. That requires an idempotent write path or an equivalent safeguard.

I cannot point to a documented Qore guarantee today that a second copy of an already-delivered instruction will always be rejected. This article is making a claim about the first problem, not the second.

Rate limits

Rate limits are also unresolved in the public documentation I reviewed.

Amazon’s advertising API can return an HTTP 429 response when a caller exceeds its allowed request rate. None of the 19 pages in our review explained how their system handles that condition, and Qore’s current in-app documentation does not explain its own backoff or throttling behavior either.

That is a fair question for any vendor to demonstrate during an evaluation.

The real test for an AI advertising agent

The advertising industry is moving quickly from systems that answer questions toward systems that act.

The models will keep improving. The tool interfaces will improve too. And the mechanics of letting an agent launch a campaign, change a bid or alter a budget will become easier.

That makes the less glamorous engineering questions more important.

Before allowing an AI system to change a live advertising account unattended, I would want clear answers to these questions:

• What is recorded when the system makes a change?
• Can I see the value before the change and the value after it?
• Does the next run have to consult that history?
• What happens if only part of a batch succeeds?
• What prevents an uncertain retry from producing a duplicate write?
• How does the system handle API throttling?
• What happens when a human or another automation changes the same entity?
• When important information is missing, what is the agent allowed to assume?

Those are not arguments about whether Claude is smarter than ChatGPT, or whether one model has a larger context window than another.

They are questions about whether the software surrounding the model behaves like an operating system rather than a chat window.

Questions people actually ask

Can Claude manage Amazon Ads?

Claude can analyze live Amazon Ads data when connected through the appropriate tools. Whether it should manage an account unattended depends on the application around it: account binding, action history, approvals, state management, failure handling and rules for repeated writes.

What does the Amazon Ads MCP server let an agent do?

More than simple reporting. Amazon says its MCP tools can coordinate multi-step operations including account creation, report generation, campaign launch and locale expansion. MCP has become a serious operating interface for advertising agents.

Is Qore just an MCP server?

No. Qore includes a read-only MCP server for external assistants and separately uses connectors to operate against advertising accounts. The part described in this article is the action layer: work is bound to an account, missing inputs can block a run, actions are recorded, and scheduled procedures can consult their own past writes before deciding again.

Is it safe to let an AI agent change live bids and budgets?

It can be, but human approval addresses only part of the risk. Approval protects against a bad individual action. Durable state protects against a reasonable action being repeated until the cumulative result is bad.

Do I still need a rules engine?

If your existing system works reliably, keep it. The distinction is not rules versus AI. It is whether the system maintains enough history to understand the consequences of its own earlier interventions.