An autonomous advertising stack is easier to evaluate when it is separated into three conceptual layers: observation, decision, and execution. The observation layer establishes what is known. The decision layer proposes what to do within the business's instructions. The execution layer performs authorized actions and checks their outcomes.
This is an evaluation model, not a diagram of GaaS's internal implementation or a requirement that every vendor use three separate services. The value is in the boundaries. A buyer should be able to trace a recommendation back to evidence and trace a reported action forward to an observed provider result.
Layer one: observation with usable context
An advertising metric is incomplete without its account, date range, time zone, attribution definition, currency, and retrieval time. A system that knows yesterday's reported purchases but not whether the import completed may make a confident decision from partial evidence.
The observation record should identify the source and the limits of the data. Distinguish observed values from estimates, unavailable fields, and failed requests. Preserve enough context to reproduce a material finding without storing unnecessary personal information.
Ask how the system handles conflicting reports. Platform-attributed revenue, analytics purchases, and an order ledger may answer different questions. The stack should not silently choose whichever number supports its recommendation. Our stale-data checks provide a worksheet for defining when particular inputs are too old or incomplete for a particular action.
A useful acceptance case is simple: interrupt a data feed in a test environment and inspect what the system reports. Does it identify the missing period and limit the dependent decision, or does it reuse an old value without disclosure? The latter can be more dangerous than an obvious error.
Layer two: a decision tied to a specific objective
The decision layer needs a business objective, constraints, and an explicit scope of authority. “Improve performance” is not enough to resolve a tradeoff between volume, margin, cash exposure, and sales capacity.
A useful proposal identifies the target account and object, current relevant state, suggested change, supporting evidence, assumptions, expected effect, and review condition. It should also be able to conclude that no action is justified. A system rewarded only for producing changes may generate activity without improving decisions.
Keep native platform automation in view. Google Smart Bidding optimizes bids for conversions or conversion value in auctions. An external operator may manage other account-level decisions around that automation. Treating both as one undifferentiated AI capability makes it difficult to know which system controls which lever.
Layer three: execution with constrained authority
Execution should receive a specific authorized action, not an unrestricted instruction to pursue the goal by any available means. Confirm the account and object identifiers, the operation allowed, and any relevant limits before changing state.
An AI agent permissions matrix can distinguish read-only analysis, drafting, approval-gated changes, and bounded automatic actions. Those distinctions should be reflected in available controls. A friendly promise in a prompt is weaker than a workflow that cannot access an out-of-scope account or mutation.
OWASP's AI agent security guidance discusses least privilege and untrusted inputs. For an advertising workflow, a practical implication is to treat retrieved pages, creative files, and tool outputs as evidence to inspect, not as new authority to change campaign instructions.
Define the handoff contract between layers
The following fields make the conceptual boundaries reviewable. They are a suggested design for evaluation, not a universal provider API schema.
| Handoff | Required context | Failure the context helps expose |
|---|---|---|
| Observation to decision | Source, account, window, definitions, freshness, missing data | A recommendation based on the wrong account or incomplete period |
| Decision to approval | Proposed change, rationale, assumptions, limits | An approver authorizing a different action from the one executed |
| Approval to execution | Exact scope, version, target identifiers, relevant current state | A stale approval applied after conditions changed |
| Execution to observation | Request reference, item outcomes, provider readback, timestamps | A submitted request being reported as a verified result |
Version material proposals. If a user approves pausing one campaign, the approval should not silently become permission to pause a broader set after the model revises its plan. When current state differs materially from the approved proposal, the workflow should apply its defined revalidation or approval policy.
Design for partial and ambiguous outcomes
A network timeout does not always mean an operation failed. A batch response does not always mean every item succeeded. The execution layer needs operation-specific recovery and reconciliation rather than a blanket retry that can repeat a consequential action.
Google's partial failure documentation illustrates why item-level outcomes matter for supported API requests. Preserve successes, failures, and unresolved results separately. If only part of a proposed change occurred, report that state before making a new optimization decision.
Use the agent change log template to connect the chain. A buyer should be able to select one consequential action and inspect the evidence, approval, execution response, and current readback without relying on a generated retrospective story.
Evaluate the boundaries through a small scenario set
Ask a vendor to demonstrate the workflow in a safe test setup using a stale report, an out-of-scope account request, a changed object, a partial failure, and an unavailable provider response. Define the expected behavior before the demonstration.
For each case, check whether the system preserves identity, respects authority, reports uncertainty, and offers a recoverable next step. Do not score a refusal to perform an unauthorized operation as a failure of autonomy. Scope enforcement is part of the intended behavior.
Then evaluate ordinary work: can the operator explain a useful recommendation, complete an authorized task, and produce a clear receipt? Reliability includes both stopping at the right boundary and progressing competently within it.
Connect architectural quality to business evidence
A well-designed stack can still optimize the wrong metric or operate an unprofitable offer. Review business outcomes alongside operational behavior. Keep the distinction between a successful action, a better campaign metric, and additional contribution.
Use the three-layer model to identify where a weakness belongs. Repair the data contract when observations are unreliable, the objective when decisions pursue the wrong tradeoff, and the execution controls when results cannot be verified. That diagnosis is more useful than deciding that a product is broadly autonomous because it can generate a plausible recommendation.