Human Approval for AMC Activation

Run the read-only half of an AMC workflow hands-off, and stop in one place: audience activation waits inside a Skill until a human approves the exact creation payload. The Amazon Ads MCP runs the sizing reads automatically and holds the gated submission, while Amazon Agent Atlas supplies the rules the approver checks against: the 2000-user rule-based floor, the 500 to 500,000 lookalike seed band, the 24-to-36-hour DSP lag. The policy answers a Slack message from our media lead: "If the agent builds an Amazon Marketing Cloud audience and the SQL compiles, does it push it into the demand-side platform (DSP) on its own, or does one of us sign off first?" Our agent could do either. It stops.

Why not paste the audience SQL into ChatGPT or Claude for review? A plain chat hits three walls here. No access to your data: it cannot run a sizing query against your AMC instance. No way to take action: it cannot submit or watch anything on Amazon; you do every step by hand. Generic knowledge, not Amazon's: it does not carry the activation thresholds. That is disconnected, generic, manual work that ships silent mistakes. The MCP closes the first two walls, Atlas the third; the Skill makes the gate repeatable.

An AMC audience query returns nothing you can review, so the gate must come before the POST

One line of shared playbook boilerplate settles where the gate goes: "Unlike standard AMC queries, AMC Audience queries do not return visible results that you can download. Instead, the audience defined by the query is pushed directly to Amazon DSP." A rule-based audience query selects user_id values and nothing else; once submitted, there is no artifact left to inspect. Review after submission is not late, it is impossible.

Activation queries even run on their own table surface: the _for_audiences variants, conversions_for_audiences, conversions_all_for_audiences, dsp_impressions_for_audiences, sponsored_ads_traffic_for_audiences, amazon_attributed_events_by_traffic_time_for_audiences. That suffix in a FROM clause is a machine-checkable signal that a query is an activation, not an analysis. One nuance: conversions_all_for_audiences is the audience copy of conversions_all, and the high-value-segments query built on it lists a Flexible Amazon shopping insights subscription as a requirement, so the runnable seed below stays on conversions_for_audiences.

Cost lands on the same line. The Off-Amazon Conversions Playbook is explicit: "Submitting an audience to be created is not charged. There is no cost until the audience is activated in Amazon DSP." In the console the write is a paste into the Audiences query editor; through the Amazon Ads MCP it is the POST method of the AMC rule-based Audience API, which the Skill refuses to send unsigned.

Approval is a numbers check: 2000 distinct user_ids for a rule-based audience, a 500 to 500,000 seed for a lookalike

Two thresholds decide approvability, and they never blend. For rule-based audiences the Off-Amazon Conversions Playbook states that "the minimum is 2000 distinct user_ids for a rules-based audience to be activated in the market," a floor the Programmatic Audience Framework Playbook repeats. Lookalikes answer to a different band: Introduction to AMC Lookalike Audiences requires a seed of between 500 and 500,000 user_ids, warns that refresh "will fail if the size falls below 500 or goes above 500k," and recommends 1,000 to 450,000 as the working range. A correct approval card names the one threshold that applies and puts the measured number beside it.

Measurement runs automatically. Before submission, the agent wraps the seed in the corpus's companion pattern, SELECT COUNT(user_id) AS user_count FROM (seed query) GROUP BY 1, run as an ordinary measurement query. Sizing needs no approval because it changes nothing.

The seed we gated most recently, purchasers from the standard audience table, built with the same query shape the cart-abandoner workflow assembles upstream:

SELECT
  user_id
FROM
  conversions_for_audiences
WHERE
  event_subtype = 'order'

That seed's companion COUNT came back at 12,480 distinct user_ids: above the 2000 floor with room to decay across weekly refreshes. On a lookalike, the same COUNT places the seed inside the 500 to 500,000 band; DSP's expansion tiers then run from roughly 300K to 1M members (most similar) up to 900K to 10M (most broad), region-dependent and subject to change. The corpus suggests starting balanced; a seed pinned to a tier's edge should be revised, not shipped.

The approver signs the JSON that ships: audienceName, advertiserId, the flattened query, the window, and refreshRateDays

In front of the human sits the creation payload itself, not a summary. The fields match the promotional-events lookalike playbook's example: audienceName, audienceDescription, advertiserId, the seed SQL flattened into query, timeWindowStart, timeWindowEnd, timeWindowRelative, and refreshRateDays; lookalike submissions add lookalikeAudienceExpectedReach, "BALANCED" in the corpus example. The same playbook scopes two recommendations to its pattern: refreshRateDays: 7 "to ensure optimal performance," and timeWindowRelative: FALSE to keep each refresh looking at individuals from the previous event.

Shipped text is not drafted text. Introduction to AMC Lookalike Audiences recommends removing all comment lines from the query before pushing to audience creation, and the seed gets flattened into the JSON regardless, so what a human eyeballed in an editor is not automatically what ships. The Skill closes that gap by hashing the flattened, comment-stripped query and binding the approval to the hash: change query by one character and the gate reopens.

{
  "artifact": "audience_definition",
  "workflow": "amc-activation-approval",
  "requiresApproval": true,
  "activation": {
    "audienceName": "AMC_Purchasers_Weekly_2026Q3",
    "audienceDescription": "Purchasers, June 2026 order window",
    "advertiserId": "123456789",
    "query": "SELECT user_id FROM conversions_for_audiences WHERE event_subtype='order'",
    "timeWindowStart": "2026-06-01T00:00:00Z",
    "timeWindowEnd": "2026-07-01T00:00:00Z",
    "timeWindowRelative": "FALSE",
    "refreshRateDays": 7
  },
  "checks": {
    "seedCount": {
      "measured": 12480,
      "threshold": "2000 distinct user_ids rule-based activation floor"
    },
    "tableVariant": "FROM uses _for_audiences tables only",
    "destination": {
      "advertiserId": "123456789",
      "instanceId": "amcinstance01"
    },
    "querySha256": "5b3c9f1e0a4b2d83c56a1908d7e5bc2a4f8e6d0b1a9c8e7f5d3b2a1c0e9f8d7b",
    "atlasChunks": [
      "6e39ff4c3e1ed64b",
      "3592514e4137c936",
      "9e1e29903178da48",
      "9fadd181160a41e4"
    ]
  },
  "decision": "approve | revise | cancel",
  "records": {
    "audienceExecutionId": null,
    "status": null,
    "statusReason": null,
    "audienceCount": null,
    "dspAudienceId": null,
    "lastRefreshedTime": null,
    "approvedBy": null,
    "approvedAt": null
  }
}

Two fields deserve more attention than the SQL. advertiserId is the destination: the DSP seat the audience lands in, confirmed, not assumed. And refreshRateDays makes activation a standing write, not a one-off: the query re-runs on cadence under this single approval, so the human is approving a recurring behavior, which is why the hash check stays live after the yes.

"Successful" in AMC is not "active" in DSP: allow 24 to 36 hours and keep your own run log

The clock after the approved POST belongs to Amazon. The Programmatic Audience Framework Playbook is precise: "Once an audience creation status is returned as 'successful' in the AMC API, it can take between 24 and 36 hours to be 'active' and ready for use in Amazon DSP." I nearly resubmitted after one quiet day; the playbook says that quiet day is the system working.

Amazon also leaves a hole in the audit trail. The same playbook admits there is currently "no unique id field that is common for both the AMC endpoint and Amazon DSP endpoint"; the only mapping for now is "by name and by the approximate creation date." The monitoring output does include dspAudienceId and dspCanonicalId columns, but by the playbook's own statement those values cannot join the two systems, so lean on neither. Copy its working practice instead: filter the DSP audience list by audienceName prefix, category "Custom-built," subCategory "AMC," which only works if the naming convention was enforced at approval time.

So the run log is the join key, not bookkeeping. Per audience, the agent logs what it watches by audienceExecutionId: status, statusReason, audienceCount, lastRefreshedTime, the query, and the window, next to the approval record itself, the same argument that makes run logs non-negotiable for MCP writes.

What happens next

Approval closes the gate once; the Skill keeps watching. It expects the DSP entry inside the 24-to-36-hour window and logs execution metadata on every refresh, keeping the name-plus-creation-date mapping current. When an audience stops refreshing, the playbook's diagnosis is blunt: "it is most likely the audience size has dropped below 2,000 unique users," flagged after a one-day buffer past refreshRateDays. After several failed refreshes the instruction turns operational: decrease or stop spending on that line item, because it keeps targeting the same users as they move down the funnel. Each refresh is also the moment to re-measure overlap against segments already live in Amazon DSP (via conversions_all), at launch and mid-campaign, since affinity and size metrics do not necessarily indicate overlap.

The loop runs on the Amazon Agent Data layer: the Amazon Ads MCP carries the AMC sizing reads, the gated submission, and the refresh monitoring, and the Selling Partner MCP joins when audience logic depends on catalog facts, like which ASINs a promotion actually covers. That is the whole pattern: reads run free, the one write stops at a person, and the approval binds to the exact artifact that ships.

Next: turning gated analyses like this one into repeatable AMC agent workflows, where the approval step is part of the Skill rather than a manual afterthought.

{"workflow":"amc-activation-approval","requiresApproval":true,"requiredChecks":["seed_count","table_variant","destination_advertiserId","query_hash","atlas_chunk_ids"]}