# Agentic Ad Lab — full text corpus

> Protocol-neutral reference for agentic advertising: AdCP, AAMP, and how machines buy media.

Generated 2026-08-13. 11 documents.

---

# AdCP vs AAMP: Which Standard to Implement

Source: https://agenticadlab.com/protocols/adcp-vs-aamp/

AdCP and AAMP are the two agentic advertising protocol stacks. AdCP is one specification of 64 operations pinned at 3.1.13; AAMP is an IAB Tech Lab umbrella over eight independently versioned repositories that share no data type. Implement AdCP first.

Back AdCP. If you have one integration budget for the next two quarters, spend it there and keep AAMP as a watch item with a named owner and no engineers attached.

AdCP publishes one number for the whole specification in a file you can fetch: dist/schemas/latest.json reads 3.1.13 stable, and that release carries 64 operations across 10 areas. Freeze the directory, run a conformance suite against it, re-run the same suite next quarter against a byte-identical artifact. AAMP is eight repositories versioning independently, and the one holding the buyer-to-seller wire contract, iab-agentic-primitives, calls itself a pre-release whose "APIs, schemas, and package layout may still change between releases until a 1.0 IAB Tech Lab standardization". A supply contract needs a conformance clause, and that sentence will not carry one.

The umbrella version does not close the gap. IAB Tech Lab announced AAMP 2.3 on 30 July 2026 and the number matches no tag, no release and no version field in any of the eight repositories; the hub had zero tags on the day of the announcement and has zero tags now.

A counterparty that publishes only an AAMP agent card flips the call, because you implement what they serve. So does serve-time work. ARTF lets a third-party agent patch the bid object while the auction clock is running, inside somebody else's OpenRTB auction under tmax, and AdCP has nothing at that layer to compete with it. That work goes to your general counsel before it reaches an engineer: the Go implementation is AGPL-3.0 under Index Exchange copyright.

Your first move, by side

If you sell inventory, publish two static documents this week. adagents.json and brand.json at /.well-known/ make you discoverable to a buying agent before you implement a single operation, and no protocol decision blocks them. The AAMP equivalent is an agent card plus a registry entry to resolve it, which costs more and reaches fewer buyers today.

If you buy, run one HTTP request per counterparty domain before the protocol argument starts. Does the domain serve /.well-known/adagents.json, or hand you an agent card and a registry to resolve against? The responses decide your order of work, and the discovery file guide covers what comes back. If nothing resolves across your top twenty partners, you are early: put a date in the calendar and spend the budget elsewhere.

The two stacks, job by job

AAMP has no single surface to cite, so its column names repositories: naming operations would imply a coherence that is not there.

| Job to be done            | AdCP 3.1.13                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | AAMP (per repository)                                                                                                                                                                                                                                                                                                             | What it costs you                                                                                                         |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Agent discovery           | getadcpcapabilities, plus adagents.json at /.well-known/adagents.json and brand.json at /.well-known/brand.json, all hosted on the domain itself.                                                                                                                                                                                                                                                                                                                                                   | GET /.well-known/agent.json (Agent Card) and POST /registry/agents/discover in iab-agentic-primitives, resolved through a registry.                                                                                                                                                                                         | Two static files on your own origin, against a registry entry somebody else has to grant.                                 |
| Trust                     | Authorisation and grading are separate mechanisms. What authorises a transaction is the publisher's adagents.json declaration plus RFC 9421 request signing, normative in 3.1, with AAO Verified as an out-of-band conformance mark. The graded value is derived by the consumer, never issued: five states, inline, mutualassertion, onesidedbrand, onesidedhouse, standalone, computed from brand.json parenthouse against the publisher's brandrefs[], and left to deployer policy. | Five states, issued: Agent.truststatus enum unknown, registered, approved, preferred, blocked. Its own description: "Registry-verified trust status. Caps the effective AccessTier; never self-asserted by the agent."                                                                                               | AdCP's grade is advisory. AAMP's caps the price you are shown.                                                            |
| Inventory discovery       | getproducts, with a required buyingmode of brief, wholesale or refine; listcreativeformats.                                                                                                                                                                                                                                                                                                                                                                                                 | GET /products, GET /products/{productid}, POST /products/avails in iab-agentic-primitives; media kit and package endpoints on seller-agent.                                                                                                                                                                            | The one job both stacks do, and the only one a vendor demo will show you.                                                 |
| Negotiation               | No priced multi-round negotiation. The nearest surface is getproducts with buyingmode: "refine", where each entry carries a natural-language ask and a proposal-scoped action of include, omit or finalize.                                                                                                                                                                                                                                                                                     | First class and numeric. POST /api/v1/negotiations/messages carries action (accept, counter, finaloffer, reject), buyerprice and roundnumber; the response returns concessionpct and cumulativeconcessionpct.                                                                                           | A concession budget on the AAMP side, spent in rounds. On AdCP, a seller you have to trust to re-price honestly.          |
| Transaction               | createmediabuy with a required idempotencykey, account, brand, starttime and endtime, returning mediabuyid. updatemediabuy applies PATCH semantics.                                                                                                                                                                                                                                                                                                                                    | Two steps. POST /api/v1/quotes mints a quoteid; POST /api/v1/deals books it and mints a dealid; POST /api/v1/change-requests handles modification after booking. idempotencykey is required on both quote and booking.                                                                                             | Two round trips on AAMP where AdCP takes one, and a second idempotency surface to test.                                   |
| Creative                  | buildcreative, previewcreative, synccreatives, listcreatives, listtransformers, getcreativedelivery, listcreativeformats, validateinput.                                                                                                                                                                                                                                                                                                                                              | No creative operation. Creative, Assignment and CreativeApproval exist as objects in iab-agentic-primitives; agentic-direct exposes createcreative and createassignment MCP tools whose handlers call generateMockResponse. seller-agent's API has no creative endpoint anywhere in it.                       | AAMP has none, so creative review stays a manual process sitting next to the agent.                                       |
| Signals and audiences     | getsignals, activatesignal, and syncaudiences for hashed first-party CRM records.                                                                                                                                                                                                                                                                                                                                                                                                                      | agentic-audiences, a draft embedding exchange using application/vnd.ucp.embedding+json; v=1, plus POST /agentic-audience/match on seller-agent. The schema that would connect the format to either agent, specs/v1.0/schema/agentinterface.schema.json, is zero bytes.                                                 | Any delivery date quoted for audience activation over AAMP is a date for somebody to write the empty file first.          |
| Serve-time decisioning    | Trusted Match Protocol, AdCP's serve-time layer: contextmatch and identitymatch, two structurally separated operations carried over direct HTTP instead of MCP or A2A. Returns eligible packages, no auction.                                                                                                                                                                                                                                                                                             | ARTF v1.0 (the Agentic Real Time Framework, in the agentic-rtb-framework repository): RTBExtensionPoint.GetMutations(RTBRequest) returns RTBResponse, a list of JSON-Patch-shaped mutations keyed on an Intent enum with eight defined intents plus an unspecified zero, applied inside the OpenRTB auction under tmax. | A general counsel review before an engineer opens the ARTF repository.                                                    |
| Governance and consent    | 22 of the 64 registry entries, including checkgovernance, syncplans, reportplanoutcome, getplanauditlogs, property and collection CRUD, calibratecontent and validatecontentdelivery. No consent tag on the wire.                                                                                                                                                                                                                                                                         | No governance operation. ConsentContext carries eight fields (applicableregimes, diligencestatus, gdprapplies, gppsectionids, gppstring, tcfstring, usprivacy, verifiedat) and is optional everywhere it appears. Plus DecisionRecord and seller-agent's /approvals human-review endpoints.      | AdCP gives you an audit trail and no consent tag; AAMP gives you a consent object that is optional everywhere it appears. |
| Measurement and reporting | No measurement operation group. Delivery and outcome data move through getmediabuydelivery, provideperformancefeedback, synceventsources, logevent and reportusage, alongside four core objects: measurement-terms, measurement-readiness, measurement-window, outcome-measurement.                                                                                                                                                                                                  | No measurement object in the wire contract. Reporting is per implementation: /gam/report, /api/v1/deals/{dealid}/performance and /api/v1/orders/report on the seller agent, /reports/{jobid} and /meta/report on the buyer agent.                                                                                     | A per-vendor reporting integration either way.                                                                            |

AdCP has no priced negotiation. AAMP has no creative operation, no governance operation and no measurement object in its wire contract, which is three blanks against one. Two groups made different bets about which part of a media transaction is the hard part. How a machine buys media traces one purchase at the wire level; AAMP Explorer breaks the right-hand column out repo by repo.

The object models do not compose

The transports compose. The object models do not: an AdCP mediabuy and an AAMP Deal are unrelated types with unrelated lifecycles, so an agent that already speaks MCP is adding a vocabulary, while a buyer who wants both stacks is buying two integrations and two conformance suites.

Negotiation is where that costs money. AdCP negotiates in sentences: a buyer who wants a cheaper plan sends refine with ask: "reduce total by 10%" and lets the seller re-price. AAMP negotiates in numbers, bounded by an access tier the seller assigns to your API key rather than one you claim. The caps are percentages of the seller's own opening price: public gets three rounds, 3% per round and 8% cumulative; advertiser six rounds, 6% and 20% (AAMP Explorer reproduces the table). AdCP's model is more expressive and much harder to test, and on price I want the numbers.

NegotiationMessage makes idempotencykey required and the seller agent's handler never reads it, so a retried request counts as a fresh round. On the public tier that is one of your three rounds and 3 of your 8 cumulative points gone to a timeout nobody logged.

AAMP's registry issues its five trust states and they cap the prices a buyer is shown. AdCP's five are computed by the consumer from two self-published documents, advisory by design, and they touch no price at any point. The trust status entry has both enums side by side.

AdCP's own FAQ files the rivalry away in one line: "Put simply: AAMP is agentic bidding; AdCP is agentic buying." ARTF fits that sentence. The rest of AAMP does not, because its wire contract exposes /products, /api/v1/quotes, /api/v1/deals, /api/v1/change-requests and /api/v1/negotiations/messages over OpenDirect 2.1, which is quote, negotiate, book and amend, the campaign layer AdCP occupies. The same table, stamped "As of April 2026", calls AAMP's public schemas "Being defined"; there are 48.

<details
<summaryThe two stacks do not share a noun for the sell side.</summary

AdCP's glossary defines a sales agent as "an MCP server that exposes publisher inventory for discovery and purchase". AAMP calls the same role a seller agent and named a repository after it. That matters when your RFP asks a vendor whether they support agentic buying and both sides answer yes. The term map lines the two sets of nouns up.

</details

Anthony Katsur is right that "standards proliferation is a real cost to the industry", and right that "when you remodel the kitchen, you don't burn down the house" — AAMP is built on OpenDirect 2.1, AdCOM and OpenRTB, all IAB Tech Lab work. What the metaphor hides is that his remodel shipped as eight rooms with eight release schedules and no plan covering the house. Andrew Casale calls the category "a soup of confusion" and the evidence backs him, though the soup is thickest inside AAMP: eight repositories, four with no tag at all, a press-release version that matches none of them, and one component that nobody can route around shipped under a licence that reaches its host's users.

Craig Tuck's objection, that "the biggest risk we see with an innovation like AdCP is decreasing transparency and control", and Paul Bannister's claim that agentic trading "puts the buyer directly in touch with the publisher's ad server and removes other middlemen", are both true, of different planes. The campaign path is buyer to publisher, with a record of who agreed what. The auction path is a mutation applied to somebody else's bid inside somebody else's auction under a timeout. Which path you buy on decides which of the two you get.

Governance, licensing and the AGPL problem

|                          | AdCP                                                                                                                                                                                                                                                                    | AAMP                                                                                                                                                                                                                                                                                                                                                                |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Steward                  | AgenticAdvertising.org (AAO), a pending 501(c)(6) Delaware trade association                                                                                                                                                                                            | IAB Tech Lab                                                                                                                                                                                                                                                                                                                                                        |
| Governance documents     | CHARTER.md and IPRPOLICY.md in the repository, with Bylaws, Membership Agreement and Antitrust Policy published at agenticadvertising.org                                                                                                                          | The hub README, four bullet points: contributions go to the child repository, architectural proposals to the hub, cross-cutting changes discussed first, IAB Tech Lab policies apply                                                                                                                                                                                |
| Release model            | Single semantic version. dist/schemas/latest.json is the oracle. Wire pins are release-precision ("3.1"), never patch-level                                                                                                                                         | "Each repository uses independent semantic versioning. Cross-repository alignment occurs via governance coordination."                                                                                                                                                                                                                                              |
| Versioning oracle        | Published, machine-readable, currently 3.1.13                                                                                                                                                                                                                           | None. Eight git tag outputs, four of them empty                                                                                                                                                                                                                                                                                                                   |
| Licence                  | Apache-2.0 across the repository                                                                                                                                                                                                                                        | Mixed. Apache-2.0 for the hub, buyer-agent, seller-agent, agentic-direct and iab-agentic-primitives. ARTF's Go implementation is AGPL-3.0, copyright Index Exchange; the ARTF specification is CC BY 3.0. agentic-audiences is CC BY 4.0 for specs and Apache-2.0 for code, copyright LiveRamp. registry-agent-example ships no licence file at all |
| Reference implementation | Handed to the Prebid community in February 2026, reported by AdExchanger. AAO owns the specification, Prebid owns the software | The reference implementations are the deliverable. buyer-agent and seller-agent are where the protocol currently lives                                                                                                                                                                                                                                          |

"AAMP is Apache-2.0" is a reasonable assumption and it is false. ARTF's LICENSE file is the GNU AGPL v3 text, and the README spells it out: copyright Index Exchange Inc., AGPL-3.0. Vendor that Go implementation into a hosted exchange and section 13 puts your users in scope, reaching every buyer that hits your endpoint. That belongs in the first vendor call.

AAO's interim board is half one vendor and its own FAQ says so: four interim directors, two of them Scope3-affiliated, and a first Annual General Meeting dated 6 May 2026. That is more than a body still calling its own incorporation pending has to publish. I price that concentration in and take the disclosure, because a published imbalance is one you can write a contract clause against. IAB Tech Lab wrote OpenRTB, AdCOM, OpenDirect and GPP, and both stacks stand on those. Neither fact shows up in a schema diff, and both matter more to a five-year bet than any operation count.

The press release version number is worth pinning down, because the hub is where a buyer would look for one. Its stated job is to reference stable releases for ecosystem clarity, and it has zero tags and zero releases, its last commit predates the AAMP 2.3 announcement by three and a half months, and its README still omits the wire contract that both reference agents pin in their pyproject.toml. Here is what the tags said on the day of the announcement, and what they say now.

| Repository               | Tag on 2026-07-30                     | Tag now                        | Listed in hub README |
| ------------------------ | ------------------------------------- | ------------------------------ | -------------------- |
| AAMP (hub)             | none                                  | none                           | is the hub           |
| iab-agentic-primitives | v0.5.0, tag only, no GitHub release | v0.5.1, published 2026-08-10 | no                   |
| seller-agent           | v2.3.3, published 2026-07-29        | v2.4.1, published 2026-08-05 | yes                  |
| buyer-agent            | v2.3.0, published 2026-07-22        | v2.4.1, published 2026-08-10 | yes                  |
| agentic-rtb-framework  | v1.0, published 2026-07-20          | v1.0                         | yes                  |
| agentic-direct         | none                                  | none                           | yes                  |
| agentic-audiences      | none                                  | none                           | yes                  |
| registry-agent-example | none                                  | none                           | yes                  |

The closest things to 2.3 are the buyer agent's v2.3.0, already out for eight days when the announcement landed, and the seller agent's v2.3.3. Both are one team's application tag, and both are gone. Three independent releases followed within twelve days, and no number covers any two of them. The per-repository breakdown has the rest.

AdCP will cost a person's attention every month, permanently. It published four patch releases in the first eleven days of August and it dates its removals in advance: formatids deprecated in 3.2 and removed in 4.0, package bidprice deprecated in 3.2 in favour of bidding. One release, 3.1.3, is marked "Withdrawn. Do not use." with the reason attached and still sitting in the tree. I would take that trade every time, and I would put the owner's name on it before the first integration ships.

AdCP is stale about itself too. docs/reference/versions.mdx names 3.1.12 as current stable, dist/schemas/ in the same checkout carries 3.1.13, and the AAMP comparison table in docs/faq.mdx still calls AdCP "3.0 GA (released April 2026)". Both projects drift from their own code in their own prose. The difference is that one of them publishes an oracle you can fetch and diff the prose against.

Where each stack thins

AdCP's full surface is public and needs no membership. An engineer integrating against it can answer "what does this field mean, and what happens if I omit it" without booking a call with a working group.

AAMP's control plane carries a warning label with real work underneath it: 13 operations and 48 JSON Schema files in iab-agentic-primitives, a large OpenAPI surface and an MCP tool set on each reference agent, a 534-line ARTF specification with a protobuf contract. Most of that is one team's application, and it moves on the next minor release.

registry-agent-example is a 22-line agent.ts. Six files in agentic-audiences are zero bytes, including the schema that would join the embedding format to either agent, specs/v1.0/schema/agentinterface.schema.json, and the specification that does have content titles itself "Draft v0.1" from inside a directory named v1.0. The client that would make registry-mediated discovery work is called "the legacy stub retained as the default" in the seller agent's own source. Discovery is where AAMP is least finished; the AAMP page has the repo-level verdicts.

iab-agentic-primitives also ships a standards gap report whose stated rule is the best sentence in either corpus: "'We model a field named after a standard' is never treated as 'we verified conformance against the published standard'." AdCP's conformance suite is bigger and points inward, testing AdCP against AdCP. And ConsentContext gives a GPP or TCF string somewhere to sit on the wire, where AdCP's limitations page says it "does not carry a normative consent tag".

Neither stack standardises measurement or attribution. AdCP carries exposure records and outcome signals "but it does not specify an attribution model", and says it "is not MRC-accredited and does not seek accreditation"; AAMP's wire contract has no measurement object at all. Amy Porter's worry that agents "could obscure critical decision-making if advertisers rely too much on AI" lands on exactly that seam: on the question a CFO asks first, both stacks hand the problem back and reporting stays a per-vendor integration. What neither stack standardises has the rest.

None of that volume measures deployed traffic, and neither corpus carries an adoption figure. What is measurable from outside is thin and real: of the 23 agents in AdCP's public registry on 12 August, 13 completed an anonymous MCP handshake and three sales agents returned a product catalogue to a caller with no credentials (the full sweep).

Three sales agents handing a product catalogue to an unauthenticated caller is a security finding as much as an adoption one. Early deployments are running open, which is itself an argument for moving now, while the norms about who gets to see a rate card are still being set. Every named agentic buy that has run in public so far ran on AdCP or on raw MCP, and none of it is large (the deployment ledger).

What would change this analysis

Each of these is a file change, checkable without waiting for a press release.

1. iab-agentic-primitives tags at 1.0 or above. That moves AAMP from implementations-with-an-emerging-contract to contract-with-implementations, and it is the trigger to watch.
2. A first tag on the hub. The umbrella carries no tags at all, which is what the whole pinning argument above rests on.
3. A non-empty agentic-audiences/specs/v1.0/schema/agentinterface.schema.json, the join between AAMP's data plane and everything else.
4. seller-agent's AAMPRegistryClient stops being the legacy stub, which registry-mediated discovery needs before a buyer can rely on it.
5. Either corpus references the other. The first adcp string in an IAB Tech Lab repository would be the first sign that anyone intends the two to interoperate.

If you would rather not watch them yourself, that is the work I sell.

---

# The Autonomy Ladder for Agentic Media Buying

Source: https://agenticadlab.com/guides/autonomy-ladder/

The autonomy ladder is the five rungs between an agent that only reads your delivery data and one that moves money unattended. Vendors sell rung placement as a buyer-set dial; it is set by whichever counterparty's implementation is loosest.

Every vendor deck in this category lands on the same sentence: humans set the rules, agents operate within them. Nobody publishes the rules. Five rungs sit between reading your campaign data and moving your money, and each one is enforced, or not enforced, by a specific field. Those fields invert the framing. Autonomy is not a dial the buyer sets. It is a property of whichever counterparty's implementation is loosest, and the buyer usually can't see it.

An ad ops lead put the question to r/adops directly:

 How much trust do you put in these new AI agents to execute optimizations and shift budgets, or are you also just using them as reporting assistants? What's a part of the process that is NEVER going to be taken by AI?

The top reply:

 we automate the boring plumbing, data pulls, normalization, anomaly alerts, basic pacing dashboards, because that's repeatable and easy to QA at scale. budget shifts and bid changes stay human since context like client politics, promo timing, and platform quirks still matter a lot.

The five rungs

| Rung          | What the agent may do                                          | What breaks if it is wrong                                       | How you undo it                              | Wire mechanism                                                                                                                    |
| ------------- | -------------------------------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| 1. Read       | Pull delivery, forecasts, product catalogues; normalise; alert | A wrong number in a client deck                                  | Resend the deck                              | None. Your own key scoping, plus MCP readOnlyHint where a seller sets it                                                        |
| 2. Propose    | Assemble the exact buy and stop before the write               | Nothing. No spend committed                                      | Discard the draft                            | paused: true on createmediabuy. The gate itself is buyer-local                                                              |
| 3. Envelope   | Mutate a live buy inside tolerances the seller declares        | Over-delivery on the wrong package at your own CPM               | updatemediabuy mid-flight                | availableactions[].mode: conditionalselfserve; budget.reallocationthreshold                                               |
| 4. Post-hoc   | Commit spend; findings logged, not blocked                     | A weekend of budget in the wrong place                           | Pause, then argue about the cancellation fee | Governance mode: advisory, reported not set; PACINGHOLD in IAB Tech Lab's buyer agent, which is reference code               |
| 5. Unattended | Reallocate freely up to the plan total                         | The cap is the only thing between the agent and the whole budget | Nothing below the cap                        | budget.reallocationunlimited: true; floorprice and round caps, which are seller-agent constants rather than protocol fields |

The fourth column matters more than the second. Between rungs 3 and 4 the undo stops being a keystroke and becomes a contract negotiation.

Two dials are in play in that table and only one of them is a ladder. Rungs 1, 2, 3 and 5 grade how much the agent may write. Rung 4 grades when a human looks, and post-hoc review attaches to any rung above the first: a plan can carry unlimited budget reallocation and still escalate every targeting decision, and conflating the two dials is the most common misreading of this layer.

Picking a rung

Start at 1. Move up only when the next rung's entry condition — a tolerance document, a cancellation policy that is not fullcommitment, a declared aggregation window — is true of the specific buy in front of you.

Then adjust for the account. Duluth Trading hands bidding and creative iteration management to agents through its agency and its marketing director reports being comfortable with it. The risk profile of a bid adjustment on a retail account is not that of a pharmaceutical campaign at Bayer, whose digital media activation lead told Digiday's Programmatic Marketing Summit in May 2026, "I want a person overseeing the bot."

Rung 1: read-only is where nearly everyone is

A wrong read costs you a correction. That's the whole risk, and it is where every practitioner in that thread reported shipping. A TeqBlaze engineer: "Anything involving pacing, budgets, or major decisions - still remains fully human." When a marketer posted an open-source plugin letting Claude reallocate budget through the Google Ads API, the first reply was one line: "The official Google ads mcp server is read only." One line from one reply is the closest thing there is to a public statement of where a large platform put its own connector.

AdCP has no read-only mode for production data. account.sandbox looks like one and does something else, marking "a sandbox account — no real platform calls, no real spend," a separate test account returning fake delivery. Rung 1 is pulling real delivery and alerting on real anomalies, so sandbox cannot express it.

What holds this rung is out-of-band. Your credential is scoped to discovery and reporting calls, and nothing in the request or the response says so. The one machine-readable hint is MCP's readOnlyHint annotation, and of the 13 registered agents that answer tools/list only three set it. Every agent exposing createmediabuy leaves it blank, so a client cannot tell a read from a write by inspection.

Rung 2: propose the diff, spend on a second call

A tool author in the same thread put up a proposal and asked practitioners to shoot it down:

 i'd automate reads, normalization, anomaly checks and draft actions. for spend-changing writes, i'd let the agent prepare the exact before/after but require a second call with identical args. that's the line i'm testing in adport; i'm the author and would love adops people to tell me where the approval gets too annoying.

The shape is right. Approving "shift 15% from CTV to display" is not the same act as approving the twelve-field object that shift turns into, and a second call with identical arguments makes the human's approval refer to the object. Every buy with a spend-changing write in scope belongs here, whatever anyone's maturity model says, and it costs you one extra call.

AdCP doesn't give you this. There is no dryrun on createmediabuy; the only dryrun in the media-buy domain of 3.1.13 sits on synccatalogs, which is inventory housekeeping. The nearest affordance is paused: true on createmediabuy, which commits you contractually and then withholds impressions.

Issue #6381 on the AdCP repository, filed 11 August 2026, states the gap exactly:

 Today the only way to honor this is inside the buyer's own agent orchestration — simply not calling createmediabuy until a human clicks approve. That gate is invisible to the counterparty, can't be verified by a heterogeneous partner, and leaves no shared record.

Rung 2 is real, widely intended, and lives entirely off the wire: your approval log and your seller's booking log are disconnected silos. The RFC proposes having the governance agent mint a humanapproval claim, with an opaque approverref, inside the signed token that already travels with the buy.

AAMP's buyer agent ships rung 2 as a default, in code, and the default fails closed: waitforapproval times out after 3600 seconds, an unseen request silently becomes a rejection, and the campaign stalls rather than errors, which means it stops without paging anyone. ApprovalConfig in models/campaignbrief.py has four booleans: planreview and booking default to True, creative and pacingadjustment to False. Plan and spend gated, creative and pacing not, which is close to what the thread describes.

Those defaults answer the tool author's question about where approval gets too annoying, and the answer is milder than the fear. Pacing adjustment, the high-frequency stage, is ungated, so approval volume scales with deals booked rather than with days the campaign runs: a ten-line plan costs a couple of clicks at the front and nothing after until somebody changes the plan.

Check two things before citing the config as a standard. checkapprovalrequired is called nowhere outside the approval module; the flow that books deals, flows/dealbookingflow.py, has its own hard-coded stop at AWAITINGAPPROVAL plus an approveall() method, and the CampaignBrief class that flow consumes, in models/flowstate.py, carries no approvalconfig field. The repository has two brief classes and one gate config, and the config is attached to the class the booking flow does not use.

Rung 3: the mode is on the wire, the numbers are not

This is the rung the market is selling: the agent operates freely inside a pre-agreed boundary and escalates outside it. AdCP models it properly, giving each action a seller allows on a buy a mode from a three-value enum. The column that matters is the third.

| Mode                     | What the seller does with your mutation                                             | Can you predict the outcome before you call?       |
| ------------------------ | ----------------------------------------------------------------------------------- | -------------------------------------------------- |
| selfserve             | Honours it synchronously, no approval                                               | Yes                                                |
| conditionalselfserve | Auto-approves inside declared tolerances, escalates outside them                    | No. The tolerances are not on this surface         |
| requiresapproval      | Puts a human on its own side in the loop, asynchronous, resolved by poll or webhook | Yes, in the sense that the answer is always "wait" |

The middle value is where programmatic guaranteed lives, and the mode description names FreeWheel, Magnite and GAM as the platforms "where small mutations clear automatically but large ones queue for human review." The same description then concedes the problem:

 Constraint metadata defining the tolerances is out of scope for v1 [...] until #4425 lands, tolerances are declared out-of-band and buyers cannot statically predict which mutations will auto-approve from this surface alone.

An envelope whose edges you can't read is a surprise with paperwork on it, and your agent finds the edge by trying, in production, on a live guaranteed buy. So the entry condition for this rung is a document rather than a field: the seller's conditionalselfserve tolerances, in numbers, in writing. If nobody has sent you one, you are on rung 4 with extra steps.

The third mode deserves more than the joke, because publisher-direct sellers will live on it. requiresapproval is "human-in-the-loop, asynchronous, no proposal artifact," and the call returns status: 'submitted' with a taskid covering "long-running execution (hours to days)," resolved by polling tasks/get or by webhook. No schema carries a deadline: no expiry on a pending approval, no field for how long the seller's operator has, no terminal state for a request nobody opens. The clock that decides when a pending approval has gone stale has to live in your own orchestration, and somebody has to be paid to watch it.

The buyer-side half is better specified. A campaign governance plan pushed through syncplans carries budget.reallocationthreshold: "Amount above which budget reallocations require human escalation. The orchestrator can reallocate spend across sellers, channels, or purchase types up to this threshold per change without asking a human [...] set to 0 to require approval for every reallocation." A numeric autonomy dial denominated in the plan's currency, and the single field here I would most want an agency to fill in deliberately. Both of the checkgovernance schemas that consume it, request and response, carry "x-status": "experimental".

AdCP reads "per change" literally. An agent under a reallocationthreshold of 5,000 moves 4,999 as often as it likes. The defence sits on a different surface: getadcpcapabilities lets a governance agent declare an aggregationwindowdays, the trailing window over which it sums committed spend before testing any dollar threshold. Without it, the schema warns, "a buyer can split a single large spend into many sub-threshold commits across plans / task surfaces / time and bypass every dollar-gated escalation," and silence implies nothing: absence "indicates the governance agent has not committed to any aggregation window and buyers MUST assume per-commit evaluation only." Ask for the declared window before you pick a threshold, because against an agent that declares none the number you set caps one change and nothing else.

AAMP's envelope parameters constrain your own agent and nobody else's, because none of them are asserted to the seller: DealPreferences.maxcpm, FrequencyCap as a maximpressions plus periodhours pair, and PacingModel with four values (EVEN, FRONTLOADED, BACKLOADED, CUSTOM).

Rung 4: spend first, review after

AdCP's governance mode enum is the cleanest description of this rung in either corpus. audit always returns approved, advisory returns findings but does not block ("Human reviews happen post-hoc"), enforce blocks. Escalation severity sits alongside it with three values, of which two gate behaviour: warning means "agent may proceed but human should review within a deadline," critical means "agent must not proceed until human approves." The third, info, is "logged for audit, no action required."

Neither enum is a control a buyer can set. Both appear only on responses: mode on checkgovernanceresponse and getplanauditlogsresponse, severity on those plus reportplanoutcomeresponse. No request field carries either, and the mode description says what it is for, letting "counterparties, regulators, and auditors distinguish whether a finding blocked execution (enforce) or was logged silently (audit)." You configure the mode inside your own governance agent, and the wire reports which one was in force once it no longer matters.

What makes rung 4 expensive is the contract underneath it, not the protocol. cancellation-policy.json gives sellers a noticeperiod and a cancellationfee whose type may be fullcommitment: "buyer owes the full committed budget regardless of delivery." Canceled buys cannot be reactivated. Post-hoc review of a guaranteed buy means reviewing something you may have to pay for either way, so the rung is only defensible on a buy whose cancellation policy is something other than fullcommitment.

Henry Webster of Kelly Scott Madison put the fear in the form every agency lead will recognise, at Digiday's Programmatic Marketing Summit in May 2026: "Would it blow a quarter's worth of budget in a weekend?"

The nearest thing to an answer is thinner than it looks, and it is not in AdCP. IAB Tech Lab's buyer agent declares a campaign state called PACINGHOLD, distinct from a manual PAUSED, with legal transitions ACTIVE → PACINGHOLD labelled "automated pacing deviation threshold" and PACINGHOLD → ACTIVE labelled "deviation resolved, auto-resume." Separately, pacing/engine.py measures deviation against configurable thresholds, 10% for a warning and 25% for critical in both directions, and on breach emits a PACINGDEVIATIONDETECTED event and returns a PacingAlert.

Nothing joins the two. Outside models/statemachine.py and a status-string map in storage/campaignstore.py, PACINGHOLD appears nowhere in the source, and no code performs the transition. The pacing guide hedges to match, saying the state machine "can transition" the campaign. The industry's strongest automated brake on this rung is an unwired enum sitting next to a detector that files a report, and 25% is a critical alert threshold rather than a hold trigger.

Above rung 3, AAMP has nothing at all: no governance mode, no escalation severity, no automated hold. Rungs 4 and 5 are an AdCP-only conversation. What an AAMP buyer gets instead is DecisionRecord, an audit object carrying a DecisionActor whose kind discriminates human from machine, plus rationale, policy refs and a moneyeffect. It records who decided and why, after the fact, and it is never embedded on a Deal, Order or Quote, so it documents the spend without being able to interrupt any of it.

Rung 5: unattended, inside a cap

AdCP has a field for declaring this on purpose. budget.reallocationunlimited: true is mutually exclusive with reallocationthreshold, and the schema says why it exists rather than letting you set the threshold to the total: "Use this for deliberate full-autonomy declarations rather than setting reallocationthreshold: total (which silently tightens when total changes)." Someone thought about the failure mode where a budget cut quietly revokes an autonomy grant.

plan.humanreviewrequired is orthogonal to the money dial and the buyer can't switch it off. When a resolved policy carries requireshumanreview the governance agent must set the flag: "A buyer cannot opt out of human review by omitting the flag." It exists for GDPR Article 22 and EU AI Act Annex III verticals, which is why the money dial and the review dial move independently of each other.

On the sell side, rung 5 is already the default in the reference code. Any publisher deploying IAB Tech Lab's seller agent unmodified has put price negotiation on rung 5 while their buy-side counterpart is still arguing about rung 2. Its negotiation engine accepts, counters or walks away with no human in the path, guarded only by a floorprice and a per-tier round limit: three rounds and an 8% total concession cap for a public buyer, six rounds and 20% for a known advertiser.

Which rung a live sales agent actually enforces

Schemas describe what a seller may implement. Whether one did is a separate question, and Cora AI, at sales-agent.coraai.org/mcp and whose product catalogue is measured elsewhere, is the one AdCP sales agent that answers anonymously. Of the 24 tools it publishes, one carries a governance surface, and the buying surface is missing three fields this ladder depends on while publishing a required-field list that went from five to zero.

| Field                              | In AdCP 3.1.13                                           | On the live agent |
| ---------------------------------- | -------------------------------------------------------- | ----------------- |
| createmediabuy.paused          | Present                                                  | Absent            |
| createmediabuy.planid         | Present, required when the account has governance agents | Absent            |
| updatemediabuy.revision        | Present, optional, optimistic concurrency                | Absent            |
| createmediabuy required fields | 5                                                        | 0                 |

syncgovernance binds a governance agent to an account, so it is the wire path every control on rungs 3 through 5 arrives by. On this agent it takes accounts as an array of bare untyped objects with no inner structure published at all, and requires only accounts where AdCP 3.1.13 also requires idempotencykey, so the deduplication key that stops one retry firing two approval flows is optional.

This agent publishes populated schemas elsewhere: 20 properties on createmediabuy, 18 on getproducts, mediabuyid marked required on updatemediabuy. docs/protocol/calling-an-agent.mdx warns that some AdCP MCP servers publish no per-tool parameter schemas at all, where "every tool shows {type: 'object', properties: {}}", and this is not one of those. The absences are chosen, and so is the empty required list, which is the worst line in the table. A createmediabuy that requires nothing accepts a call with no budget, no dates and no packages, and whatever happens next is decided somewhere the buyer cannot see.

The missing fields cost specific rungs. Rung 2's book-it-paused move is unavailable. So is binding the buy to a governance plan, which is how reallocationthreshold and humanreviewrequired reach the seller at all. And without revision, two agents, or an agent and a human, can both write to the same buy with no conflict detection: sellers MUST reject on a revision mismatch, but only when the buyer sends one, and this schema has nowhere to put it.

Run the same check against whatever agent you are buying from: send initialize, then notifications/initialized, then tools/list, and read each inputSchema. Those schemas tell you which rung that seller can hold you to.

Why the dial belongs to the counterparty

I trust the practitioners in that r/adops thread over the vendor framing, because agreeing the rules turns out to be the hard part and they are the only people describing it. The TeqBlaze engineer running an AdCP sales agent pilot reported that "the challenge is getting teams to agree on the rules before the system runs. If goals or limits are vague, the agent simply scales that ambiguity faster." A publisher replying to him: "most publisher teams can't even agree on their floor prices lol. we spent 3 weeks just trying to get sales and ops to align on what a 'good deal' looked like."

Every mechanism above fails in the same direction, and what is left when they fail is whatever each counterparty happened to implement.

AdCP's own governance documentation is closer to those practitioners than its vendors are, and it has the same problem. Its central idea, escalate when confidence is insufficient for the risk, has no wire representation, because no field lets a buyer declare a confidence threshold.

So run the ladder against the counterparties you actually trade with, one at a time.

Five questions for the vendor call

1. Which rung does your default configuration sit on, and which field sets it?
2. If the agent proposes a spend-changing write, what exactly do I approve: a sentence, or the payload?
3. Does my approval leave any record the seller can verify, or only a row in your database?
4. For conditionalselfserve actions, what are the tolerances, in numbers, in writing?
5. What is your reallocationthreshold default, what aggregation window is it evaluated over, and does it reset when I change the campaign total?

Question 4 decides which rung you are actually on, and the answer has to come back in numbers and in writing before the buy goes live.

---

# Questions to Ask an Agentic Advertising Vendor, and the Answers That Disqualify

Source: https://agenticadlab.com/guides/questions-to-ask-an-agentic-vendor/

Diligence questions for an agentic advertising vendor work only if the vendor can fail them on the wire. Three AdCP sales agents answered anonymously on 12 August 2026: one honoured a structured channel filter, none honoured a plain-English exclusion.

A diligence question is only worth asking if the vendor can fail it, and almost none of the questions being published this year can be failed. The ones below can, because each resolves to an artifact on the wire rather than to a claim in a deck.

Three sales agents in the AdCP registry answered an anonymous call on 12 August 2026. The public catalogue is 18; the other 15 demanded credentials, exposed no media-buy surface, or never completed a handshake. One of the three emptied its whole catalogue when I sent a structured filters.channels: ["audio"]. None of the three dropped a single product when the brief told it, in plain English, to exclude the inventory it was about to return, and two of them asserted a match against "purple monkey dishwasher quantum bicycle". Three agents is not a rate and nothing below treats it as one. It is a wiring observation, and the wiring is lopsided in a way that three samples are enough to show: the structured half of the request did something on one agent, and the prose half did nothing anywhere.

Compare that with Infillion's 15 Questions to Ask Your DSP for the Agentic Era, the list most buyers are working from. It is gated behind an email form, and two of its questions are visible on the page:

 "Is your platform built for AI-driven buying, or layered onto legacy infrastructure?"

 "Do you own any of your supply, and does your system prioritize it?"

Read the first one as a vendor. You say "built for AI-driven buying", and so does the vendor after you, and so does the one after that, so the question separates nobody. Gartner has a name for what you are actually screening for: agent washing, estimated in June 2025 at roughly 130 real builders among the thousands of vendors claiming agentic AI. That number is Gartner's own and isn't independently audited, but its direction matches what buyers say in public: the highest-scoring reply under an r/programmatic thread on Yahoo's six new agents is that "having an OpenAI API wrapper doesn't make things agentic".

Three checks are worth more than the four that follow them, in this order:

| Check                                                          | What it costs you                                               | What it proves                                                   |
| -------------------------------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------- |
| Send the same product request twice, one constraint changed    | An hour of an engineer's time, or a screen-share in the meeting | Whether a constraint you supply changes what comes back          |
| Ask for the agent's URL and call it                            | An email, then an hour                                          | Whether the agent exists anywhere outside the vendor's own login |
| Open the publisher's /.well-known/adagents.json in a browser | Thirty seconds                                                  | Whether the publisher has authorised this vendor to sell it      |

Seven checks in all, each with an answer that ends the conversation. Three you can run in a browser, three need someone who can call an endpoint — the registry lookup and the A/B belong to both groups — and two are conversations with nothing to run. Both stacks are in scope: AdCP, the Ad Context Protocol, which has a public agent registry and one machine endpoint per agent, and AAMP, IAB Tech Lab's competing stack, which has neither.

Three agents answered an anonymous call. Nine correctly refused.

Ask for the agent's URL and the credentials to call it, before the meeting rather than after: a URL ending in /mcp, the authentication scheme, and either a sandbox tenant or a test key. Vendors who have built the thing send that by email the same day. Any version of "the agent is available inside our platform" ends the conversation, because an agent that only exists behind the vendor's own login is a feature of their UI, and the premise of both stacks is that somebody else's software calls it.

Half of this runs in a browser. Open https://agenticadvertising.org/api/registry/agents and search the page for the vendor's name. That is the AdCP registry, and it returned 23 agents on 12 August 2026: 18 typed sales, 3 signals, 1 creative, 1 buying. Enrolment runs through an AgenticAdvertising.org member profile, there is no self-registration, and the same API reported 68 further agents discovered by crawling adagents.json files, a set the registry does not publish and which may overlap the 23. A vendor who isn't listed goes straight to the URL request above. What the registry gives you is the shortlist you can test today, covered agent by agent in the AdCP registry, measured.

The other half needs an engineer for an hour. Every registry agent speaks MCP, so a call is an HTTP POST and a session header. Here is what an anonymous handshake plus a getproducts call returned across all 18:

| Result                                                   | Count | Agents                                                                         |
| -------------------------------------------------------- | ----- | ------------------------------------------------------------------------------ |
| Returned products to an anonymous caller                 | 3     | Cora AI, Equativ, No Fluff Advisory                                            |
| Handshake succeeded, getproducts requires credentials | 3     | goTom Sandbox, Adzymic (SPH), Adzymic (Mediacorp)                              |
| Credentials required at the handshake                    | 6     | AdCP Test Agent, InMobi (prod and non-prod), LoopMe, Purrsonality Seller, Pubx |
| Typed sales, exposes no getproducts tool            | 3     | Advertible, Dstillery, vastlint                                                |
| Transport failure before any protocol ran                | 3     | BidMachine (503), Content Ignite (500), Rediads (522 from Cloudflare)          |

Rows two and three, the nine agents that demand credentials at one layer or the other, are the healthy ones. An agent that refuses an anonymous stranger is behaving correctly, and the protocol's own public test agent is in that group: it answers 401 Missing bearer token, the HTTP code for absent credentials. The last two rows are the ones worth pausing on. Three agents are registered as sales and expose no media-buy surface at all: Advertible answers unknown tool "getproducts", Dstillery offers getsignals only, and vastlint's 14 tools are VAST validation and content-standards management. Three more never completed a handshake on any attempt. Any of those rows can belong to a vendor worth buying from. Not being able to tell you which row they are in disqualifies them.

One structured filter excluded anything. No English sentence did.

This is the highest-yield check here, and if you only get one thing into the meeting, get this one. Send a product discovery request. Send it again with a constraint that should exclude most of the catalogue. Compare the two sets of products. That is the whole test, and it is the one thing a demo cannot fake, because you supply the second input.

Three agents answered anonymously, so the A/B ran against all three:

| Request                                                                                     | Cora AI                                                                                 | Equativ                                                                             | No Fluff Advisory                                                       |
| ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| US-only CPG brief, CTV and online video                                                     | 4 products, all Korean FAST CTV and Korean news                                         | 1 product, "High CTR APAC Video"                                                    | 5 products: 4 fixed, 1 generated ("US market entry & GTM operators")    |
| Same brief plus "Exclude all non-US inventory. Exclude Korean-language and APAC inventory." | same 4                                                                                  | same 1                                                                              | same 5, generated product on the same topic                             |
| "purple monkey dishwasher quantum bicycle"                                                | same 4                                                                                  | same 1                                                                              | same 5, generated product switches to "Clean room & data collaboration" |
| filters.countries: ["US"]                                                                 | same 4 — but all four declare countries: ["KR","US"], so returning them is defensible | same 1                                                                              | same 5                                                                  |
| filters.channels: ["audio"]                                                               | 0 products                                                                          | same 1 — the product describes itself as "Synthetic data for demo purposes only." | same 5                                                                  |

Two of the three also asserted a match. Cora's response carries filterdiagnostics: {totalcandidates: 4, matchedcandidates: 4, nomatchtargeting: false, semantics: "approximate"} for the nonsense string, and each product's briefrelevance reads "Matched against buyer brief:" followed by the brief echoed back. Equativ returned briefrelevance: "Matches video campaign requirements for APAC market with CTR optimization segment" against a brief that says United States, and again against the nonsense.

Six structured attempts across the three agents produced exactly one exclusion, Cora's filters.channels. No English sentence excluded anything anywhere. Prose was not entirely inert — No Fluff Advisory generates its fifth product per brief from a corpus of essays, and that topic did follow the brief — but it could change what a product slot was about and never take a product away. Cora's catalogue is four products and No Fluff's is five, sizes at which returning everything and matching everything look identical from outside, and Equativ's endpoint is a demo tenant by its own description. What survives those caveats is the shape of the wiring: the structured half of getproducts is where the implementation is, thin as it is, and the natural-language brief that every deck opens with came back on two of three agents as an echo with a match assertion attached.

A real answer runs the A/B live and the sets differ, or names which fields are hard filters and which are hints. "The agent interprets the brief holistically" is the answer that ends it, and the follow-up that exposes it is to ask what changes in the response when you remove a requirement. If nothing changes, the requirement was never applied. When the credentials do not arrive before the second meeting, which is the usual outcome, have them screen-share the two calls and read the product IDs off the screen with you. You still supply the second input, which is the only property that matters here.

Adzymic declares three honoured filter fields out of twenty-eight

AdCP 3.1.13 puts campaign prose in a brief string with no schema and no validation, and puts everything a seller can filter on in a sibling filters object: 30 properties, of which 29 are filters and one is an ext escape hatch, and one of the 29, requiredaxeintegrations, is marked deprecated. Twenty-eight live filters, then: countries, regions, metros, postalareas, geoproximity, channels, formatids, deliverytype, exclusivity, budgetrange, signaltargeting, requiredperformancestandards and the rest. "We support AdCP" says nothing about how many of the 28 do anything.

Adzymic publishes the answer this question is looking for. Its live capabilities response declares exactly three targeting dimensions as true, geocountries, georegions and deviceplatform, alongside contentstandards: false. I would onboard the vendor who published three honoured fields over the one claiming twenty-eight in a deck, because only one of those two numbers can be checked.

A real answer names which fields cause a product to be excluded from the response and which are advisory. The disqualifying answer is "we are fully compliant with the spec". A vendor who can't split the list either hasn't implemented filtering, or has implemented it without knowing which fields went live.

Run it yourself, with an engineer. One call to getadcpcapabilities returns the declaration, and Adzymic's is public.

Idempotency decides whether a retry buys twice

IAB Tech Lab's own reference seller agent shipped two bugs of exactly this class. Issue 44 is duplicate quotes on replay: the same request arrives twice, the agent prices it twice. Issue 51 is worse in kind, because POST /api/v1/negotiations/messages requires an idempotencykey, never honours it, and a retried counter-offer burns a round from a negotiation's maxrounds budget, so "enough retries can push a legitimate negotiation past maxrounds into an unintended REJECT". A required field that the handler never reads is worse than no field, because it buys the caller a guarantee that doesn't exist.

Neither issue documents a duplicated createmediabuy landing against a live insertion order, so size the money exposure as theoretical for now and bounded by your daily cap: a retry doesn't create budget, it creates a second commitment against the same one. That is still a commercial question rather than a technical annex, because the person who eats a double booking is not the person who wrote the retry loop.

In AdCP the declaration lives in getadcpcapabilities, as an idempotency object alongside adcp.supportedversions. The schema's own language is unusually direct: clients MUST NOT assume a default, and a seller without the declaration "is non-compliant and should be treated as unsafe for retry-sensitive operations". Cora declares {supported: true, replayttlseconds: 86400}. goTom declares request signing as supported and required for createmediabuy.

A real answer is the declaration itself, with the replay window in seconds. The disqualifying answer is a description of the retry policy with no idempotency object behind it, or a protocol version quoted from a slide with no supportedversions on the wire.

Run it yourself, with an engineer. Fetching the declaration takes one call, so ask them to make it while you are in the room.

Vox's authorisation file is missing two required fields

If a vendor says your inventory is discoverable by buying agents, or that they are authorised to sell somebody else's, the assertion lives in a file at https://<domain/.well-known/adagents.json. Anyone can open it in a browser. I opened four on the same day: straitstimes.com serves a pointer file naming sales-agent.adzymic.ai as the authoritative location, vox.com serves a full file naming https://salesagent.voxmedia.com as its authorised agent, and cnn.com and theguardian.com return 404.

Look for the vendor's endpoint in authorizedagents[].url, then look at the entry itself, because Vox's has a defect worth knowing about. It carries url, name and properties, and omits authorizationtype and authorizedfor. Both were required on every authorized-agent entry as of AdCP 2.5.3, and all six entry shapes the 3.1.13 schema allows still require authorizationtype. A buyer agent validating that file against the published schema has grounds to reject the authorisation outright. Most clients don't validate today, which is why nobody has caught it, and "most clients don't validate today" is not a sentence you want load-bearing in a contract.

"Discovery is handled through our integration" ends the conversation. Discovery is a file on a domain the publisher controls, and the publisher-side page on agent discovery files covers what belongs in it.

The reference seller agent invents a price when the product doesn't exist

Ask what the agent does when it hits something it can't answer: a product that isn't in the catalogue, or a brief it can't parse. The reference implementations answer that in public, and their answer isn't reassuring. On 11 August 2026 an external contributor filed seller-agent issue 57 against IAB Tech Lab's seller agent: POST /api/v1/deals/curated accepts an arbitrary productid with no existence check, and when the ID matches nothing it falls back to a hardcoded basecpm = 12.0 and mints a persisted, confirmed, bookable deal at that price. The function's own docstring says the opposite: "A known-but-unpriced product (no base/floor CPM) is a 422 — never a fabricated price." The guarantee is implemented for products that exist without pricing and skipped for products that do not exist, which is the failure mode to interrogate in both stacks: a confident, bookable number standing where an error belonged.

A real answer names the error code and shows you the response body. The disqualifying answer is "it falls back to a sensible default".

Nothing to run here. Unless the vendor gives you write access to a sandbox, this one is a conversation, and the two issues above are the vocabulary for having it.

Ask which field records that a human was asked

Amy Porter of RPA told Digiday that agents could obscure critical decision-making if advertisers lean on AI for bidding, optimisation and performance assessment without human oversight. She is right, and the remedy is narrower than the warning suggests. The obscurity nobody can fix sits in the model's reasoning, which nobody was ever going to read. The obscurity you can fix is whether a protocol field records that a human was asked and what they said. AdCP has checkgovernance and the submitted and input-required async states; AAMP's buyer agent has an ApprovalConfig with separate switches for plan review, booking, creative and pacing adjustment. Those are the things that leave a trace.

So ask which specific operations require a second human, and which field enforces that, rather than which ones the vendor's policy says require one. A role in the vendor's UI is a setting their own staff can change on a Friday afternoon; the field is what the log shows on Monday. The autonomy ladder maps each rung to the mechanism that implements it.

A real answer names the field and the state the buy sits in while it waits. Nothing to run here either, until you have a live integration and can read your own logs.

Does an AdCP compliance badge prove the agent honours a brief?

AdCP runs a hosted compliance programme with storyboards, tracks and a badge. It is the most developed conformance apparatus in agentic advertising, and it doesn't test the thing the A/B tests. Two issues, both filed by outside implementers, say so directly.

Issue 2902, open since April:

 "An endpoint can accept startdate/enddate, return a correctly-shaped response, pass all compliance checks — and silently return the same data regardless of what dates were passed. The schema is valid. The contract is broken."

Issue 5495 found the same hole from the runner's side: when a storyboard sends a spec-defined field that the agent's own tool schema does not declare, the runner strips the field, logs a console warning that never reaches the report, and scores the step as a pass. "A conformance tool reporting 'pass' for a capability the agent never exercised is a false positive." And issue 6374 records that the public compliance API exposes verified as a bare boolean, with three unrelated possible causes for a false and no field distinguishing them.

The AAMP side has no badge to weaken. Its conformance kit is a script the vendor runs in their own CI, emitting a gapreport.json, and there is no third-party register of who passed. So on that stack, ask for the gap report. "AAMP-compliant" is, today, entirely self-asserted.

Rank the badge accordingly: it is a tiebreak between two vendors who both passed the A/B, it is evidence of effort and I would weight it above a case study, and it is not a substitute for running the A/B yourself.

Where these checks stop working

They verify mechanism. They say nothing about whether the buy performed better, which is the objection carrying the most weight in both threads I read. On value, from r/programmatic:

 "so far there's not a good value preposition [sic] that can't be addressed by a bulk sheet or API."
 — u/GreenFlyingSauce, r/programmatic

And on proof, from r/adops:

 "I have yet to see any agentic experience that you can actually trust to execute, the ones that work don't save enough time nor have any proof of improved performance because attributed metrics don't mean incremental performance. AI has no absolute accountability either."
 — u/Toast687, r/adops

Both are practitioner sentiment rather than measurement, and nothing on the wire answers either. No field in either protocol carries incrementality, and a vendor who passes all seven checks has demonstrated that the integration works. Whether it buys better is a separate claim, and none of these checks touch it. The named deployments and their reported numbers are tracked separately in who is running agentic buys, and most of those numbers are vendor-stated.

The window is narrow too. Eighteen sales agents is the whole public catalogue and a fraction of the market: the registry lists only agents an AAO member has enrolled at public visibility, and anonymous access shows only what these systems do for a stranger. Which is why the check that generalises is the endpoint call, and why a vendor who says plainly which parts are not built yet can still be the right pilot partner.

When one of them fails the A/B and you want them anyway, put the fix in the pilot contract rather than in the minutes. Name the filter fields that must hard-exclude, the three or four your planning actually depends on out of the twenty-eight, and a date by which getadcpcapabilities declares them true. That declaration is the reporting obligation and the acceptance test at once: it is public, it is machine-readable, and you can rerun the A/B against it on the date without asking anybody's permission.

---

# Who Is Actually Running Agentic Buys: A Sourced Ledger

Source: https://agenticadlab.com/guides/who-is-running-agentic-buys/

The companies who have transacted agentic media buys since December 2025 are Omnicom, NBCUniversal, Butler/Till, Vox Media, Magnite, PubMatic and Yahoo, mostly on AdCP. One advertiser has been named, and every result came from the vendor that sold the campaign.

Agentic buying is real, it is eight months old, and it is smaller than one large publisher's monthly revenue. Eight named deployments have transacted since December 2025. Exactly one advertiser has put its name to any of them. Three produced a number anybody could quote, all three of those numbers came from a company that sells agentic software, and that last fact decides how you read every case study you will be shown this year.

The buys that have actually run

Three names carry the protocol column. AdCP, the Ad Context Protocol, is the buying-and-selling spec most of these deployments run on. AAMP is IAB Tech Lab's competing framework, and the two are compared here. A row marked MCP means the agents had a way to talk to each other and no published buy-side spec governed the commercial content of what they said.

| Who                                                                                                                                                                       | When                                                                   | What ran                                                                                                                                                                                    | Protocol                                                                                                                                                | Reported result                                                                                                                                                                                                                                                                                 | Where the number comes from                                                                                                                                                                                                                                                                         |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Butler/Till + PubMatic, for Geloso Beverage Group                                                                                                                         | Two flights, December 2025 into January 2026                           | CTV campaign for the Clubtails brand across Samsung, Paramount, Vizio and Tubi, planned and executed by agents from a natural-language brief, with agency sign-off on the curated inventory | AdCP, per PubMatic | 5.5x buy-side supply-chain cost efficiency; 40% more impressions than planned; about 30% lower effective CPM; 98% video completion. Quality checked by the verification firm Jounce. Budget not disclosed                                                                                       | Vendor press materials, reported by Marketing Dive and Digiday |
| Magnite + Scope3, MiQ                                                                                                                                                     | December 2025, announced 6 January 2026                                | Seller agent inside SpringServe; first AdCP test buys with LG Ad Solutions, MiQ and Warner Bros. Discovery                                                                                  | AdCP                                                                                                                                                    | None published                                                                                                                                                                                                                                                                                  | Magnite, via ppc.land                                                                                      |
| NBCUniversal + RPA + FreeWheel + Newton Research                                                                                                                          | Announced 6 January 2026, Q1 2026 flight                               | Buy-side and sell-side agents transacting a single premium video investment across linear and streaming, including live NFL playoff inventory                                               | MCP                                                                                                                                                     | None published                                                                                                                                                                                                                                                                                  | Vendor announcement, reported by AdExchanger           |
| Yahoo DSP + Newton, RPA                                                                                                                                                   | 6 January 2026                                                         | External agents connect to Yahoo DSP over MCP; a Newton and RPA trafficking agent has executed programmatic guaranteed buys                                                                 | MCP                                                                                                                                                     | None published                                                                                                                                                                                                                                                                                  | Yahoo                                                                                                                                                                                     |
| PubMatic AgenticOS                                                                                                                                                        | Launched January 2026; 250+ deals by March, 1,000+ by Q1, 4,000+ by Q2 | Agentic deal transaction at platform scale; 80+ fully autonomous end-to-end campaigns by Q2, spanning all five holding companies                                                            | AdCP plus proprietary agents                                                                                                                            | Level Agency, 2x reach per dollar against its incumbent DSP; a Spain CTV campaign 18% below target CPM and 23% over impression goal | PubMatic Q2 2026 results, an unaudited operating metric in an earnings release                                                                                        |
| Omnicom                                                                                                                                                                   | Disclosed on the Q1 2026 earnings call, late April 2026                | Live media buys for selected clients on an agent-to-agent framework, with the stated goal of shrinking the intermediary take                                                                | AdCP                                                                                                                                                    | None published                                                                                                                                                                                                                                                                                  | Company statement, reported by Digiday and AdExchanger                      |
| Boostr + Vox Media                                                                                                                                                        | June 2026, announced 9 June 2026                                       | Seller agent received, negotiated and closed a campaign-level buy covering budget, audience and delivery schedule; Vox staff accepted the buy and verified it in the ad server              | AdCP                                                                                                                                                    | None published; the claim is that hours of manual setup were removed                                                                                                                                                                                                                            | Vendor press release                                                                                                                   |
| Magnite Orchestration, with dentsu and DIRECTV Advertising | 11 June 2026                                                           | A neutral layer connecting third-party buyer agents to Magnite supply                                                                                                                       | AdCP                                                                                                                                                    | "A handful of millions of dollars" transacted agentically to date, against the roughly 9 billion dollars of ad spend Magnite processes                                                                                                                                                          | Q2 2026 earnings call, 5 August 2026                                                                                                                           |

A row qualifies when a named company is on the record, with a date, that something transacted. Current as of 12 August 2026.

Eight rows, three different units. Two are platforms reporting aggregate volume: PubMatic AgenticOS and Magnite Orchestration. One is a seller-agent integration with named test buys behind it, Magnite and Scope3 inside SpringServe. The other five are discrete campaigns or buy programmes, where a brief went in and media came out. Eight is the number a vendor will quote at you. Five is the number that means something ran.

Two threads on r/programmatic have been asking for that list. One put it bluntly: "Literally give me one example of an advertiser actually using either." The other, from January, drew this: "I have no reason to believe that it's anything more than just another buzzword until i see some solid tangible examples. Otherwise, blockchain sandbox NFT IOT flying cars." The closest either thread got to an answer was one publisher saying they had started integrating on the sell side with Magnite.

That standard undercounts, and in one place the size of the undercount is knowable. PubMatic's Harry Tong told Digiday the company is running tests with "upwards of 10" agency partners and declined to name any of them. The public ledger is a floor, not a census.

The ledger also has a hole where the biggest buyers should be. Yahoo's DSP is in it. The Trade Desk is in the second table and goes no further than alpha. Google's DV360, Amazon DSP and Meta appear in neither table, and no public agentic deployment exists from any of the three. The platforms that spend most of the world's programmatic money have published nothing that would fill a row, and on a proof-of-deployment list that absence is worth more than most of the rows.

Shipped the infrastructure, no campaign to point at

Real products. No advertiser has been named on any of them.

| Who                                                                                                                                         | When                  | What shipped                                                                                                                                                      | Protocol      |
| ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| Zefr | 21 April 2026         | Zain, an agentic hub for YouTube, TikTok and Meta that turns a natural-language request into a live campaign inside Google's buying stack                         | AdCP over MCP |
| The Trade Desk                               | 21 April 2026         | Koa Agents in alpha, with Stagwell as the first agency partner building on The Trade Desk's MCP; beta to select clients was expected later in the summer          | MCP           |
| PMG                         | 7 April 2026          | Alli, the agency's operating system, integrated with the AAMP buyer agent architecture and the Agent Registry                                                     | AAMP          |
| CNN                                                                 | Reported 6 April 2026 | In-house agent-to-agent buying and selling for CNN's article and short-form video inventory; testing during 2026, full-scale transactions targeted for early 2027 | Not stated    |

Almost every number above was produced by the company that sold the campaign

PubMatic's AgenticOS ran the Butler/Till buy and PubMatic's supply chain carried it. The 5.5x compares that path against what the two companies call the standard economics of traditional DSPs, and it gets much more useful when you take it apart. PubMatic's own case study puts the same result at about an 80% reduction in buy-side costs. Digiday reports 82%, specifically in DSP tech fees. 5.5x is one divided by 0.18: the identical number restated as a multiple, by the company that removed the fee.

That is the disintermediation thesis, proved and priced, and it settles one half of the argument the trade press has been having with itself. Paul Bannister of Raptive has been the clearest voice for the optimistic case, arguing that agentic trading "puts the buyer directly in touch with the publisher's ad server and removes other middlemen". On fees, the Butler/Till result is his evidence and it is good evidence. Craig Tuck of Ozone says the "biggest risk we see with an innovation like AdCP is decreasing transparency and control", and this ledger is his evidence too. The fee came out of a supply chain only PubMatic can see, the saving was published by the party that charged the fee, and nobody outside PubMatic can reconstruct why those particular impressions were bought. Bannister wins the fee argument. Tuck wins the one that decides whether you can audit next year's spend, and he wins it on Bannister's own case study.

It is also the limit of what the number says. Removing a DSP fee is a supply-chain result, not an agent result, and nobody has isolated the agentic layer inside it. The budget was never disclosed either, so from outside you cannot tell whether 40% more impressions than planned is agent optimisation or simply what a 30% lower effective CPM buys you on the same money. That 30% is in PubMatic's own case study and it travelled the least of any figure in the set, which is odd, because it is the one a planner would care about most.

So the number to carry into a business case is zero. Model your pilot at no media saving at all. If a fee really comes out, it shows up in your own reconciliation and costs you nothing to have not forecast; forecast it from somebody else's press release and you have committed to a saving whose mechanism you cannot inspect.

The quality numbers are the exception in this ledger, and the two outlets that reported them disagree. Marketing Dive, working from press materials, published under 1% DoubleVerify failure and 0% made-for-advertising. Digiday reported that an independent audit by the verification firm Jounce found an MFA rate below 1%, with 80% of the inventory rated higher than DoubleVerify's typical benchmark. Two outlets, two different numbers, one campaign, and no way from outside to tell which figure Jounce actually produced. Digiday's version is the stronger claim precisely because it is the one place in this entire ledger where a third party looked at an agentic campaign and measured something.

The deal counts have the same shape and a weaker defence. 4,000 AI-powered deals transacted to date is a count of deals; the spend behind them has never been published, and the figure is an unaudited operating metric in an earnings release. What is useful in it is the curve, 250 to 1,000 to 4,000 across two quarters, which is real acceleration in something. The absolute number still tells you almost nothing about money.

Five rows in the first table say none published. NBCUniversal, Omnicom, Yahoo and Vox Media have all confirmed live transactions and not one has published a performance delta. The reasons could be commercial as easily as unflattering, since agencies and holding companies almost never publish client-level results for any tactic. But a delta is the thing that would settle the argument, and eight months in, nobody has produced one.

Nothing has gone wrong either, on the public record. No pulled campaign, no rerun, no agent that mispriced a buy, no integration that stalled with a name attached to it. Every row here is a success or a silence, which is exactly what a ledger assembled from press releases would look like whether or not the failures exist.

The one number that came from outside the trade

DataBeat, a programmatic analytics provider working with the revenue-operations firm MediaMint, published its US Programmatic Trends report on 22 June 2026 using May 2026 marketplace data: more than 55 million dollars of monthly revenue, 35 billion monthly impressions, over 200 bidders. It is the only agentic-versus-conventional comparison in circulation that was not written by a party to the campaigns it describes.

Independent of the campaigns is not the same as disinterested. DataBeat had no stake in the buys it measured and it has a direct stake in you reading the report: it sells analytics into this market, the report is monthly marketing, and its own conclusion is that agentic buying has moved past the experimental stage and stands to become a larger contributor to publisher monetisation. The numbers are still worth having, because they are the only ones of their kind.

| Metric                | Conventional demand | Agentic demand     |
| --------------------- | ------------------- | ------------------ |
| Average CPM (USD)     | 6.95                | 6.13               |
| Fill rate             | 0.183%              | 0.204%             |
| Auction participation | Baseline            | 86% fewer auctions |

Conventional buyers paid a 13.4% CPM premium, which reads either as agents avoiding overpayment or as agents winning inventory conventional demand had already declined. The fill rate would settle it if it were sound: an 11.5% relative edge between two fractions of one percent is not load-bearing, DataBeat never defines how either rate was derived, and ppc.land points out that a conventional fill rate measured the usual way runs far above 1%, so whatever these two numbers are, they are not that. Take them at face value anyway, pair them with 86% fewer auctions, and the unflattering reading fits better than the flattering one: curated, pre-negotiated supply does not clear at a fifth of one percent, and bidding rarely into thin competition does. DataBeat itself hedges that it is worth assessing whether the edge comes from inventory quality or from win-rate optimisation. It is one network for one month, and still the only outside look anyone has published.

Where is AAMP in this ledger?

AAMP has one row here and it belongs to an agency, not an advertiser. IAB Tech Lab's Agent Registry opened on 1 March 2026 and reached ten entries by 11 March, every one of them registered as an MCP server and none as A2A, the agent-to-agent transport that competes with MCP. PMG connected Alli to the buyer agent architecture on 7 April. Kochava shipped an open-source workspace on it, Amazon Ads donated a bidstream component, and Google, The Trade Desk, Amazon and Meta are all named as members. No advertiser has spent money through AAMP in public.

So if a vendor is selling you AAMP compliance in 2026, they are selling you a roster. Every buy in the first table above ran on AdCP or on raw MCP.

The entire market is still a rounding error

Michael Barrett, Magnite's chief executive, told an interviewer in July 2026 that the most optimistic forecasts he collected at Cannes put total 2027 agentic ad spend at 600 to 700 million dollars, and on the August earnings call he widened the range of answers he gets from customers to "0 to 1 billion dollars for the whole industry". Magnite alone processes about 9 billion dollars of ad spend a year, which is roughly 170 million dollars a week. The top of Barrett's own industry-wide forecast for 2027 is four weeks of Magnite's pipe.

There is no urgency argument in those numbers, and I would not let a vendor build one for you out of a deal count. The case for running something this year is optionality: you learn what your own supply chain costs when a machine assembles it, at a budget you can afford to lose. What a defensible first pilot looks like is a separate question from whether the market is real yet.

Three questions for the next vendor call

Who is on both sides of the trade? Run that on the next vendor who shows you a number. When one company supplies the buying agent and carries the supply, the saving it reports is the saving from removing a fee it was already positioned to remove, and that can be entirely honest while saying nothing about what the agent is worth to you.

What was the budget, and did anything run against it? Every published figure so far is measured against a counterfactual, never a control. Ask for the control instead: same budget, same weeks, same market, bought the old way. Nobody has published one, so a vendor who offers to run one alongside your pilot is telling you more than the 5.5x does.

Then ask to speak to the advertiser. There is one. Geloso Beverage Group is the only brand that has let its name go on a transacting deployment since December; Level Agency is an agency and Vox Media is a publisher, and all three were put into a press release by the vendor that served them, so a reference call costs that vendor nothing if the campaign happened the way the release says it did.

One thing worth raising on that call, because both campaigns get described as fully agentic: in the Butler/Till buy a person signed off the curated inventory, and at Vox a person accepted the buy in the ad server before it launched.

The mechanism checks underneath all of this, including whether a vendor's agent answers on the same version the spec publishes, which is 3.1.13 in dist/schemas/latest.json, are on questions to ask an agentic advertising vendor.

---

# Will Agents Replace Media Buyers? Role by Role

Source: https://agenticadlab.com/guides/will-agents-replace-media-buyers/

Agents will not replace media buyers. AdCP and AAMP automate the tasks their schemas both carry and decide: creative sync, pacing writes, counter-offers, IO paperwork. Tasks where a person still supplies the number, the floor or the policy stay human.

Agents are not going to replace media buyers, and the useful question is which half of your week they take. An agent will hold a floor. It won't tell you the floor is wrong.

Almost everything you do is already a field in somebody's schema, and only some of those fields have a decision procedure behind them. That is the sort: a task is going when the protocol carries the value and decides it, and it stays yours when the protocol carries the value and a person still has to supply it.

AdCP's core/product.json is where the split first shows. pricingoptions, exclusivity and signaltargetingallowed are properties of a product, all read by getproducts, and signaltargetingallowed defaults to false, so signals stay bundled into product terms unless a publisher deliberately opens them. Nothing in 3.1.13 is a buyer-facing write against a product.

With one exception anyone in a pricing role should know about, because it is the closest thing in either corpus to automating a task that looks like it stays yours. iscustom is a product field, documented as true if the product was generated for a specific brief and paired with an expiresat; AdCP's product documentation calls these "dynamically generated products," and the worked example there carries iscustom: true on the same object as a floorprice of $5.00 and a priceguidance of p50 $8.00, p75 $12.00. Machines do author priced products, on demand, today. What they do not do is decide the yield policy they price against. Custom products move product authoring from per-deal to per-policy, and the per-policy version is the better-paid one.

A publisher-side operator on r/adops, reacting to news that Vox Media had run a sell-side deal negotiated agent to agent:

 "The 2-minute deal automated trafficking and IO paperwork. That was never the job with a lot of value. Someone still needs to decide what packages exist, what the exclusivity is worth, and which first-party data is exposed to agents. Agents execute deals. They don't decide which deals deserve to exist."

Which of your own tasks is on the path?

Take your week and sort it: does a protocol carry the value and decide it, or carry the value and wait for you?

| Your task                                                           | Operation pointed at it                             | Verdict |
| ------------------------------------------------------------------- | --------------------------------------------------- | ------- |
| Uploading and assigning creatives                                   | synccreatives (AdCP only)                        | Going   |
| Budget, pacing and bid changes                                      | updatemediabuy / package-update               | Going   |
| Building the IO and the deal record                                 | POST /api/v1/quotes, /deals, /orders          | Going   |
| Sending a counter-offer                                             | POST /proposals/{id}/counter                      | Going   |
| Pulling delivery and pacing reports                                 | getmediabuydelivery, getmediabuys          | Going   |
| Assembling a product against a specific brief                       | iscustom products, priced by the seller          | Going   |
| Applying tier discounts and volume adjustments                      | the AAMP pricing engine                             | Going   |
| Setting the base rate card and the floors                           | PUT /api/v1/rate-card, values supplied by you     | Yours   |
| Deciding what a package contains and what exclusivity is worth      | none                                                | Yours   |
| Deciding which first-party signals agents may target                | signaltargetingallowed, default false         | Yours   |
| Approving a creative, and holding the queue when one is pulled back | stops at pendingreview; impairment on reversal | Yours   |
| Judging whether a returned product actually matches the brief       | briefrelevance, which nothing verifies           | Yours   |
| Handover, ownership, escalation, makegoods                          | none                                                | Yours   |
| Deciding whether the campaign was worth running                     | performanceindex, which nothing computes         | Yours   |

Six roles carry those rows: trafficker, trader, planner, ad ops manager, account executive, yield analyst.

If your week is search and paid social

The question that brings a lot of people here came from r/adops: will Claude Code and similar tools "eventually replace performance marketers, or will they just make great performance marketers even more powerful?" Neither protocol answers it. AdCP's channels enum does contain search and social, there is a sales-social specialism defined as a "social media advertising platform with self-service flows," and package-update even carries keywordtargetsadd and negativekeywordsadd — all of it addressed to a publisher's sales agent. The self-service auction accounts where a performance marketer's day happens are not sales agents, do not speak MCP, and are not party to either specification: the AdCP registry's sales side is publishers, SSPs and ad networks, and nothing named Google, Meta, Amazon or TikTok is in it. Whatever automates that job ships from inside those platforms, on their schedule, with no schema you get to read first.

The test still transfers. Inside Performance Max or Advantage+, the tasks with a decision procedure behind them went years ago. What is left is the brief, the budget split, the creative call and the judgement about whether the reported number means anything, which is the same list as everyone else's.

Trafficking is the strongest case, and it stops at pendingreview

The trafficker is the most exposed role here and I'd say so to anyone hiring into one, though not on AAMP's account. AAMP models creatives and gives you no way to move them. The seller agent's core models define Creative, CreativeManifest, CreativeAsset, a ReviewStatus of pending, approved and rejected, a RotationMode, and an Assignment that "links creative to placement with rotation rules." None of the 74 paths in the seller agent's OpenAPI document mentions a creative, so a buyer's agent cannot hand a creative to an AAMP seller at all. That part stays in email.

AdCP is where the job goes. synccreatives takes an array of creative assets plus assignments, an idempotencykey, deletemissing, dryrun and validationmode: bulk upload, package assignment, and reconciliation of a library against a source of truth, in one call, safely retryable. The tag-sheet reformatting an r/adops poster built a GPT for, because doing it in Excel "would also introduce the risk of manual errors", is the task it was designed to delete.

Where the two stacks disagree is on whether creative approval is human work at all. AdCP's creative-status enum has six values, and the interesting ones are the reverse transitions: an approved creative can be sent back to pendingreview, to suspended on a recoverable authorization loss, or to rejected on post-approval revocation, and in the last two cases sellers MUST surface an impairment against any active media buy referencing it. A creative can be pulled back into the queue mid-flight, on somebody else's policy call, while money is running.

AAMP's answer to the same question is its change-request model, which maps ChangeType.CREATIVE to ChangeSeverity.MINOR, and docs/api/change-requests.md, which marks minor changes auto-approved with "creative swap" as its example. One protocol treats a creative change as a live risk to an in-flight buy; the other waves it through as low impact. Which one your counterparty implemented decides whether you staff a review queue at all.

Boostr's announcement of the Vox deal has Lauren Winter, Vox Media's head of advertising operations, saying her team "simply accepted the buy and verified it in their ad server to launch the campaign." That is a vendor press release about the vendor's own launch deal: evidence the deal happened, and a record of what the parties chose to claim.

The trader's daily loop

updatemediabuy carries a packages array of package-update objects, and a package-update has budget, pacing, bidprice, impressions, starttime, endtime, paused, optimizationgoals, targetingoverlay, keywordtargetsadd and negativekeywordsadd. Read that list next to what a trader does between nine and six. It's a complete description of daily optimisation, it fits in one payload, and the request carries an optimistic-concurrency revision that sellers must reject on mismatch, so two agents can't clobber each other.

The r/adops poster who said they used to spend two hours a day "manually tweaking CPMs and budgets across 40+ line items to hit delivery targets" was describing budget and bidprice on a loop. I don't think that survives, and I wouldn't spend career capital defending it.

provideperformancefeedback is the counterexample in the same protocol. It carries a performanceindex from buyer back to seller, and nothing in AdCP computes that index or decides whether the campaign it summarises was worth running. Carried, not decided. Emily Proctor of OMD, at Digiday's Programmatic Marketing Summit, said the quiet part for anyone two years into this job: the skill being automated is the same skill that qualifies you to supervise the automation, so having "those manual skills, or at minimum understanding what it takes to get it done manually" stays essential.

What a planner still owes the response

Amy Porter of RPA, an agency that has actually run an agentic buy, told Digiday there is a "real risk they could also obscure critical decision-making if advertisers rely too much on AI." She is describing a governance problem and I'd call it a QA problem, which is a demotion and also a promotion: nobody writes a policy that catches this, and one person running one check does.

Three of the 23 agents in the public AdCP registry answer an anonymous getproducts with a product array: Cora AI, Equativ and No Fluff Advisory. Cora AI returns the same four products to a US CPG connected-TV brief, to a German-language B2B podcast brief specifying audio only, and to a brief one character long. Those four are Korean FAST CTV and Korean display, carrying countries: ["KR","US"]. Each product's briefrelevance, which core/product.json defines as "Explanation of why this product matches the brief," reads "Matched against buyer brief:" followed by the brief echoed back. These are small catalogues, one to five products, two of them self-labelled demo or interop, and on a catalogue of four, returning everything and matching everything are indistinguishable until the brief is meaningless. The full sweep is here.

So make the check standing rather than occasional. Send every agent you are asked to trust a brief its inventory cannot possibly match, then read countries, publisherproperties and deliverytype on what comes back; an agent that returns its whole catalogue to a one-character brief is one you gate or drop, not one you put in front of a planner. Opacity is what happens when nobody runs that check before a response becomes a plan.

The operation underneath is real capability. getproducts accepts a natural-language brief and a structured filters object and returns products with briefrelevance, forecast and pricingoptions, so a planner can put a campaign in prose to a dozen sellers and get structured availability back, in fields, on the same call. What comes back is a claim. A planner who reads it as a shortlist has been handed someone else's inventory.

Ad ops management is the role with no operations at all

Take the workflow an ad ops lead at a mid-sized publisher posted to r/adops while mapping their team's process: pre-sale feasibility and packaging, campaign handover, chasing missing assets and approvals, QA across sites and devices, delivery troubleshooting, post-campaign wrap and makegoods. Their stated pain was "a lot of time lost to 'who owns this bit' and 'where do I find the source of truth'."

Neither protocol has anything for that. I'd put this role at the bottom of the exposure list, because the coordination an ad ops manager does all day is what both stacks assume has already happened by the time a request goes out. AdCP's governance layer has checkgovernance, syncplans, getplanauditlogs and reportplanoutcome, which record whether a spend was authorised against a declared plan. Ownership, escalation, handover and makegood policy are modelled nowhere. The one open RFC in the area, adcp#6381, asks that buyer-side human approval at least travel as a claim in the governance token. It has not shipped.

The headcount question is not settled here either, and it will not be settled by a schema. If the agents remove the hours and your scope of work is priced in hours, the answer gets written into a remuneration negotiation between a client and a holding company, which is why the holding companies have the strongest incentive of anyone to make this work and the least incentive to publish what it did to their staffing.

The AE's negotiation is a state machine, and a retry can spend your rounds

AAMP's seller agent is where negotiation actually lives. POST /proposals/{id}/counter evaluates a buyer's offer, appends a round to a persisted NegotiationHistory and emits a NEGOTIATIONROUND event, bounded by a maxrounds budget of three to six depending on the buyer's tier. POST /api/v1/quotes, /deals, /orders and /api/v1/change-requests cover the rest of the paper trail. The IO is an API call now, and if your week is IO throughput, that week is going.

The machinery is young in a way that matters commercially. The newer entry point, POST /api/v1/negotiations/messages, takes a shared NegotiationMessage that inherits a required idempotencykey and returns a 422 without it. seller-agent#51 showed that nothing reads it: two identical posts, same key, same body, minted two rounds and spent two units of a budget that starts at three. That issue is closed. On v2.4.1 the negotiation service that mints those rounds contains no reference to idempotencykey at all. A closed issue and an unread field live in the same repository, so the way anyone finds out is a client retrying a timed-out counter and walking a real deal into a rejection it never intended.

Greg Langer of Havas Media Network, at the same Digiday summit, on what agents bring to a negotiation: "There's no human emotion in it. They don't know the relationship." What that leaves an AE is the half of the week that was never in the paperwork, plus an obligation nobody has staffed: watching a state machine spend rounds on your behalf.

Yield analysis: the rate card is a PUT nobody prices from

The yield analyst's split is the cleanest of the six. The tiering and the discount ladder are code. The base card and the floors are a human PUT.

AAMP's seller agent exposes GET and PUT /api/v1/rate-card. The PUT's description: "Publishers should update this when their ad server rate cards change. The pricing engine uses these values as base prices before applying tier discounts and volume adjustments."

In the reference implementation nobody has supplied a rate card, and nothing would read one if they had. The PUT writes a storage key ratecard:current, and src/adseller/flows/dealrequestflow.py, which actually prices a deal, never reads that key. Its applytieredpricing step holds two literals instead: a five-entry price table (display 12.0, video 25.0, ctv 35.0, mobileapp 18.0, native 10.0) and a tier discount table topping out at fifteen per cent for an advertiser-tier buyer. The endpoint that writes the rate card and the code that prices a deal do not share a variable.

The consequence has already been reported. In seller-agent#57, a contributor showed that POST /api/v1/deals/curated accepts an arbitrary productid with no existence check and no auth dependency, falls back to the hardcoded twelve-dollar default, and mints a persisted deal with status: "confirmed". His reproduction typos one letter of a real product priced at $45 base and $35 floor, and gets a live deal at $13.20 total CPM. The function's own docstring promises "never a fabricated price." The yield analyst's failure mode is not a floor that gets missed. It is a floor that is confidently wrong and enforced at machine speed, on every deal, until somebody reads the number.

What is shipped, what is registered, what is running

A schema is not a deployment, and the distance between the two is most of your risk calculation. AdCP 3.1.13 is the current stable release with every operation named here in the box and the AAMP seller agent is on v2.4.1; the public AdCP registry listed 23 agents on 12 August 2026, of which thirteen completed an anonymous MCP handshake, six exposed getproducts to an unauthenticated caller, three returned a product array and two of those three catalogues are self-labelled demo or interop by their operators; and eight named deployments have actually transacted since December 2025, with nearly every number attached to them published by a company that sells agentic software. That ledger is its own page.

Read the middle number carefully, because it is easy to over-read. Gating discovery behind authentication is a defensible choice and plenty of sellers will make it deliberately, so the funnel measures how open the registry is rather than how real it is. A catalogue its own operator labels a demo is a different matter.

The most optimistic 2027 forecast anyone has collected, from Magnite's chief executive Michael Barrett in July 2026, is a rounding error against a single SSP's annual volume; the ledger page runs that arithmetic. The direction is settled and the timing is not, and anyone quoting you a number of months is guessing.

The agents added a shift

Sorting tasks into going and staying assumes the agents are net subtractive from a workload. For the people posting about them, they aren't. The r/programmatic thread that asked "Are we all burnt out from AI yet or is it actually helping anyone or anything?" opens with a complaint that internal rollouts are "actually exhausting and time consuming and feels like a second job," and the poster asks the career question directly: "Will my new job be creating/maintaining/managing AI agents instead of completing the work to service clients myself?"

The most-upvoted reply is not about the tools at all:

 "AI has enabled me to do a LOT more than I was doing a few years ago, which lead to massive increases in my salary... But it doesn't help me at all with the stress of being responsible for more, if that makes sense. Lately my best days at work are the ones where I've stopped caring."

That is the failure mode the protocols make more likely. Watching a round budget spend itself is new work. So is holding a creative queue that can reopen while money is running, and both land on the same people whose manual work was removed, with no published headcount model in which the two cancel.

One commenter in that thread puts programmatic roles that paid $160,000 to $190,000 two years ago at $110,000 to $140,000 now. It is a single anonymous data point and the only salary figure anywhere in these threads. The same commenter, further down the Vox thread: "We saw this movie with RTB. Everyone said programmatic would kill sales teams. It killed fax machines. The sellers who moved up the stack did OK."

So if most of your week sits in the Going block of that table, spend this quarter buying yourself one task from the Yours block: take the floor-setting off your yield lead, or own the QA pass on what a sales agent returns. Getting faster at the Going block is worth very little, because the thing getting faster is the thing being automated.

---

# Agentic Ad Lab: independent analysis of AdCP and AAMP

Source: https://agenticadlab.com/about/

Agentic Ad Lab is an independent analysis site covering the two agentic advertising protocol stacks, AdCP and IAB Tech Lab AAMP, for buyers and publishers deciding which one to fund. It is published by Postindustria and affiliated with neither body.

Two organisations are writing the rules for how software buys advertising, and neither one
acknowledges the other. If you hold a budget, that is a procurement question rather than a standards
question, and it has an answer this quarter: AdCP is the only one of the two publishing a released
contract you can write code against, so a pilot there is fundable now. AAMP's one finished
specification, ARTF, governs bid mutation inside a live auction. Everything else under the label is
code without a contract, and I would keep it on a watch list instead of a roadmap.

If you are scoping Q1, that is one integration to fund and one to leave off the roadmap, and
the side-by-side prices both. What moves AAMP off the watch list is a
versioned AAMP release with a schema behind it. Until a tag exists at the AAMP level, there is
nothing to conform to.

Calling the two equally documented would be a lie. IAB Tech Lab announced AAMP 2.3 on 30 July 2026
and the string appears in no file in any of the eight AAMP repositories, which makes 2.3 a programme
milestone, not an artefact you can pin; the version matrix
shows what does exist instead. agentic-audiences ships
specs/v1.0/schema/agentinterface.schema.json at zero bytes, the file whose name promises to define
the interface between buyer and seller agents. It defines nothing.

Who writes Agentic Ad Lab

Constantine Mirin. I am CEO of Postindustria and I build agentic systems
that run in production. That is the qualification and the conflict, both. Public trail:
LinkedIn,
GitHub,
Crunchbase. The name appears as both
Constantine and Konstantin depending on which profile you land on. Same person, and the
transliterated spelling is what the LinkedIn and Crunchbase slugs use.

Staff of one. When a page here says "I", it means me, and it names the thing that would prove the
judgement wrong.

Postindustria pays for this

Postindustria does protocol integration and agent-readiness work, and this site is the showroom for
it. The site sells nothing and takes no money from anyone it writes about, including for a place in a
comparison. The paid work is described at /services/.

The comparison is where a commercial interest could most plausibly bend the writing, so it is the
page that carries the file paths and the linked sources. Adgentek, which publishes its own
AdCP-versus-AAMP piece, opens by disclosing that it is a founding member of the Ad Context Protocol,
which is the right way round to do it.

The comparison is the page to read first

I run six sites on this subject, and this is the one that takes a side.

Fund one integration and watch the other, and AdCP vs AAMP is where that
call gets made, with the licence and governance risk priced in. If you want the evidence that anyone
has done this for money before you sign off on it, who is running agentic
buys is the dated ledger of named deployments.

A publisher needs to know what to put on their own origin before a buying agent arrives. That turns
out to be one static file, and agent discovery files is the whole
of it, including the part of the schema that survives an agent domain being compromised. An
implementer needs field names instead: every registered AdCP operation has a page at
AdCP Explorer, AAMP Explorer
does the same across the eight AAMP repositories, holes included,
the ad tech glossary takes one term per page, and
Brief Gateway turns a campaign brief into a validated
getproducts request. What Is Agentic Buying answers
that one question without assuming you care how it is specified.

The builders already exist, so this documents their output

Both sides already run a standards body, a registry and a certification programme, and nobody needs a
third of each. AgenticAdvertising.org publishes a brand.json builder and an adagents.json builder,
both linked from AdCP's own intro page, and they are good. Documenting the fields they emit is more
useful than rebuilding them.

The subject is those two advertising stacks and the transports underneath them.
MCP and A2A are in scope, because AdCP
defines its planning-time operations over both and AAMP's agentic-direct puts OpenDirect 2.1 over
MCP. The commerce protocols are not. ACP and UCP standardise checkout, payments and fulfilment inside
an assistant, and AdCP's own glossary files them as the layer next to advertising rather than inside
it. Nothing here covers them.

AdCP is maintained by AgenticAdvertising.org, which its FAQ describes as "an independent specification
body — not a subsidiary or working group of IAB Tech Lab", and AAMP is published by IAB Tech Lab.

This site is affiliated with neither and endorsed by neither. "AdCP" belongs to
AgenticAdvertising.org, "AAMP" and "IAB" to IAB Tech Lab.

Both corpora move; every claim here is pinned to a commit. If something is wrong, point at the file
that contradicts it and mail hello@agenticadlab.com. The page gets edited.

---

# Agent Discovery Files: Publish adagents.json and Pin the Signing Keys

Source: https://agenticadlab.com/guides/agent-discovery-files/

A publisher makes inventory discoverable to a buying agent by serving /.well-known/adagents.json on its own domain: a released JSON Schema listing which sales agents may sell which properties, and pinning the signing keys those agents must use.

If you own inventory and anyone has asked you for a file, publish adagents.json on your own origin
this week and populate its signingkeys. If neither is true, read the schema and wait. One static
file at https://{yourdomain}/.well-known/adagents.json, a released JSON Schema, a free public
validator, no account to open, and the answer to "who is allowed to sell my inventory" stays on your
domain instead of in somebody else's database. It is the cheapest useful thing a publisher can do in
this whole category and the thing most often wrong on the first attempt.

Publish the file, then pin the keys

The keys are the part publishers skip, including the largest publisher currently doing this at all.
Skipping them is the mistake. The pin is the only mechanism in either stack that still holds when an
agent's own domain is compromised, AdCP already makes it a MUST for the four mutating operations, and
the rotation rules cost you one coordination step.

On the buy side, publish brand.json for the same reason. Then read every registry listing in either
stack as a catalog entry, because neither registry has a field that means "a publisher agreed to
this". If you are building against AAMP, do not hard-code a registry hostname: one of the three named
across its own repositories has no DNS record at all. Configure it, cache the verdicts, decide your
own access tiers and treat the registry's answer as one input to them, and build nothing that depends
on authorized-agents.txt until that file has a schema.

There is one production adagents.json of any size, the same path 404s on adcontextprotocol.org,
agenticadvertising.org and sovrn.com, and no buying agent has been observed fetching any of them
at decision time. What publishing buys you today is a record the registry will validate on request,
plus the option on the day a buyer starts reading them. That is a model worth being ready for, not a
deadline.

Both stacks copied ads.txt. One of them shipped the file.

A buying agent arrives at a publisher's domain with one question: who is allowed to sell this
inventory? Both protocol stacks landed on the same two-layer answer. A file the publisher hosts on
its own origin, then a registry that fetches that file, validates it, and keeps the agents' own
identity records. Both descend from ads.txt and both say so: AdCP specifies an ads.txt
managerdomain fallback for when the well-known file returns 404, and IAB Tech Lab's registry
announcement lists "Creating the ability to verify that seller agent actually represents a property
(like ads.txt for agents)" as a roadmap item. They shipped opposite halves of it.

| Layer                               | AdCP                                                                                                          | AAMP                                                                                               |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Publisher-hosted authorization file | /.well-known/adagents.json, released JSON Schema in 3.1.13, in production                                   | /.well-known/authorized-agents.txt, named three times in eight repositories, all three in Python |
| Registry over the top               | agenticadvertising.org, 105 API paths, reads unauthenticated (security: [] on the whole OpenAPI document) | registry.iabtechlab.ai, 40 agents listed, reads gated by an HS256 JWT with issuer IAB          |

Files versus registry is the wrong axis to argue about. AdCP's registry has something authoritative
to index and AAMP's does not, which is why the instruction above comes out the same whichever stack
your counterparty is on.

Neither stack has read the other. Zero files across the eight IAB agentic repositories mention
adagents, zero lines mention AdCP, and nothing maps an AAMP registered status onto an AdCP
authorizedagents entry; the same silence runs across the whole of both corpora, priced in
AdCP vs AAMP. Both stacks do serve an A2A card at
.well-known/agent.json, and that one shared artifact is a format coincidence. The one detailed
comparison anybody has published, adgentek.ai/blog/adcp-vs-aamp/, describes a hybrid flow in which
a buyer resolves brand.json and adagents.json and then cross-checks the IAB
agent registry, and no file in either
corpus implements it.

What goes in adagents.json

One file at one path. Its schema ships in the released registry as dist/schemas/3.1.13/adagents.json,
generated 2026-08-04, a oneOf over two variants.

The pointer variant has three properties and requires one, authoritativelocation, an HTTPS URL
where the real file lives. Three rules in docs/governance/property/adagents.mdx stop that redirect
turning into a maze: "Same Schema", "No Nested References", and "Single Hop", which reads "Only one
level of URL indirection is allowed."

The inline variant carries sixteen top-level fields and requires exactly one of them,
authorizedagents. A complete one from docs/brand-protocol/seller-setup.mdx, with the contact
block dropped for length:

That is the whole thing. Everything else is scope: authorizationtype discriminates six ways, an
entry narrows by collection, placement, placement tag, country or an effectivefrom /
effectiveuntil window, and delegationtype is one of direct, delegated, adnetwork. An
empty array is legal, and the schema spends four negative clauses telling validators not to read it
as deny-all, authorize-all, a revocation, or an error. Nobody writes that for a hypothetical;
somebody hit all four readings in the wild and the schema carries the scar.

Field-by-field reference lives on AdCP Explorer. On the
buy side, brand.json sits at
/.well-known/brand.json: five variants in 3.1.13, split the way adagents.json splits, two
redirects and three actual documents.

The signing key pin inverts key discovery

Every authorized agent inherits core/authorized-agent-base.json, whose key objects require a kid
and a kty, and the governance documentation makes the pin normative:

 if the publisher's adagents.json entry for an agent contains signingkeys, the verifier MUST reject any signature whose keyid is not in that pinned set, regardless of jwksuri contents. The pin is authoritative; the agent-hosted JWKS is advisory and MUST NOT override it.

Normally the agent tells you its keys and you believe it. Here the publisher pins them and the
agent's own JWKS loses the argument. Publishers MUST populate the pins for the four mutating scopes:
createmediabuy, updatemediabuy, synccreatives, updateperformanceindex.

Rotation is the obvious operational objection, and the same document answers it. The agent mints
its own keypair and publishes it under its own jwksuri; the publisher pins the public half, so a
rotation needs both parties to move. It does not turn into a lockout, though. Verifiers SHOULD cache
the pinned set no longer than the Cache-Control max-age on adagents.json, one hour by default.
On an unknown keyid a verifier MUST force-refresh before rejecting for good. And publishers MAY
carry both keys through the window, since the pinned set is unordered and presence in it is
sufficient. Keys also take an optional revokedat that verifiers MUST honour.

Two things are left loose. adagents.mdx defaults the pin cache to an hour while
core/agent-signing-key.json reasons about revocation on a "recommended: 5 minutes" TTL for the same
document; use the shorter one. And the pin says nothing about publisher-domain compromise. Rewrite
adagents.json and you rewrite the pin, so the first retrieval is trusted on TLS alone.

The largest adagents.json in production carries no signing keys

https://mediavine.com/.well-known/adagents.json is a 301 to www.mediavine.com, where the same
path answers 200 to an unauthenticated GET. A resolver that refuses redirects — which is what the
authoritativelocation rules tell validators to do one layer up — sees the 301 and nothing else.
Follow it and you get 3,272,011 bytes, last updated 2026-07-06, covering 8,865 properties under 24
tags. One publisher can carry that much in this format without the model falling over.

Now the uncomfortable half. It has two authorizedagents entries, both pointing at
https://interchange.io/, both authorizationtype: propertytags with
propertytags: ["scope3aee"], both delegationtype: adnetwork. They differ only in the
free-text authorizedfor string: display inventory on one, video on the other. Machine-readably
they are identical, and the distinction the publisher meant sits in prose no resolver can act on.

And there are no signingkeys in it. Zero, in the largest live file in production, the one the
spec's MUST is aimed at. One file of that size against 404s everywhere else says the model ships.

The agenticadvertising.org registry reads it, demonstrably. POST /api/adagents/validate checks
any domain's file on request, and its revalidate endpoint will "synchronously fetch a publisher's
live /.well-known/adagents.json, run the registry validator, persist the refreshed verdict".
Validation needs no account, because security: [] sits at the top of that 105-path OpenAPI
document, while writes still need a bearer token. What is missing is a buying agent fetching the file
at decision time. On the write side there is a released schema with a validator in front of it; on
the read side, the validator is the whole of the evidence. That registry lists 23 public agents, and
three sales agents will answer an anonymous product call.

If you are a publisher, you are done. What follows is for anyone being asked to integrate against
AAMP.

Registry membership is worth money

seller-agent/docs/api/agent-discovery.md publishes a five-value
trust status and maps each value to a
maximum access tier.

| Trust status | How it is reached                                      | Maximum access tier | Pricing visibility                |
| ------------ | ------------------------------------------------------ | ------------------- | --------------------------------- |
| unknown    | default on first contact                               | public            | published rate card only          |
| registered | found in the IAB AAMP registry, verified automatically | seat              | seat-level pricing                |
| approved   | seller operator action                                 | advertiser        | full advertiser pricing           |
| preferred  | seller operator action                                 | advertiser        | full pricing plus priority access |
| blocked    | seller operator action                                 | none                | no access                         |

The five values are ordered, and the effective tier is the minimum of the trust ceiling and the tier
the buyer claims. Claim advertiser on registered trust and you get seat.

Read the second row commercially. registered is granted by registry membership alone, and it moves
a buyer from published rate card to seat-level pricing. Being in the registry is worth money, and
that is the best argument for the registry-first direction in either corpus.

Then the wire contract contradicts itself. AgentTrustVerification.json hard-codes the five values
and states that trust "is verified against the AAMP registry (the IAB Tech Lab agent discovery and
trust registry), never self-asserted". SANDBOXREGISTRY.md, in the same repository, says the real
registry "has no self-asserted access-tier / trust-tier enum — trust is the verificationstatus +
domainverified + iabmember triplet", and files the whole trust-tier surface under "Legacy AAMP
trust-tier surface", "a compatibility layer". That ordering is the seller agent's local policy. The
registry does not issue it.

AAMP discovery is three calls, and the default points at localhost

Nobody has run this against a production registry. The buyer agent's default registry URL is
http://localhost:8080/agent-registry, so an unconfigured deployment discovers nobody, and the
production hostname the same repository documents was never created.

The flow is three calls, per buyer-agent/docs/api/seller-discovery.md. GET
/agents?agenttype=seller&capabilities=ctv against the registry, then GET /.well-known/agent.json
against whichever seller came back, then GET /verify?agenturl=... back to the registry for a trust
verdict. The client caches verdicts for 300 seconds by default.

The agent card it fetches is a real document:
authentication.schemes (apikey, bearer), skills[] (discovery, pricing, proposals,
negotiation, deals), inventorytypes, supporteddealtypes (pg, pmp, preferreddeal,
privateauction), and capabilities.protocols, which is ["opendirect21"]. That is OpenDirect
2.1, the pre-agentic direct-buy API. The doc notes that "a2a will be listed once an inbound A2A
server ships". That path, .well-known/agent.json, is the Agent2Agent card convention: the address
itself advertises that an agent speaks A2A, and the card parked there lists one protocol, the legacy
one.

Which registry it calls is unsettled. Three files name three different production bases.

| Named in                                        | Base URL                                       | What it does today                       |
| ----------------------------------------------- | ---------------------------------------------- | ---------------------------------------- |
| buyer-agent/docs/api/seller-discovery.md      | https://registry.aamp.iab.com/agent-registry | no DNS record at all                     |
| seller-agent/src/adseller/config/settings.py | https://tools.iabtechlab.com/agent-registry  | 200                                      |
| iab-agentic-primitives/SANDBOXREGISTRY.md    | https://registry.iabtechlab.com              | 302 to https://registry.iabtechlab.ai/ |

The first row is the one to stop on. registry.aamp.iab.com is the production registry hostname in
the buyer agent's own documentation, and it was never created. iab.com resolves fine. The subdomain
does not exist. The third row is the base the primitives library pins as IABPROD, and it now
redirects to a top-level domain no file in the corpus mentions.

The live service is real. GET https://registry.iabtechlab.ai/api/agents returns a 401 with
"error":"Authentication required", and that enveloped shape matches what SANDBOXREGISTRY.md
documents. The public UI lists 40 agents with Domain, GPP and Endpoint verification indicators. GPP
is IAB Tech Lab's own Global Privacy Platform consent framework, so a third of the trust signal is
"carries an ID from another IAB standard". Whether the reference client's iabmember field exists
on the live service is unconfirmed.

The repository the AAMP hub README names as its registry component, registry-agent-example, is a
22-line agent.ts with one commit that wraps an external MCP server and defines no contract. The
Node.js service that does run the registry, IABTechLab/agent-registry, is not in that README at
all. The AAMP maturity verdict has the rest of that split.

Then the file the whole model would rest on. AAMP's answer to adagents.json has a name and nothing
else. iabagenticprimitives/registryclient.py defines a class called AgentAuthorization with
this docstring: "Result of POST /api/agents/validate/agent (public endpoint). Whether a publisher
domain authorizes a given agent URL, per the publisher's /.well-known/authorized-agents.txt file."

That filename occurs three times across eight repositories, and the other two occurrences are an
admission and a test. IAB's own sandbox test double does not fetch the publisher's
authorized-agents.txt, and IAB's own reference client ships a test asserting that a publisher
authorization check returns false, because there is no file to check. No schema for the file exists
in the repository, and nothing anywhere in the corpus describes its syntax, so two implementations
would have nothing to agree on.

The corroboration comes from IAB Tech Lab's own wire contract. STANDARDSGAPREPORT.md is
machine-generated and guarded by a drift test, so it is not an offhand remark in a README. It lists
"IAB Tech Lab AAMP agent discovery and trust registry" as UNVERIFIED and gives the action to close
it: "Obtain the IAB Tech Lab AAMP (agent discovery and trust registry) specification". That is IAB
Tech Lab's own reference implementation recording that it could not obtain IAB Tech Lab's discovery
specification, and two-thirds of the standards that report tracks are blocked the same way, on a
specification IAB has not published.

Discovery has a request shape and no answer shape: AgentDiscoveryRequest.json exists with a single
required field, agenturl, and there is no AgentDiscoveryResponse.json anywhere in the
repository.

The AAMP registry is real, live, and better engineered than the documentation around it suggests. It
has nothing authoritative to index. It can tell you an agent exists and that someone DNS-verified its
domain; it cannot tell you a publisher authorized it, and there is no cryptographic fallback either,
because no file across the eight repositories mentions signing keys. That missing file is the largest
single item in what these protocols don't standardize.

A registry listing is a catalog entry, not a grant of authority

Both stacks take self-registration: POST /api/me/agents in AdCP, bearer-authenticated, and POST
/api/agents in AAMP, where the JWT's company domain must match the submitted primarydomain. What
the listing buys you is the difference. An AdCP entry is a catalog record and the publisher's file
still decides; an AAMP entry is the trust record the table above already priced.

The failure modes are not the same size either. Get an adagents.json wrong and one publisher's
inventory stops being sellable by one agent until somebody edits one static file, and nobody else
notices, because there is no shared object to corrupt. Break the registry and the blast radius is
every participant at once: a seller agent that cannot reach it has no path to registered, which
drops its counterparties back to public tier and rate card. In AAMP the registry going down is a
pricing event, and one bad verificationstatus record travels just as far. Price that difference
before you decide which layer your revenue depends on.

---

# Agentic Advertising Standards: Two Cover Advertising, One Ships a Contract

Source: https://agenticadlab.com/protocols/

Two standards target agentic advertising: AdCP, one versioned registry from AgenticAdvertising.org, published at 3.1.13 stable; and AAMP, an IAB Tech Lab umbrella over eight repositories with no shared version number. ACP, UCP, AP2 and x402 are commerce and payments protocols.

Two of the standards in this conversation cover advertising, and only one of them has a contract you
can write code against. AdCP is a single versioned JSON Schema registry: 3.1.13 stable, 64 operations
across ten areas, and one machine-readable file that says which release is current. AAMP is an
umbrella over eight repositories that tag on their own schedules, four of which have never been
tagged at all. Outside its bidstream framework there is nothing normative in it to conform to, so
"we support AAMP" today means "we match somebody's Python". There is nothing to point a contract at.

Back AdCP for anything on the campaign path, and treat everything below as the version evidence for
that call. Put "3.1" on the wire for AdCP and read the release pointer for whichever patch the registry is
serving. When a vendor quotes you 3.0 GA off the docs site, the registry is serving 3.1.13 and the
wire contract only cares about "3.1" — that is a correction, not a re-scoping. On the AAMP side,
write the vendor's name into the integration plan instead of the standard's, because the vendor is
what you are integrating with. And keep the other four acronyms out of that budget line entirely.
ACP, UCP, AP2 and x402 settle transactions, and no operation in either advertising stack moves money.

AdCP is one registry. AAMP is eight repositories.

AdCP, the Ad Context Protocol, comes from AgenticAdvertising.org. One repository, one version number.
It standardises a buyer agent buying media from a seller agent, and the two operations you meet first
are getproducts, which asks a seller what inventory it has (natural-language brief or structured
filters, your choice), and createmediabuy, which turns whatever comes back into a campaign.
Twenty-two of its 64 operations are governance, twice the size of the media buy area they sit next
to: AdCP's authors think the hard part of an agentic buy is proving what the agent was allowed to
do. You implement it as an MCP server or an A2A endpoint.

AgenticAdvertising.org is the half of this that needs an introduction. CHARTER.md describes a
Delaware trade association with 501(c)(6) status still pending, four voting classes with equal board
representation (brands, agencies, publishers, technology providers), and a first AGM dated 6 May 2026. CONTRIBUTORS.md names an interim board of four, two of them from Scope3, and says outright
that "Scope3 seeded AAO with foundational IP, funding, and the initial property-catalog knowledge
graph". That is a single-vendor protocol with a trade association forming around it, disclosed by
the vendor, and I would rather price a published imbalance than guess at an unpublished one.
Mediaocean, The Washington Post, Magnite, PubMatic and Yahoo appear on the external contributor
list, which is participation rather than adoption; who actually runs an endpoint in production is
a separate question with a separate answer, and the deployments
ledger is where it gets kept.

AAMP comes from IAB Tech Lab, which wrote OpenRTB, AdCOM, OpenDirect and the Global Privacy Platform.
That provenance normally settles a standards question on its own, which is what makes the current
state of AAMP surprising: it is a name over eight separate GitHub
repositories, each tagging on its own schedule, sharing no common type
system and no common release. The work is the same shape approached from the other end: a
seller-agent SDK over OpenDirect 2.1, Deals API and sellers.json, a buyer-agent SDK to talk to it,
a bidstream framework underneath. One of the eight, the Agentic Real Time Framework (ARTF, in the
repository agentic-rtb-framework), is a finished specification with a release date on it. Most of
the rest are reference implementations.

Anthony Katsur, who runs IAB Tech Lab, says standards proliferation is a real cost to the industry.
He is right, and the bill lands on the buyer rather than on either standards body: two object models
with no shared type between them, and one of the two has no conformance suite to fail. Half the
repositories under his own umbrella have never been tagged, which is the cost arriving inside the
body that named it.

Which leaves the question he does not answer. If proliferation costs what he says it costs, and he
runs the body saying so, does this resolve into one stack before the money you spend this quarter has
depreciated? I do not expect a merger inside eighteen months. The tell that would change my mind is
AdCP-shaped work — a versioned schema registry with a release pointer in front of it — appearing
under an IAB Tech Lab tag, and nothing in the eight repositories is moving that way.

Everything else people bring into this conversation is a transport, an older IAB standard the agents
are built on, or a commerce protocol.

Four of the six acronyms in this conversation settle transactions

| Protocol                          | Steward                                          | Category    | What it standardises                                                                        |
| --------------------------------- | ------------------------------------------------ | ----------- | ------------------------------------------------------------------------------------------- |
| AdCP                              | AgenticAdvertising.org                           | Advertising | Media buying, creative, signals, brand governance, real-time matching                       |
| AAMP                              | IAB Tech Lab                                     | Advertising | Agent discovery and trust, buyer/seller negotiation, bidstream mutation, embedding exchange |
| ACP (Agentic Commerce Protocol)   | OpenAI and Stripe                                | Commerce    | Checkout, payment delegation without becoming merchant of record                            |
| UCP (Universal Commerce Protocol) | Google, with Shopify, Walmart, Target and others | Commerce    | Checkout, payments, fulfilment primitives                                                   |
| AP2 (Agent Payments Protocol)     | originated at Google                             | Payments    | Mandates authorising an agent to pay on a user's behalf                                     |
| x402                              | originated at Coinbase                           | Payments    | Settlement over HTTP, built on the 402 status code                                          |

The ACP and UCP rows are AdCP's own glossary talking about its neighbours. AP2 and x402 are the only
two with no primary specification behind them, taken from
Crossmint's protocol comparison
and the Applied Technology Index 2026
analysis.

The two layers meet at one documented handoff, in Sponsored Intelligence, where
docs/sponsored-intelligence/si-chat-protocol.mdx has the host initiating ACP checkout when the
termination reason is handofftransaction. AdCP's FAQ compresses that to one line: "AdCP owns the
path up to the handoff; the commerce protocol owns the transaction." No AdCP operation settles
anything, and no operation anywhere in the AAMP corpus mentions payment, checkout or a merchant of
record.

One collision in that table is real rather than sloppy. UCP means two different things inside this
one subject area: AdCP's glossary uses it for Google's Universal Commerce Protocol, while the AAMP
repository agentic-audiences was formerly the User Context Protocol, contributed by LiveRamp. Its
surviving JSON Schema still carries an $id pointing at
raw.githubusercontent.com/LiveRamp/user-context-protocol, and its catalog-info.yaml still
declares the project slug LiveRamp/user-context-protocol and the name user-context-protocol. A
document saying "UCP" may therefore mean a commerce protocol or an advertising data plane, and
nothing on the page will tell you which unless you ask who wrote it.

Which version number is real, and which is a press release

AdCP has one machine-readable answer. It lives in dist/schemas/latest.json:

That file is five lines and none of them is ambiguous. Follow the pointer and
dist/schemas/3.1.13/manifest.json stamps its generation time and lists 64 tools.

Four other surfaces in that same repository answer the same question differently:
docs/reference/versions.mdx says 3.1.12, package.json and static/schemas/source/index.json both
say 3.1.1, and docs/building/concepts/industry-landscape.mdx, the page a search engine is most
likely to hand a buyer, prints "Current version | 3.0 (GA, April 2026)". That last one is a whole
minor line and thirty-odd patches behind the registry sitting beside it. The two branch artifacts are
the ones that catch people out, because they are also the first files a reader opens.

The spread does not break a client, and AdCP's own rules say why. Negotiation runs at release
precision: buyers send adcpversion as "3.0" or "3.1", never a patch number.
docs/reference/versioning.mdx puts the build string outside the wire contract entirely, calling
adcp.buildversion "optional advisory metadata for incident triage — not part of the wire
contract". The same file promises that "implementations built against 3.0 will continue to function
against any 3.x release", versions.mdx adds that "3.1 remains additive over 3.0", and every release
from 3.1.4 to 3.1.13 is filed in CHANGELOG.md under "Patch Changes".

That patch classification is the project's own, applied to its own changes. The one time it slipped,
release 3.1.3 was withdrawn for adding a stable schema field in a patch release, a semver violation
against AdCP's own versioning document, caught by the body that wrote both. Somebody caught it, which
is the system working. It also means the stable surface was loose enough for a patch to widen it 25
days after 3.1.0 shipped, and nothing has changed that. Release-by-release detail sits on the
maturity assessment.

AAMP has no equivalent file at all, and the hub README concedes it in one line: "Each repository uses
independent semantic versioning." Four of the eight repositories have never been tagged. The four
that have agree on nothing: the spread runs from v0.5.0 to v2.4.1, and no two sit on the same
version line.

Three AAMP repos ship an API document, and in all three the document's own info.version
contradicts the newest git tag: seller-agent tags v2.4.1 against an OpenAPI 1.0.0,
buyer-agent tags v2.3.0 against 1.0.0, iab-agentic-primitives tags v0.5.0 against 0.1.0.
Generate a client from the OpenAPI file, pin the git tag, and you carry two different version numbers
for the same component, both read correctly. The per-repository matrix is at AAMP
Explorer.

None of that reaches the trade press. Four AdCP numbers are circulating — 3.0 GA, 3.0 RC, 3.1 and
3.1.2 — and not one of the eight published sources covering this opens a repository: the protocol
directory at advertisingprotocols.com has AdCP at "3.0 RC" and AAMP at v2.0, and adgentek.ai runs
a full "AdCP 3.1 vs IAB AAMP 2.3" comparison and takes 3.1.2 from the docs site. "AAMP 2.3" is a
genuine IAB Tech Lab release announcement dated 30 July 2026, so nobody invented it; what it lacks is
a tag, because no repository in the corpus carries a 2.3 at the AAMP level and the closest string
in any tag list is buyer-agent v2.3.0. What the repositories held on the day of that
announcement is a page of its own, and it does not match. A release number tracks
a programme of work while the tags track engineering, nobody has declared either authoritative, and
so every trade article has a defensible source for a different number. When a version gets quoted at
you, ask which file it came out of. A clause in a signed agreement naming "AdCP 3.0 GA" pins a line
the registry moved off months ago, and nobody finds out until the first deprecation.

The AAMP half ships code where AdCP ships contracts

| Artifact               | Steward                | Newest git tag | Version it declares about itself               | What you get                                                             |
| ---------------------- | ---------------------- | -------------- | ---------------------------------------------- | ------------------------------------------------------------------------ |
| AdCP                   | AgenticAdvertising.org | n/a            | latest.json says 3.1.13 stable               | 64 operations, 761 JSON Schema files                                     |
| ARTF                   | IAB Tech Lab           | v1.0         | "Version 1.0, Released November 12, 2025"      | a published specification plus protobuf, eight named Intent mutations  |
| seller-agent           | IAB Tech Lab           | v2.4.1       | OpenAPI info.version 1.0.0                   | OpenAPI 3.1.0, 74 paths, 91 schemas                                      |
| buyer-agent            | IAB Tech Lab           | v2.3.0       | OpenAPI info.version 1.0.0                   | OpenAPI 3.1.0, 13 paths, 8 schemas                                       |
| iab-agentic-primitives | IAB Tech Lab           | v0.5.0       | OpenAPI info.version 0.1.0                   | 48 JSON Schemas; README says not yet released; absent from the hub index |
| agentic-audiences      | IAB Tech Lab           | none           | "Draft v0.1", inside a specs/v1.0/ directory | one JSON Schema, four zero-byte spec files                               |
| agentic-direct         | IAB Tech Lab           | none           | n/a                                            | MCP and A2A wrapper over OpenDirect 2.1                                  |
| registry-agent-example | IAB Tech Lab           | none           | n/a                                            | a single 22-line agent.ts                                              |

Two SDKs, a wrapper and a 22-line example. The specification documents in the set come to one
released standard and two that describe themselves as unfinished.

One name in that table does not mean what buyers assume it means. ARTF imports OpenRTB 2.6 into its
protobuf and mutates live bid objects inside the auction through eight named Intent operations.
Nothing in it negotiates, and nothing in it needs a language model. The r/programmatic thread that
exists only to ask the difference got
there first: "ARTF: Protocol framework to allow custom algorithm companies to standardize how
container services are built on ad tech. Has nothing to do with AI agents. Don't ask me why it got
the word agent in its name." It is also the one AAMP artifact with a finished specification and a
release date, which produces an awkward result: the most complete thing published under the agentic
banner is the piece furthest from anything a buyer would call an agent. AdCP's FAQ files it
"alongside OpenRTB at the impression layer".

It is also the one that goes to your general counsel before it goes to an engineer. ARTF's Go
implementation is AGPL-3.0 under Index Exchange copyright, while the specification document itself is
CC BY 3.0. Vendor that Go code into a hosted exchange and section 13 puts every counterparty hitting
your endpoint in scope for the source. If your exchange is proprietary the choice is binary:
reimplement from the CC BY 3.0 specification, or open the service. Finding that out after the
integration is written is the expensive version.

The row that matters most is iab-agentic-primitives, unreleased by its own statement and absent
from a hub README that lists six component repositories. The wire contract, the piece every other
repository would have to agree on, is the piece you cannot reach from the index. The
repository-by-repository read is at AAMP: what IAB Tech Lab has published.

Neither stack invented its transport

AAMP did not invent most of its object model either.

AdCP runs over MCP and A2A. Its glossary
defines the protocol itself as "domain-specific tasks and schemas that work over MCP and A2A as
transports", and the Trusted Match operations sit outside both, on a direct HTTP/2 API per
docs/trusted-match/router-architecture.mdx.

AAMP runs over MCP, A2A JSON-RPC 2.0 and REST, with gRPC for ARTF. Its control plane is assembled
from IAB standards that predate the agentic work. OpenDirect 2.1 supplies Account, Order, Line,
Product, Creative, Assignment and ChangeRequest; AdCOM and OpenRTB 2.6 supply the creative and
bidstream shapes; sellers.json supplies supply-chain transparency.

AdCP wrote a new object model and published schemas for it, where AAMP wrapped existing IAB standards
in agent interfaces. Which of those two bets ages better is not answerable from a file, and I would
not trust anyone claiming it this early. What is answerable is which one you can build against this
quarter, and my money is on the stack that can be frozen and re-tested. Fund AdCP for anything on the
campaign path, name the vendor rather than the standard for anything on the AAMP side, and get the
licence question in front of legal before an engineer opens ARTF's repository.

Read next: AdCP vs AAMP costs the two against each other, and what IAB
Tech Lab has published reads AAMP repository by repository.

---

# How a Machine Actually Buys Media, End to End

Source: https://agenticadlab.com/guides/how-a-machine-buys-media/

How a machine buys media: one CTV campaign runs 13 of AdCP 3.1.13's 64 operations, from get_adcp_capabilities through create_media_buy to get_media_buy_delivery. AAMP's shared contract begins at the quote and stops at the deal ID, leaving creative, delivery and spending authority outside it.

AAMP's shared buyer-to-seller contract begins at the quote and stops at the deal ID. Creative, delivery reporting and spending authority fall outside it, which puts all three inside your integration budget, per counterparty, forever.

AdCP's surface runs the other way, from who authorised the spend through to what it delivered and who gets billed for the tooling. One connected-TV campaign uses 13 of the 64 operations it publishes in 3.1.13. The procurement decision is settled before the first payload, by where each contract starts and where it gives up.

The two stacks, step for step

| Step                 | AdCP 3.1.13                                                                                                 | AAMP canonical contract                                                                                         |
| -------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Capability discovery | getadcpcapabilities                                                                                     | /.well-known/agent.json, then /registry/agents/discover                                                     |
| Spending authority   | syncplans, then checkgovernance                                                                       | None. ConsentContext rides on the quote                                                                       |
| Inventory discovery  | getproducts with a prose brief                                                                         | GET /products, then /products/avails                                                                        |
| Price agreement      | refine with an ask, then finalize                                                                     | /api/v1/quotes, then a numeric buyerprice                                                                  |
| Audience attachment  | getsignals, activatesignal, syncaudiences                                                          | audienceplan, an open object                                                                                 |
| Creative             | synccreatives, buildcreative and six more                                                             | None in the wire contract                                                                                       |
| Commit               | createmediabuy returning mediabuyid                                                                 | /api/v1/deals returning dealid                                                                             |
| Modification         | updatemediabuy, PATCH semantics                                                                         | /api/v1/change-requests                                                                                       |
| Delivery reporting   | getmediabuydelivery, getmediabuys                                                                  | None. /deals/{id}/performance on the seller agent, /reports/{jobid} on the buyer agent, neither a standard |
| Closing the loop     | provideperformancefeedback, reportplanoutcome, reportusage                                       | No counterpart                                                                                                  |
| Errors               | core/error.json, 92 documented codes, open vocabulary, recovery, retryafter, 15 typed detail schemas | ErrorEnvelope, closed 11-code enum, no recovery or retry hint                                                 |

Four of those eleven rows are empty on the AAMP side, and the two questions a finance team asks first, who authorised this spend and what did it deliver, are two of the four. That is my case for putting AdCP first on an integration roadmap and treating AAMP as the negotiation layer it is good at. The longer version of that argument sits with the version evidence.

The price of the call is the negotiation record. AdCP has no field for a counter-offer, so a desk that wants a machine-checkable concession trail builds one in its own orchestration, and AAMP is the stack that already has one. Governance is the second qualification: checkgovernance validates against a registered plan, so with no plan there is nothing to check, and AdCP ships its strongest control as opt-in.

Who is in the trace

AdCP is the Ad Context Protocol, one versioned registry out of the adcontextprotocol project, and you call its operations as tool calls over MCP and A2A. AAMP is Agentic Advertising Management Protocols, IAB Tech Lab's umbrella over eight independently versioned repositories, and its shared contract is an OpenAPI 3.1 document you hit over plain HTTP, so where one stack has operation names the other has URL paths.

Five parties show up: a buyer agent for the advertiser, a seller agent for the publisher, and AdCP's governance agent (spending authority), signals agent (segments) and vendor agent (invoicing). AAMP's shared contract knows about two.

buildcreative, previewcreative, updatemediabuy and syncaudiences get named in passing and never called, which leaves 51 operations a straightforward campaign never touches. A campaign that changes mid-flight adds updatemediabuy to the count. Anyone quoting you a per-operation implementation estimate for all 64 is quoting you for a surface you will not use.

The payloads below are the wire view: real field names at the paths the schemas put them, with the budgets and identifiers invented. There is a prose version of the same buy, no field names in it, if you want the story first.

Before the first call

The envelope will not let you pin the wire version at release precision. core/version-envelope.json takes adcpversion as a major and a minor with an optional prerelease suffix, so "3.1" validates and "3.1.13", the release you read the schemas from, does not. The file says why: "Patches are not negotiated; surface them as buildversion on capabilities for operational visibility." Keep emitting the deprecated adcpmajorversion through 3.x anyway, for sellers that read only the legacy field.

Capability discovery, then spending authority

getadcpcapabilities is the only unconditionally required task in AdCP. The Shared table in docs/protocol/required-tasks.mdx has one other row, syncagentnotificationconfigs, and it is conditional.

Two things come back that you have to read: supportedprotocols, and an adcp block whose supportedversions is the authoritative list of releases the seller speaks. Read requestsigning off the same response before you send anything mutating. It says whether RFC 9421 signed HTTP requests are required, and finding that out from a failed createmediabuy is finding it out too late.

The request's protocols enum is snakecase: mediabuy, signals, governance, sponsoredintelligence, creative. The registry directories for those areas are kebab-case. A client that generates its constants from directory names ships strings the seller rejects.

Spending authority lives with the governance agent, and the plan gets registered there before any buying happens.

One entry in plans[], alongside a required idempotencykey. The first five members are required; the optional ones carry the teeth. static/registry/policy-categories/ holds ten categories as registry strings rather than an enum, so a new category can arrive without a release. Only four of the ten are enforced by the validator itself, and they are the four you would guess from a compliance memo: fairhousing, fairlending, fairemployment, pharmaceuticaladvertising. The other six, politicaladvertising included, are strings no code reads, so the extensibility is currently a place to file categories that do nothing. If your compliance officer is relying on one of those six, tell them today rather than in the incident review.

How AdCP negotiates a price: in English, and in nothing else

getproducts is discovery, and buyingmode is required on every 3.x request, taking brief, wholesale or refine.

The response carries products[] and, when the seller curates rather than filters, proposals[]. A product has 44 properties, requires seven, and carries pricingoptions as a discriminated array with nine models on disk, CPM through flat rate and time. Choosing a pricingoptionid is how an AdCP buyer accepts a rate; the getproducts reference has the other 43 fields, and what belongs in the brief string rather than in filters is a decision with money on it.

Pushing back happens inside getproducts too, on a second call with buyingmode: "refine". Entries are discriminated on scope: request-scoped carries only a prose ask, product-scoped adds morelikethis, and only proposal-scoped takes finalize. Finalize is exclusive: "if any entry has action: 'finalize', ALL entries in the array MUST be proposal-scoped with action: 'finalize'", or the seller returns INVALIDREQUEST. Multiple finalizes all land or none do. There is no rollback, and proposalstatus has exactly two values, so a half-finished finalize is neither visible nor recoverable.

That prose ask is the whole negotiation vocabulary. Nowhere in the published schemas is there a buyerprice, a roundnumber or a concessionpct. A trading desk that wants a machine-checkable concession trail out of AdCP is going to build it in its own orchestration or not have one.

Creative, and the two shapes that catch people out

Creative is eight operations in AdCP, third-largest behind Governance's 22 and Media Buy's 11, and zero operations in AAMP's shared contract. Build against AAMP and the creative pipeline is yours to invent.

synccreatives upserts into a library capped at 100 creatives per call.

A creative requires creativeid, name and assets, and two of those three have a shape that catches everyone once. assets is an object keyed by the format's assetgroupid rather than an array, with each value carrying an assettype discriminator that selects the matching asset schema. formatid is always a {agenturl, id} object rather than a plain string, mutually exclusive with formatkind.

dryrun, validationmode and deletemissing are the flags worth knowing before the first run against a new counterparty, and the creative area reference has the other seven operations. dryrun rehearses the sync without applying it, validating library upsert semantics and creative IDs against the seller's current context. validationmode defaults to strict, which fails the entire sync on any error, against lenient, which processes the valid creatives and reports the rest. And deletemissing turns the call into a full library replacement by archiving everything not named in this request, which the schema flags "use with caution" and refuses to combine with creativeids.

Signals attach on a discriminated destination

Third-party segments and first-party CRM records take different operations. getsignals and activatesignal handle segments; CRM records go to syncaudiences, whose SHA-256 hashedemail the schema calls "Pseudonymous PII, not anonymous". Both roads end in targeting, which is why signal and audience get conflated.

idempotencykey, signalagentsegmentid and destinations are all required, and core/destination.json is a oneOf discriminated on type: a platform branch requiring a platform string, or an agent branch requiring an agenturl. Both take an optional account. action also takes deactivate, which the schema ties to data governance, "removing the segment from downstream platforms, required when campaigns end to comply with data governance policies (GDPR, CCPA)". The teardown is in the contract rather than in a runbook.

The verdict before the money

checkgovernance is the gate, and it is read-only.

The response requires checkid, verdict, planid and explanation. verdict takes approved, denied or conditions; on conditions the conditions array says what has to become true, and expiresat says how long the verdict is good for. Porting 3.0 code, read that field's description first: "Renamed from status in 3.1 to free the top-level status key for the envelope task-status ..." The enum values did not move, only the property name, so a 3.0 client reads the task status and treats it as the decision.

Then the money.

Five fields are required and neither packages nor proposalid is one of them. Executing a committed proposal by proposalid lets you skip packages; the seller derives them from the proposal's allocations.

reportingwebhook, artifactwebhook and pushnotificationconfig are optional and sit alongside those, and the first has a requirement inside it. reportingwebhook resolves to core/reporting-webhook.json, which requires url, authentication and a reportingfrequency of hourly, daily or monthly, and that frequency "must be supported by all products in the media buy". An hourly setting across a mixed CTV and online-video buy can be invalidated by a single product. The other two slots take a URL and its auth.

The response is one of exactly three mutually exclusive shapes, all three worth reading in full before you write the client. Sync success returns mediabuyid, packages and a mediabuystatus of pendingcreatives, pendingstart, active or paused. Terminal failure returns an errors array and no media-buy artifact. The submitted branch returns a taskid, and mediabuyid lands on the task's completion artifact. A client that reads mediabuyid unconditionally breaks on that third shape, which is what you get whenever a human signs an insertion order. A repeat of the key returns the existing buy, marked replayed: true on the envelope.

That third shape is the general case for seven of the 64 operations: getproducts, createmediabuy, updatemediabuy, synccreatives, synccatalogs, buildcreative and getsignals all ship async response arms and can return status: "submitted" and a taskid instead of a result. The other 57 answer in line, so a client that treats all 64 as async keeps books for 57 that never need them. Retrieval is specified either way: enums/task-status.json says the client "can always poll gettaskstatus (legacy tasks/get) with taskid", webhooks through pushnotificationconfig are A2A and REST only because "MCP uses progress notifications instead of webhooks", and a submitted task is queued for "hours to days", so the polling interval comes off a human's calendar rather than a request timeout.

The reporting loop runs to three different agents

getmediabuys answers what state the buy is in. getmediabuydelivery answers what it delivered, and requires nothing at all.

Every field there is optional, including the buy you are asking about, so an empty request is a schema-valid way to ask a seller for everything. The response carries partialdata and nextexpectedat, because some channels report in stages.

The three reports that close the campaign do not all go to the same place. provideperformancefeedback goes back to the seller carrying a normalised performanceindex rather than raw conversions, and that single float is the entire quantitative channel from buyer to seller in 3.1.13. The governance agent gets reportplanoutcome. reportusage is for the vendor agent, and it exists because AdCP does not settle payment: it reports the consumption an off-protocol invoice gets built from. Build only the seller-facing half and you have built a third of the loop.

Most of a client's code lives in the error model

Both stacks publish one error shape and then disagree about what a code is for. AdCP's core/error.json requires code and message and carries a retryafter the client "MUST clamp" to 1 through 3600 seconds. Its vocabulary is 92 documented codes in enums/error-code.json, deliberately open: error.code is wire-typed string, sellers may emit codes outside the list, and receivers "MUST decode unknown codes" by falling back to error.recovery, one of transient, correctable, terminal. So the code list is documentation and the recovery classification is the contract. When recovery is absent it defaults to transient, which means an error that forgot to say what kind of error it is gets retried.

Underneath that sit 15 typed schemas in error-details/, one per failure a client can do something about. The three that change client behaviour most are budget-too-low, version-unsupported and rate-limited, each carrying the field that makes the next attempt different from a repeat: a minimum budget, the version the seller does speak, a wait. A production client spends more code against those 15 than against the happy path.

AAMP's ErrorEnvelope is one shape over a closed 11-value enum, with no recovery classification and no retry timing. A closed enum is easier to switch on, and a client built on one ships a release the day the spec adds a code.

The same buy through AAMP's contract

The wire contract underneath everything in this section is unreleased: both reference agents pin the package at v0.5.0, and the OpenAPI document's own info.version reads 0.1.0. Read the field names below as intent rather than as an integration target.

Discovery is a file plus a registry call. GET /.well-known/agent.json returns the Agent Card with capabilities, skills, inventorytypes, supporteddealtypes and truststatus; POST /registry/agents/discover registers the counterparty with a one-field body. No capability negotiation, no version pin, nothing saying which release you are talking to. Agent discovery files has both models side by side.

GET /products takes limit and offset and nothing else, because "filtering is client-side; no /products/search". Then POST /products/avails per product, in the lowercase unseparated field names (productid, startdate, enddate) inherited from OpenDirect 2.1. POST /api/v1/quotes requires idempotencykey, productid and dealtype, one of PG, PD or PA, and buyeridentity sets the access tier, though "the effective tier is capped server-side by registry-verified trust" and that ceiling is code rather than schema, TRUSTTIERCEILING in registryclient.py. So the tier your agent asks for is a claim the seller's registry lookup can quietly downgrade, and the round limits and concession caps you thought you had move with it.

Here AAMP has a step AdCP doesn't.

That price object is the most opinionated thing in either corpus. Flagged decision FD-11 makes Money an integer micros amount and bans floats: "IEEE 754 floating point is non-deterministic for money math ... that defect must not be fossilized into the spec." Sending 41.50 gets rejected rather than truncated. The one float left on the wire is avails.budget. action takes accept, counter, finaloffer or reject and has no default, and a round requires roundnumber, buyerprice, sellerprice and action, with the response adding concessionpct and cumulativeconcessionpct. Round limits and concession caps vary by trust tier, four rows of them, on AAMP Explorer.

Booking is thin because the quote did the work: POST /api/v1/deals requires only quoteid and idempotencykey, and the Deal it returns requires dealid, dealtype, product, pricing and terms while carrying openrtbparams optionally. openrtbparams is the field that hands the buy to a DSP, and a seller can return a valid, booked Deal without it.

What the schema enforces, and what it only describes

53 AdCP schema files carry an if conditional. Zero of AAMP's 48 shared-contract schemas do. An if is a rule a validator will hold your counterparty to; a description is a rule you will be arguing about over email.

| Stack                     | Payload                                                                    | Result                                                     |
| ------------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------- |
| AdCP syncplans         | policycategories: ["fairhousing"], no humanreviewrequired          | rejected: "'humanreviewrequired' is a required property" |
| AdCP syncplans         | same plan, humanreviewrequired: false                                  | rejected: "True was expected"                              |
| AdCP syncplans         | policyids: ["euaiactannexiii"], no humanreviewrequired          | rejected                                                   |
| AdCP syncplans         | policycategories: ["politicaladvertising"], no humanreviewrequired | accepted                                                   |
| AdCP createmediabuy   | the required five, neither packages nor proposalid                    | accepted                                                   |
| AAMP NegotiationMessage | action: "counter", no buyerprice                                      | accepted                                                   |
| AAMP NegotiationMessage | action: "reject" carrying a buyerprice                                | accepted                                                   |
| AAMP NegotiationMessage | buyerprice.amountmicros: 41.5                                          | rejected: "41.5 is not of type 'integer'"                  |
| AAMP NegotiationMessage | a price with no action                                                   | rejected: "'action' is a required property"                |

AdCP's hardest governance rule compiles. Declare fairhousing and the validator makes you declare human review, and it will not take false for an answer either. Declare politicaladvertising and nothing happens.

FD-11 holds up on the AAMP side, so floats bounce. The negotiation rules go the other way: buyerprice is described as "REQUIRED for 'counter'/'finaloffer'" and "omitted on 'reject'", and the validator enforces neither, so a counter with no price and a rejection carrying one both sail through. Anyone building against NegotiationMessage is implementing that state machine in application code, whether they planned to or not.

create-media-buy-request.json says "One of packages or proposalid must be provided" and has no oneOf to make it so, which is why the call that commits the money accepts a request with nothing to buy in it. Run both stacks' schemas against your own fixtures before you trust a description.

Neither trace measures delivery against a conversion, and neither settles a payment. AdCP says the first part about itself in known-limitations.mdx: "Not an attribution protocol." The list of everything else neither stack standardises is longer than the trace above. So the thirteen calls get you a booked, delivering, governed campaign and stop one step short of the number your CFO cares about, which stays where it is today: in your measurement stack, reconciled by hand.

If you are scoping one of these integrations, I do that for money.

---

# Protocol Integration and Agent Readiness Work

Source: https://agenticadlab.com/services/

Protocol integration work is the L4 business logic no SDK ships: implementation reviews against a named AdCP release, readiness audits, adagents.json and brand.json validation, and buyer or seller agent builds. Unaffiliated with AgenticAdvertising.org and IAB Tech Lab, and not a certification.

The protocol layer of an agentic integration is nearly free, and AdCP is the one saying so. The layer underneath it, the one that decides whether your agent sells anything worth selling, has never been priced by anybody, AAO included. Every quote you receive this year blurs the two together, which is how the expensive half gets billed as though it were the cheap one.

So split any integration proposal in half before you read the number on it. Ask which of the two layers the figure covers, ask for the second half itemised, and treat a single blended total as a refusal to answer.

Four pieces of work sit against that split, and each one ends in something written down:

| Engagement                  | What it ends in                                                                                                                           |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Implementation review       | Your requirement level per operation, the deprecated fields you are still sending, and the operations you built that nobody asked you for |
| Readiness audit             | A written finding on role, transport, requirement level, discovery model and registry access, plus a build-or-wait recommendation         |
| Discovery file work         | adagents.json and brand.json in the correct one of the two permitted shapes, validating against a named release                       |
| Buyer or seller agent build | L4 written against the published schemas, on top of the SDKs at L0 to L3                                                                  |

Your engineering lead is pricing the whole build. The standards body is pricing the three-quarters an SDK already ships.

The cheap number is a card on the front page of AdCP's building docs:

 Point a coding agent at a skill file, get a storyboard-compliant AdCP agent in 2–8 minutes (protocol layer only — see Operating an agent for the full going-live scope).

Leave that parenthetical in and the number covers a quarter of the engineering. AdCP numbers its own stack L0 to L4 — wire and transport, identity and signing, auth and registry, protocol semantics, and your business logic — and every SDK on either side of the industry stops at L3. Storyboard-compliant is a narrow claim about the first four of those: storyboards are AdCP's executable conformance suite, YAML scripts a compliance runner replays against a live agent, and the conformance page says flatly that "the storyboards ARE the conformance specification."

The same documentation prices that path for anyone who is not pointing a coding agent at a skill file. An agent "enforces the protocol (~3–4 person-months at L0–L3)" while a caller "consumes it (weeks of handler glue)". Then: "SDKs absorb L0–L3; L4 is the part you write either way."

AdCP decomposes L3 to the week: six to seven weeks for the seven lifecycle state machines, a week for the idempotency cache, one or two each for the async-task store, the error catalog and the complytestcontroller surface. That totals a from-scratch agent at 14 to 18 weeks for one senior engineer, with an instruction to multiply by two or three at publisher scale. Against L4 the same document writes one line: "Out of scope for any SDK. The adopter writes this."

I don't publish an L4 range either, and I'd distrust anyone who does. A band is honest at L0 to L3 because it is the same work at every shop, which is exactly why AdCP could publish one and why you can hold any vendor to it. At L4 the same job title covers a two-file review and a full sell-side build. Sell-side L4 is inventory forecasting against your real ad server, pricing and deal terms, creative review policy, and upstream calls to GAM, FreeWheel, Kevel or your own decisioning engine. Ask your ad ops lead one question before you scope anything: are forecast and rate card available over an API today? That answer sizes the project more than the protocol choice does. If they are, L4 is wiring. If they are not, the first half of your agentic project is exposing them, and that half is not an AdCP project at all. Buy-side L4 is smaller by construction — planning, budgeting, agent selection, reporting ingest — with no server to stand up and, in AdCP's own words, "no conformance bar to certify against on the consumer side". Ask me for a number once that scope is written, and apply the same rule to anyone who offers you one before it is.

AdCP ships one versioned registry, maintained by AgenticAdvertising.org (AAO), a Delaware nonprofit trade association. AAMP, Agentic Advertising Management Protocols, is IAB Tech Lab's umbrella over eight repositories that version independently of each other, so an AAMP integration has nothing single to pin. That difference is most of why the two stacks cost different amounts to adopt.

| Layer                     | What it covers                                                                                                   | AdCP  | AAMP                                                      |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------- | ----- | --------------------------------------------------------- |
| L0 — wire and transport   | JSON-over-HTTP framing, MCP envelopes, A2A SSE streams, schema validation                                        | SDK   | iab-agentic-primitives v0.5.0, installed from a git tag |
| L1 — identity and signing | RFC 9421 HTTP message signatures, key rotation, replay windows                                                   | SDK   | same package                                              |
| L2 — auth and registry    | Agent identity verification, brand resolution, AAO bridge, multi-tenant account resolution                       | SDK   | registry is an external service with a credential gate    |
| L3 — protocol semantics   | Lifecycle state machines, idempotency, error catalog, async-task contract, webhook emission, conformance surface | SDK   | 48 JSON Schemas, three of them half-built                 |
| L4 — business logic       | Inventory, pricing, creative review, decisioning; or planning, buying, reporting                                 | yours | yours                                                     |

There is no GA SDK in that right-hand column, and the shared wire contract is unreleased by its own statement. Both IAB reference agents pin it from a git URL rather than a package index: iab-agentic-primitives[client] @ git+https://github.com/IABTechLab/iab-agentic-primitives.git@v0.5.0, identically, in seller-agent/pyproject.toml and buyer-agent/pyproject.toml. Three of its schema pairs are missing a half: AgentDiscovery has a request and no response, ChangeRequest and NegotiationRound have responses and no requests. You write those halves yourself, so does everyone else integrating against AAMP, and nothing forces two of those implementations to land on the same shape.

Your role needs seven operations. The buyer's role needs none.

AdCP 3.1.13 registers 64 operations. That is the number a vendor will scope against, and it is the wrong one. The required-tasks specification breaks the surface down by role, and the per-role sets are small.

| Role                                    | Required | Conditional | Optional |
| --------------------------------------- | -------- | ----------- | -------- |
| Media Buy — sales agent (seller)        | 7        | 2           | 4        |
| Media Buy — orchestrator (buyer)        | 0        | 0           | 0        |
| Creative agent                          | 1        | 3           | 3        |
| Signal agent                            | 2        | 0           | 0        |
| Brand agent                             | 1        | 4           | 0        |
| Governance — campaign                   | 4        | 0           | 0        |
| Governance — property                   | 5        | 0           | 1        |
| Governance — collection                 | 5        | 0           | 0        |
| Governance — content standards          | 4        | 0           | 3        |
| Governance — creative                   | 1        | 0           | 0        |
| Sponsored Intelligence                  | 3        | 0           | 1        |
| Accounts (any agent accepting accounts) | 0        | 4           | 1        |

Every agent also owes the shared getadcpcapabilities. The media buy and creative rows already count it; add one to every other row, so a signal agent's real Required set is three operations rather than the two printed above.

The specification is blunt about the buyer: "Orchestrators are not MCP/A2A servers — they call sales agent tasks." Buy-side conformance is five numbered obligations and not one implemented operation: authenticate, send required fields, handle async task responses and webhook delivery, carry mediabuyid forward, respect creativedeadline. A readiness score that grades a DSP on operation count therefore has nothing to count, and will report a zero that says nothing about the DSP.

Two operations in that requirement matrix are not in the published registry at all. syncagentnotificationconfigs is listed Conditional for every AdCP agent; validatepropertydelivery is listed Optional for property governance. Neither name appears anywhere in the 3.1.13 schema index. The document you'd be graded against lists operations the release never registered, and the full registered-versus-shipped split is on adcpexplorer.

The work is at the boundaries neither stack has verified

AAO and IAB Tech Lab have each published an inventory of what they have not checked. Neither inventory mentions the other stack, which is the wider asymmetry in one specific form. Put the two inventories side by side and you have the scope of an integration.

AAMP's inventory is machine-generated, and that is the only reason I trust the numbers in it. STANDARDSGAPREPORT.md in iab-agentic-primitives is rendered by the library's own conformance runner, with a drift-guard test asserting the committed file matches a fresh render. It tracks 12 standards: 4 fully self-conformant, 0 partial, 8 unverified pending external spec. Its own executive summary names the worst one: "Highest-priority gap: IAB OpenDirect 2.1 — field-level fidelity for the core commercial booking surface (Orders / Lines / Products) is the most consequential unverified claim."

I'd go further than they do. The unverified list includes AAMP's own agent registry specification, and the remediation step reads: "Obtain the IAB Tech Lab AAMP (agent discovery and trust registry) specification." The people who wrote the wire contract couldn't get the registry spec either.

| Boundary                   | AdCP                                                                                                    | AAMP                                                                                                                                              | Where it bites                                             |
| -------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Commercial booking         | 64 operations registered at 3.1.13, with a storyboard suite that grades an agent's declared specialisms | OpenDirect 2.1 UNVERIFIED, named the highest-priority gap                                                                                         | Reconciling an agentic order with the system that bills it |
| Discovery and trust root   | adagents.json on the publisher's own domain; the AAO directory is "discovery, not authorization"      | GET /.well-known/agent.json, public, no auth, self-declared capabilities                                                                        | Deciding whether an agent may sell what it is offering     |
| Registry entry             | a file you host                                                                                         | a live service at registry.iabtechlab.ai, JWT bearer, company domain must match primarydomain                                                | Whether you can onboard without an IAB credential          |
| Verification status        | AAO Verified is still Request for Comments, membership-gated, qualifiers half-renamed                   | truststatus semantics "asserted by our own spec, not against AAMP publications" | Every contract clause that says "verified agent"           |
| Consent strings (GPP, TCF) | not audited                                                                                             | carried as opaque values on the EP-10.4 ConsentContext; no section validation, no TC-string decode, no GVL check                                  | EU and California delivery                                 |

AdCP's problem is internal drift. The verification page says plainly that "The (Sandbox) qualifier replaces the earlier draft's Verified (Live) framing", citing issue #4379 for the reframe verdict. Five other doc files still use (Live) normatively, and one of them turns it into a requirement: the accounts specification says media-buy sales agents advertising "AAO Verified (Live)" readiness "MUST support a named scope identified by scopename: "attestationverifier"". Read that specification front to back and you'll build a named authorisation scope to qualify for a badge tier the verification page says was replaced. Closing that MUST is a reading job for you and an open issue for them.

Those rows don't cost the same to close. The trust-mark drift is findable in your accounts implementation in an afternoon, and the finding is which scope you built for nothing. OpenDirect fidelity only surfaces in a build, because it is a field-by-field reconciliation between an agentic order and the system that bills it, and nobody grades that from the outside. The registry specification stays open whatever anyone does: IAB Tech Lab hasn't published it, and what is documented anywhere about registry.iabtechlab.ai comes from the AAMP client library's own sandbox notes rather than from a specification. Until that changes, no work on your side closes that row, and any vendor who tells you otherwise is quoting you for a document they do not have either.

Every engagement ends in a written finding against a named release

Scope follows your role in the transaction. The size of the protocol has almost nothing to do with it, which is why the four engagements below differ more by which side of the transaction you sit on than by which stack you picked.

An implementation review is a second reader on an integration you've already started. I grade what you've built against the required-tasks specification for your role, and against the 3.1.13 schema index for the operations, rather than against whatever main happens to contain that week. It ends in a list: deprecated fields you are still sending, your requirement level per operation, your transport declaration, and the operations you implemented that nobody asked you for.

A readiness audit is the same exercise before any code exists. Role in the transaction, transport, requirement level, discovery model, and whether the registry you'd federate into will let you in. It ends in a written finding on each of those five, a gap list against a named release, and a build-or-wait recommendation with the reasoning attached. There is no maturity score in it.

The cheapest useful thing a publisher can do is get adagents.json and brand.json right, and it is the thing most often wrong on the first attempt. The file has two mutually exclusive shapes, a URL-reference variant requiring authoritativelocation and an inline variant, and picking the wrong one is the most common first error I see. delegationtype takes exactly three values, direct, delegated and adnetwork, before you get to collections, placementids and placementtags scoping. Scale is why the AdCP directory API exists at all: the directory-API docs say CafeMedia alone delegates around 6,800 publisher domains under a single manager file. I wrote how the discovery files fit together as the free version of this. The paid version is me reading yours.

Builds are the rest of it, and the largest part. Sell-side that means inventory, pricing, creative review and decisioning, wired to the seven operations a sales agent owes and to whichever of its two Conditional and four Optional ones your business actually needs. Buy-side there is no server to stand up at all, so a buyer agent build is planning, buying and reporting against someone else's operations, plus the five orchestrator obligations the specification puts on the caller. I use the AdCP SDKs at L0 to L3 and write L4 against the published schemas, not against a commercial vendor's abstraction over them, because the schemas are the thing that carries a version number. How a machine buys media traces the wire-level path one of those builds follows, end to end.

The bills that arrive when nobody does this work

Anthony Katsur, IAB Tech Lab's chief executive, says standards proliferation is a real cost to the industry. Katsur is describing a cost his own organisation is generating: eight repositories versioning apart from each other, no GA SDK, and a registry specification his own wire-contract authors have filed a remediation step asking to be sent. Neither standards body pays for the split it creates. You do, in four places, and all four are cheap to close early and expensive to close late.

The first is internal, and it is the one that actually stops projects. From a publisher running an AdCP sales agent trial, on r/programmatic:

 "we spent 3 weeks just trying to get sales and ops to align on what a 'good deal' looked like before we could automate anything useful"

There is no protocol in that work. Floor prices by format and daypart, which advertisers get exclusivity and on what terms, which first-party segments an agent may expose to a stranger, what a house account is allowed to undercut: none of that is in a schema, none of it ships in an SDK, and every one of those decisions is currently made by a person applying judgement they have never had to write down. An agent applies the policy it can read, so either somebody writes those decisions down or the defaults in your handler code become your commercial policy. Three weeks is what the alignment costs when sales and ops sit in the same building and both want the project. It is a quarter when the two functions report into different P&Ls and the answer moves someone's commission, and that is the version I see more often. The integration ships either way, on whatever the engineer picked, and starts executing terms nobody signed off.

The other three are quicker to name. Building against documentation instead of against a release gets you an authorisation scope written for a retired badge tier and handlers for two operations the registry never carried, with no way to tell which is which until you read the schema index yourself. A discovery file in the wrong shape fails silently: nothing errors, your inventory is simply not attributable to the agent you authorised, and a buyer that validates strictly has grounds to ignore the file entirely. And a blended quote hides which half of the stack you are paying for until the invoice for the second phase arrives.

Can anyone sell you an AAO Verified badge?

AAO Verified eligibility requires "an active AAO membership with API-access tier", and AAO's own registry documentation is blunt about what happens next: "Membership lapse revokes the entire badge immediately, regardless of storyboard results." The mark is also explicit that it is "Not certification beyond AAO membership". AAO runs both things: the trust mark, which grades an agent's wire behaviour against the storyboards, and a graded certification track in its Academy, where the AI disclosure page says AAO "is both the issuer and the grader of these credentials". Passing one gets you nothing in the other. I can get you to a passing storyboard run. I can't sell you the membership, and neither can any other vendor.

Worth knowing whose incentives are in that paragraph: AAO sells the membership the badge depends on, and I don't buy media, plan it or resell it, and take no commission on spend, so the only thing I have to sell you is the reading. About sets out how the verification here is done and who pays for it.

The AdCP SDKs cover L0 to L3 for nothing

AAO handed development of the reference sell-side agent to the Prebid community in February 2026, described in the SDK stack docs as an open-source seller-side agent publishers run as their AdCP-facing implementation, "hand-rolled at L0–L3 today". What that free path doesn't cover is pointing it at your actual inventory and finding out which boundary breaks.

There is also a threshold below which the honest finding is to wait. If your role's Required set is two operations, and the registry you'd federate into is specified by a document the standard's own authors have asked to be sent a copy of, that is what the audit says, and it says it in writing.

If you want the L0 to L3 code written, hire someone else

Publishers and platforms deciding whether to expose a sales agent. Agencies and DSPs weighing a buyer agent build against holding for one more release, where the audit costs less than the quarter you'd otherwise spend guessing. Vendors who want a reader from outside both standards processes, which is most of my work.

Not you, if what you want is an implementation partner to write the protocol layer. The SDK already ships it, and any line item covering it is a line item you can strike before you sign.

AdCP vs AAMP compares them row by row. If you only want the boundary list, that is what neither stack standardises. AAMP is the maturity read on the IAB side, and the gap report itself is here.

Email hello@agenticadlab.com with your role in the transaction, your current integration state, and which stack. That's enough for me to say whether there's an engagement here or whether you get a two-line reply telling you to wait.

---

# Five Gaps Neither AdCP Nor AAMP Fills, and the Registry That Should Police Them

Source: https://agenticadlab.com/guides/what-agentic-ad-protocols-dont-standardize/

Neither AdCP 3.1.13 nor any AAMP repository standardises measurement, invalid-traffic detection, billing settlement, cross-stack identity or dispute resolution. All five land in a contract you renegotiate with every counterparty, which is what makes them expensive.

Measurement, invalid-traffic detection, billing settlement, cross-stack identity and dispute resolution. Neither AdCP nor AAMP standardises any of the five, so each of them ends up in a contract instead of a schema, and that is what makes them expensive. A schema is a one-time integration cost. A contract is one you pay again with every counterparty you sign.

The single finding I would carry into a procurement review is smaller than any of the five and sits underneath all of them. AdCP has one human-review rule that a schema enforces rather than a policy document requests, covering fair housing, fair lending, fair employment, pharmaceutical advertising and EU AI Act Annex III, and it fires only for buyers who have opted into plan registration. Nothing in the protocol notices when a counterparty doesn't.

AdCP, the Ad Context Protocol, is one versioned registry, currently 3.1.13, and it publishes its own non-goals, which more specs should. docs/reference/known-limitations.mdx opens with a line worth stealing: "Knowing what a protocol doesn't do is part of evaluating it." Hold that page against the schemas the same repository ships and it undersells AdCP in one place, and in another it describes a mechanism that no longer exists. The shipped half is not frozen either: every schema file under trusted-match and every one under sponsored-intelligence carries an experimental x-status marker, so identity matching and sponsored discovery are both still moving under anyone building on them.

AAMP is IAB Tech Lab's programme of eight independently versioned repositories, whose own files disagree about what the acronym stands for, and there is nothing at the umbrella level to hold anyone to. The nearest artifact is STANDARDSGAPREPORT.md inside iab-agentic-primitives, which is at v0.5.0 and unreleased by its own README. It audits that library against 12 external standards, marks 8 unverified, and writes down a rule I have not seen another spec put in writing: "'We model a field named after a standard' is never treated as 'we verified conformance against the published standard'."

Disclosure, because it colours everything below: drafting those clauses against the schemas is work we sell.

| Gap                              | AdCP 3.1.13                                                        | AAMP                                                                | Risk lands on |
| -------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------- | ------------- |
| Measurement and attribution      | Non-goal, beside an empty measurement protocol                   | No measurement object in the shared contract                        | Buyer         |
| Invalid traffic and verification | Outside the protocol; contractible via performance-standard.json | Viewability priced and goal-tracked, never attested                 | Buyer         |
| Billing settlement               | Non-goal; usage reporting only                                     | No invoice, usage or payment primitive                              | Both          |
| Cross-stack identity             | Opaque tokens, no cross-protocol mapping                           | Audience, bidstream and account identities, no mapping between them | Buyer         |
| Dispute resolution               | Terms declared, no operation to raise one                          | Divergence classified, resolution undefined                         | Both          |
| Agent registry                   | Exists; no key transparency until 4.0                              | Trust rooted in a registry with no published spec                   |               |

Programmatic never standardised these five either: invalid traffic sat with MRC accreditation and the vendor layer, settlement sat in the insertion order, and a shortfall was argued out between two account teams. AdCP says so in the flattest sentence on its limitations page: "AdCP is the wire and the contract, not the ledger." Read that as a boast and it is half right. The wire is real; the contract it means is the deal terms a buy carries, not the counting authority, the verification vendor or the remedy for a shortfall. What changes is the human. An insertion order gets drafted because a person is about to press buy; an agent presses buy on its own schedule, so the clauses have to exist first.

Neither corpus names a deployment. The named, dated ones are in the deployments ledger; what the repositories tell you is the state of the parts those deployments are built on.

The last cell in the registry row is empty because no risk lands there on its own. The registry is the enforcement point for the other five. On the AAMP side trust status caps the access tier, which caps the price a buyer is allowed to see. On the AdCP side the registry binds a counterparty domain to a verification key. If the registry can be spoofed or mocked, every contractual control resting on it becomes advisory.

Where the published statements and the repositories disagree

| Published statement                                                                                                               | What the repository contains                                                                                                                                            |
| --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IAB Tech Lab, 30 July 2026: Agentic Audiences v1.0 is "ready for fully programmatic and agentic transactions"                     | specs/v1.0/schema/agentinterface.schema.json is 0 bytes on main, as are both example payloads and specs/roadmap.md                                               |
| known-limitations.mdx: "3.0 rejects authoritylevel: agentfull at the schema level" on three policy categories               | authoritylevel is not a field anywhere in dist/schemas/3.1.13/, so the rejection survives only in prose                                                            |
| Same file: pharmaceutical advertising "relies on the governance-agent implementation rather than a schema invariant"              | governance/sync-plans-request.json forces humanreviewrequired: true on four categories including pharmaceuticaladvertising, and again on euaiactannexiii |
| docs/faq.mdx line 165: AdCP's advertising scope is "Sponsored discovery, media buying, creative, brand governance, attribution" | Line 53 of the same file: "AdCP does not specify attribution or viewability." No published operation sits behind the measurement protocol                             |

Three of the four rows are AdCP against itself, and it goes stale in both directions. The non-goals page is stamped "AdCP 3.0" while the published release is 3.1.13. It describes a rejection mechanism that no longer ships and undersells the human-review invariant that does. Its FAQ claims a scope the same file denies a hundred lines earlier.

The AAMP row costs a buyer more, and it doesn't stand alone. What each of those repositories actually holds is the wider version of that one line.

Documentation lags schemas and announcements lead them, which is true of every standards organisation I have read. The prices differ. A stale non-goals page wastes an afternoon of your implementer's time; an announcement running a year ahead of an empty schema file can waste a slot on your roadmap.

Measurement: AdCP has opened a protocol with nothing in it

In 3.1.13, measurement is the seventh value in the supportedprotocols enum of get-adcp-capabilities-response.json, and no published operation sits behind it. The schema is candid about this: the protocol "is experimental in 3.1 and currently scoped to getadcpcapabilities catalog discovery," and "additional measurement tasks (reporting, attribution, etc.)... land in subsequent minors." So a seller can advertise a measurement protocol with no tasks in it, and a buyer's capability check will pass. The same repository's limitations page says AdCP "does not specify an attribution model." One of those two files has to give.

The non-goal undersells what AdCP actually carries. enums/attribution-methodology.json is a closed four-value vocabulary: deterministicpurchase, probabilistic, panelbased, modeled. Its description of modeled names Media Mix Modeling, Multi-Touch Attribution and incrementality testing outright. enums/available-metric.json carries 36 metrics, roas and incrementalsaleslift among them. So the wire transports attributed numbers and refuses to compute them, and the vocabulary exists to stop anyone summing a panel number with an MMM number, which is the right line to draw.

Nothing in iab-agentic-primitives/spec/jsonschema/ is a measurement, report or delivery object. The corpus has one delivery-performance endpoint, /api/v1/deals/{dealid}/performance on the seller agent, described in its own OpenAPI document as returning "placeholder/mock stats initially — real ad server integration comes in a future phase." agentic-audiences gets closer, listing measurement as a valid agentrole. The file that would carry that agent's request, specs/v1.0/schema/agentinterface.schema.json, is zero bytes on main.

Neither protocol detects invalid traffic

Both standardise the paperwork around detection and leave the detecting to the vendor layer, which AdCP names outright: GIVT/SIVT filtration, viewability and brand-safety verification "execute in the delivery stack or the chosen vendor layer (e.g., DoubleVerify, IAS, HUMAN)."

The asymmetry is in the paperwork. core/performance-standard.json binds a metric to a threshold and a named vendor, requires a standard whenever the metric is viewability, and adds a rule with teeth: "when specified on a confirmed package, creatives MUST include trackerscript or trackerpixel assets from this vendor." ivt is the only metric in it measured as a ceiling, and getproducts filters accept requiredperformancestandards, so the requirement travels with discovery. You can write verification into the deal. Measuring it is somebody else's job.

AAMP's wire prices viewability, bills on it and sets goals against it, and can't say who measured any of it. cpmv is a pricing model across its schemas, and Proposal.json carries viewableimpressions as a GoalType and viewableimpression as a BillableEvent. That is worse than having only a price, because a goal type invites a commitment nothing in the corpus can adjudicate. ARTF, the agentic-rtb-framework repository and AAMP's in-auction agent layer, goes further. ADDMETRICS = 7 in its protobuf lets an in-path agent write OpenRTB Metric objects into a bid request, and Metric.type is "exchange curated string names," an open string curated by whoever runs the exchange. AAMP's first measurement primitive is a mechanism for injecting unattested viewability numbers into a live auction.

The money never touches the wire

An agent can commit a budget over the protocol and there is no protocol underneath the money, so the finance half of an agentic buy stays manual on both stacks.

AdCP's "Commerce and settlement" section is three bullets long. Two of them: no in-protocol payment, because "reportusage provides the consumption data that feeds invoicing" and everything after that happens out-of-band; and one ISO 4217 currency per buy, so "the buy either uses a matching currency or is rejected." No operation in the registry is named for an invoice, a payment or a settlement. getaccountfinancials, which sounds like it might help, guarantees "only account, currency, and period" on success.

AAMP models money better at the primitive level and not at all at the process level. FD-11, one of the numbered flagged decisions the primitives repository uses to record a binding choice, requires integer micros and rejects float-typed money on the wire, which is a better default than AdCP's. RateCard is then the only money primitive in the corpus: no Invoice, no Usage, no Payment.

A publisher reading this should notice which way the absence cuts. AAMP makes the seller's count authoritative when the two sides diverge, and AdCP has the seller proposing the remedy from an agreed menu, so an unspecified settlement path leaves the party that already holds the numbers holding them. Neither body wants to be in payments and neither should be, but the cost of that decision lands on a finance team rather than on a standards body. The wire trace shows where the automation stops and accounts payable picks it up.

No identity crosses between the stacks, or inside AAMP

AAMP carries three identities and no file maps any one onto another. There is an audience-side identity, {namespace, valuehash, confidence} inside an agentic-audiences embedding envelope. There is a bidstream identity, ADDCIDS = 8 in ARTF, which injects extended content identifiers into a bid request. And there is an account identity, BuyerIdentity in the control plane, optional fields running from seatid to campaignname, whose docstring says what AAMP thinks identity is for: "buyer identity revealed progressively to unlock better pricing." An organisation is being described there, not a person.

AdCP keeps identity opaque and enforces it structurally rather than by policy: identity-match-request.json returns eligiblepackageids and a servewindowsec and carries no page context, while contextmatch carries page context and no identity. syncaudiences takes hashedemail and hashedphone, SHA-256 only. Then known-limitations.mdx narrows its own claim twice, in a lawyer's language rather than a spec author's: "AdCP authenticates agents, not the humans they act for," and "SHA-256 hashes of email and phone remain pseudonymous identifiers under GDPR and CPRA."

Across the two stacks there is nothing at all, which follows from the finding underneath the whole protocol comparison. Hold one audience definition for both sides and you translate it by hand, every time, with nothing published to check it against.

The dispute flow both stacks describe and neither ships

You pick up the phone. AdCP's schemas describe the whole dispute and implement none of it.

core/measurement-terms.json hands you the vocabulary. billingmeasurement.vendor is the party "whose measurement of the billing metric is authoritative for invoicing." maxvariancepercent is the divergence between the two parties' counts "before resolution is triggered." makegoodpolicy reads: "when a breach occurs, the seller proposes a remedy from this menu; the buyer accepts or disputes." Then it stops. The schema tells two autonomous agents the exact percentage at which they should disagree and ships no message for the disagreement: "No protocol-level delivery-dispute flow... A structured dispute task is a candidate for future work."

AAMP has the state machine AdCP lacks and stops one step earlier. state/Reconciliation.json encodes FD-8 as a full state-pair table across change requests, deals and orders, classifying every pair as consistent, buyerbehind, sellerbehind or divergent, with the seller authoritative and the policy stated outright: "divergence is reported, not silently resolved." AdCP has no equivalent. What happens after divergent is undefined, and the word "dispute" survives in AAMP only as prose inside the two agent implementations, never in the shared wire contract. Whatever either body means by autonomous buying, it stops at the first disagreement.

Can either registry be trusted with autonomous spend?

Agent.json is emphatic about trust. It defines TrustStatus — unknown, registered, approved, preferred, blocked — as "verified against the AAMP registry... never self-asserted." The same repository's STANDARDSGAPREPORT.md files that registry as UNVERIFIED: "No check against the AAMP registry specification... truststatus semantics are asserted by our own spec, not against AAMP publications." The canonical wire contract cannot verify the registry its own trust model is rooted in.

Downstream, the reference implementation is blunter than its documentation: the default AAMPRegistryClient says verifyregistration() and lookupagent() "return realistic mock data", and the real client only runs when an environment variable points it somewhere. The mock is the default, so five graded trust levels collapse into whatever list the operator keeps locally. The discovery guide has the registry hostnames and what each one answers.

AdCP's registry works, and its own limitations page tells you how to defeat it. There is no enrollment ceremony binding a domain to a root verification key and no append-only rotation record, so "an attacker who controls a counterparty's CDN, DNS, or /.well-known path can serve attacker-controlled keys." Trust-on-first-use with continuity is the mitigation, "detectably raising the bar, but not cryptographically closing the gap," and the full fix is a 4.0 deliverable. So the answer is no, in two different ways: underwrite autonomous spend against either registry and your control is a domain takeover away in one case and an operator's local list in the other.

AdCP's strongest control is the one you have to volunteer for

AdCP's governance protocol is the largest area in the registry, and it holds AdCP's only human-review rules that a schema enforces rather than a policy document requests. governance/sync-plans-request.json sets humanreviewrequired to a constant true when a plan declares fair housing, fair lending, fair employment or pharmaceutical advertising, and again when it declares euaiactannexiii.

Then checkgovernance validates against a planid. An implementer who never calls syncplans has no plan to check against, so the invariants never fire and nothing in the protocol notices. The rule that could stop an agent buying fair-housing inventory with no human in the loop only fires if you opt in, and anything you opt into is a feature.

The five clauses you write yourself

One per gap, and nobody writes them for you.

1. Name the counting authority and the tolerance. billingmeasurement.vendor and maxvariancepercent put both on the wire; the remedy for a breach is yours to draft, because no schema in either corpus carries one.
2. Name your verification vendor and its thresholds. core/performance-standard.json carries the metric, threshold, standard and vendor once you have agreed them, and agreeing them is contract work.
3. State the settlement mechanism and the currency. One ISO 4217 currency per buy or the buy is rejected, and everything downstream of reportusage leaves the wire.
4. Put a name on the audience crosswalk. One person owns the mapping between an AAMP {namespace, valuehash, confidence} identity and the SHA-256 hashes syncaudiences accepts, in writing, because nobody else publishes it.
5. Attach a phone number to divergent. Reconciliation.json will tell you the two agents disagree and will not tell you who to call.

All five are per-counterparty. Ten partners is ten sets of clauses, and no schema release reduces that number.

Each gap closes as a file changing, not as an announcement

| Gap                  | What has to change                                                             | Where you would see it                                                               |
| -------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
| Measurement          | A task appears under the measurement protocol AdCP has already declared      | The current release's index.json                                                   |
| Verification         | A wire attestation replaces contract terms                                     | core/performance-standard.json, or a new AAMP primitive that names a measurer      |
| Settlement           | An invoice or payment object, or an explicit handoff to a commerce protocol    | AdCP's "Commerce and settlement" bullets; iab-agentic-primitives/spec/jsonschema/  |
| Cross-stack identity | Either corpus admits the other exists                                          | The first mention of AdCP anywhere in the eight IAB repositories                     |
| Disputes             | AdCP's promised dispute task, or an AAMP policy for what follows divergent   | known-limitations.mdx; state/Reconciliation.json                                 |
| Registry             | Key transparency lands in AdCP 4.0; IAB publishes a registry API specification | AdCP release notes; AAMPRegistryClient in seller-agent stops returning mock data |

One of those you can delegate today. Ask any vendor selling you AAMP measurement to show you a non-empty agentinterface.schema.json on main in agentic-audiences. Until they can, AAMP has no measurement agent that talks to the rest of the corpus, whatever the press release says.

And whichever stack you sign for, require plan registration: syncplans before checkgovernance, or the human-review invariants are decoration your counterparty can skip.

---