# Ad Tech Glossary — full text corpus

> Plain-language definitions for the vocabulary of agentic and programmatic advertising.

Generated 2026-08-13. 36 documents.

---

# AAMP

Source: https://adtechglossary.com/concepts/aamp/

AAMP is IAB Tech Lab's umbrella label for nine separately versioned agentic advertising repositories, spanning a control plane, a bidstream mutation framework and an embedding exchange. It has no version: each repository tags independently.

AAMP is IAB Tech Lab's umbrella label over nine separately versioned repositories of agentic advertising work. The repositories describe one media transaction carried out machine to machine: a buyer's agent finds a seller, asks what inventory is available (avails), negotiates a quote across several rounds and books the deal.

The control plane — everything that happens before a campaign runs: discovery, negotiation and booking — is defined by the wire contract in iab-agentic-primitives and implemented by the reference agents and the OpenDirect wrapper that speak it. ARTF is the bidstream mutation framework, the one part that runs at serve time. agentic-audiences is the embedding exchange.

The hub repository, github.com/IABTechLab/AAMP, holds a README and a licence file, and that README carries the release model: "Each repository uses independent semantic versioning." There is no AAMP version number, so a dependency declaration names one repository at a tag and the others move on their own schedule.

The hub expands the acronym as Agentic Advertising Management Protocols. Three other expansions appear inside the corpus, including in the wire contract both reference agents import; AAMP Explorer has the file and line for each.

Nine repositories carry the label

Nine repositories carry the label: the hub, the six the hub lists, and two named only in the code or on the standards page. Supporting AAMP means a different thing in each one.

| Repository                     | What it publishes                                                                                                                           | What supporting it means                                                                                 | On the hub README?                      |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------- |
| AAMP                         | The umbrella README and a licence                                                                                                           | Nothing to implement                                                                                     | it is the hub                           |
| iab-agentic-primitives       | 48 JSON Schemas and a 13-operation OpenAPI, the wire contract both agents import                                                            | Speaking the buyer-to-seller wire contract, at v0.5.0, unreleased                                        | no                                  |
| seller-agent                 | Supply-side reference implementation; 74 OpenAPI paths, 87 operations                                                                       | Answering for a publisher: avails, quotes, negotiation, booking                                          | yes                                     |
| buyer-agent                  | Demand-side reference implementation, Python                                                                                                | Running the same control plane from the demand side                                                      | yes                                     |
| agentic-direct               | MCP/A2A wrapper over OpenDirect 2.1; handlers call generateMockResponse                                                                   | Booking against OpenDirect 2.1 over MCP, A2A and REST | yes                                     |
| agentic-rtb-framework (ARTF) | The released v1.0 specification and a protobuf contract                                                                                     | Changing a bid at serve time: ARTF v1.0, protobuf, one entry point                                       | yes, under its old name                 |
| agentic-audiences            | Draft v0.1 embedding exchange from LiveRamp, filed under specs/v1.0/, where specs/v1.0/schema/agentinterface.schema.json is zero bytes | Exchanging audience embeddings                                                                           | yes                                     |
| registry-agent-example       | Example client that registers an agent and verifies it                                                                                      | Registering and verifying an agent against an API with no published specification                        | yes                                     |
| agentic-mobile               | spec v1.0.0-draft over MCP and A2A, untagged                                                                                              | Mobile in-app workflows                                                                                  | no, but named on the standards page |

ARTF v1.0 was released on 12 November 2025 as a Tech Lab standard, and it is the only ratified standard among the repositories with published code. The rest publish drafts or reference implementations; agentic-direct's MCP handlers call generateMockResponse. No repository records a production adopter. ARTF's contributor list names Index Exchange, The Trade Desk, OpenX and Chalice, and agentic-audiences arrived as LiveRamp's proposal.

Those repositories publish 143 operations. One runs at serve time, GetMutations in ARTF; the other 142 sit in the control plane: discovery, avails, quotes, multi-round negotiation and deal booking. AdCP's FAQ characterises AAMP as agentic bidding.

The official lists and the code name different repositories

The standards page names Agentic Mobile, Agentic Ad Object and Agentic Guardrails. Two of those three have no public repository: IABTechLab/agentic-ad-object and IABTechLab/agentic-guardrails return 404 on GitHub, and neither string appears in the published code. Agentic Mobile is real and public, since 18 November 2025, and the hub README does not mention it.

seller-agent/pyproject.toml and buyer-agent/pyproject.toml share a line.

Both reference agents hard-pin iab-agentic-primitives at an exact tag, and it appears on neither official list. Its own README states that it is unreleased, unstable and subject to change without notice.

The hub README has not been edited since 16 April 2026, and the two agents it lists have since diverged: seller-agent v2.4.1 landed on 5 August, and buyer-agent's newest tag is v2.3.0 from 22 July. The version matrix tracks the drift.

The agent registry has no published specification behind it either. Seller-agent v2.4.1 ships two registry clients: AampApiRegistryClient, which talks to a live IAB registry over Bearer JWT when AAMPREGISTRYURL is set, and a legacy stub, "stubbed pending the public AAMP API specification", which is what an unconfigured deployment gets.

Terms taken from AAMP — quote, negotiation round, trust status — describe how IAB Tech Lab's own agents behave at a tag, and any of them can change on the next minor without deprecation.

AdCP is the other stack rather than a counterpart to the umbrella: one repository, one stable release, 64 registered operations. AAMP is a label over repositories that share no type with each other, so there is nothing to line up at the umbrella level. AdCP's FAQ names AAMP, and no file published under AAMP names AdCP; object by object the comparison is tractable, which is what the terminology lookup does.

Repository-by-repository detail is in AAMP Explorer. Related terms: quote, deal, agent registry, OpenDirect 2.1, ARTF intent.

---

# Access Tier

Source: https://adtechglossary.com/negotiation/access-tier/

Access Tier is AAMP's four-value enum (public, seat, agency, advertiser) that gates what price, negotiation and availability detail a buyer agent gets. It travels as buyer_tier, is capped server-side by the calling agent's trust status, and is never self-asserted.

Access Tier is AAMP's four-value string enum for what a buyer agent is allowed to see and pay. On the wire it is buyertier, carried on the Quote, Deal and Negotiation objects and glossed "Access tier for tiered pricing, derived from revealed buyer identity".

| Value (schema) | Identity revealed       | What the schema says                            |
| -------------- | ----------------------- | ----------------------------------------------- |
| public       | None                    | "no identity — price ranges only"               |
| seat         | DSP seat, authenticated | "authenticated DSP (demand-side platform) seat" |
| agency       | Agency                  | "agency identity revealed"                      |
| advertiser   | Advertiser              | "advertiser identity revealed (best rates)"     |

All three objects declare it identically: {"$ref": "#/$defs/AccessTier", "default": "public"}. A buyer that sends no identity is priced at the public tier rather than rejected.

The schema derives the tier from revealed buyer identity. In the reference implementations the seller's API key fixes it instead, and an identity sent in the payload can only confirm what the key already allows.

The repository that defines it is unreleased and warns that its schemas will change without notice. There is no canonical AccessTier.json: the same block is copied into five schema files, and the two reference agents no longer derive the tier the same way.

Entitlements at each tier

Pricing visibility, negotiation and availability detail all move together. The discounts below are the reference seller agent's defaulttiers() fallback, which an operator overrides, rather than a published rate.

| Tier         | Pricing visibility         | Negotiation | Default discount | Avails granularity |
| ------------ | -------------------------- | ----------- | ---------------- | ------------------ |
| public     | Price ranges only          | No          | 0%               | highlevel       |
| seat       | Exact prices, no discounts | Limited     | 5%               | moderate         |
| agency     | Tier discounts applied     | Standard    | 10%              | detailed         |
| advertiser | Full discounts plus volume | Premium     | 15%              | detailed         |

The reference seller agent also maps the effective tier to a named negotiation strategy, with three hard limits and one behavioural parameter. These are that agent's defaults, not protocol.

| Tier         | Strategy        | Max rounds | Per-round cap | Cumulative cap | Buyer gap share |
| ------------ | --------------- | ---------- | ------------- | -------------- | --------------- |
| public     | aggressive    | 3          | 3%            | 8%             | 30%             |
| seat       | standard      | 4          | 4%            | 12%            | 40%             |
| agency     | collaborative | 5          | 5%            | 15%            | 50%             |
| advertiser | premium       | 6          | 6%            | 20%            | 65%             |

Buyer gap share, gapsplitbuyershare on the wire, rises with the tier: at advertiser the seller expects the buyer to close 65 percent of the remaining gap, alongside the widest concession budget. docs/integration/negotiation.md glosses the field as "How much of the price gap the seller expects the buyer to close (higher = more favorable to seller)". The worked example is on AAMP Explorer; the round record is a Negotiation Round.

The tier also controls how much availability detail a caller sees, which the tier documentation does not cover. A public caller is told a product is Available, a seat caller that availability is High, and agency and advertiser callers get numbers: estimatedmonthlyimpressions of 10M-50M, a fillrate of 85-95%.

The default rate card sets negotiationenabled=False for public and seat, and the seller's negotiation engine never reads the flag.

What sets the tier

BuyerIdentity has eleven properties and no required array, so an empty BuyerIdentity {} validates. Only seatid, agencyid and advertiserid change the tier; neither reference implementation branches on dspplatform, advertisername or the campaign fields.

A brand buying direct, with no agency and no seat, computes advertiser on its own agent while the seller walks the same identity down to ANONYMOUS and quotes a range. Neither agent raises an error, and the buyer is quoted at the lower tier. The two agents disagree about how many IDs the top tier needs: the seller requires both an advertiser ID and an agency ID, and its identitylevel reaches AGENCYANDADVERTISER only when both are present, while the buyer treats an advertiser ID alone as enough. The buyer's model carries the seller's rule as a comment, # Agency + Advertiser - 15% discount, and does not implement it.

The revelation mechanism the buyer's documentation describes is not wired up. toheaderdict() builds X-DSP-Seat-ID, X-Agency-ID and X-Advertiser-ID, no code in the repository calls it, and the seller reads only Authorization and X-Api-Key. docs/api/authentication.md states the arithmetic: "The effective tier is the minimum of the API key tier and the agent trust tier. A preferred agent with a seat-level API key gets seat access." A BuyerIdentity sent afterwards cannot raise the tier above what the key allows. The ceiling side of that minimum is Trust Status.

The schema states that the tier is "capped server-side by the registry-verified trust status of the calling agent — it is never self-asserted", over the order public < seat < agency < advertiser. Quotes, deals and negotiation all go through verifiedbuyercontext, which floors the effective tier to public when the claim is unverifiable.

One discovery endpoint in the reference seller agent does not apply that cap. POST /media-kit/search bypasses verifiedbuyercontext, builds a buyer context whenever apikeyrecord is not None or request.buyertier != "public", and leaves maxaccesstier unset, so an unauthenticated caller claiming advertiser is answered at that tier: exactprice at the top-tier discount, floorprice, placements, audience segment IDs and negotiationenabled: true. It is a defect in that repository rather than a reading of the schema.

Access tier in AdCP

AdCP 3.1.13 defines no access tier, and no tier, accesstier, buyertier or accounttier property in dist/schemas/3.1.13/. The relationship is modelled under another name: core/account.json describes "the relationship between a buyer and seller", an account that "determines rate cards, payment terms, and billing entity", and its ratecard is {"type": "string"}, so the rate card is named and its contents are left to the parties. Capability lives in core/account-authorization.json, an allowlist of task names in allowedtasks[] plus fieldscopes and readonly.

AdCP's accountscope is also a four-value enum on the buyer relationship — operator, brand, operatorbrand, agent — but its values are categories, not levels, so they do not compose into a ceiling. The rest of that shape difference is in the protocol comparison.

---

# Signal Activation

Source: https://adtechglossary.com/signals/activation/

Signal activation is the AdCP call that makes a discovered signal usable on a named destination, taking a segment handle and a list of destinations and returning an activation key once the deployment is live.

Signal activation is the AdCP call that makes a discovered signal usable on a named destination. AdCP's glossary puts it as "the process of making a signal available for targeting on a specific platform and seat". The Signals area has two operations: getsignals reports that a signal exists and returns a handle, and activatesignal turns that handle into something a DSP will accept.

Destination, Deployment, and the activation key

Destination and Deployment are discriminated unions on type with the same two branches: a platform names a DSP by string identifier (the-trade-desk, amazon-dsp), an agent names one by URL. Deployment adds islive, activationkey, estimatedactivationdurationminutes and deployedat. All four — both Destination branches and both Deployment branches — allow additional properties.

activation-key.json calls the key a "universal identifier for using a signal on a destination platform", arriving as type: segmentid or type: keyvalue, because AdCP does not normalise how platforms express targeting.

The visibility rule sits on both Deployment branches: "The key to use for targeting. Only present if islive=true AND requester has access to this deployment." The field is simply absent, so the caller cannot distinguish "not live yet" from "not yours".

estimatedactivationdurationminutes is the only clock the protocol offers, and activation is asynchronous rather than immediate: the glossary's "Estimated Activation Time" entry describes "typically 24-48 hours for new activations", which is 1,440 to 2,880 in the field's unit. Deployments also arrive with neither a key nor an estimate, and the schema says nothing about the interval there.

What an activatesignal request requires

activate-signal-request.json lists exactly ["idempotencykey", "signalagentsegmentid", "destinations"] in required. Two further fields are required by conditions written in field descriptions that nothing in the file can check: no if/then, no dependentRequired, and the only oneOf is the version envelope the request inherits.

| Tier                                  | Fields                                                                                                                             |
| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Enforced by required[]              | idempotencykey, signalagentsegmentid, destinations (minItems: 1)                                                       |
| Required by a sentence, unenforceable | pricingoptionid, when the signal has pricing options; governancecontext, when the account has a registered governance agent |

That leaves action, account, context and ext optional. action defaults to activate. Its other value, deactivate, exists because ending a campaign requires the segment to be torn down: the schema gives the reason as "required when campaigns end to comply with data governance policies (GDPR, CCPA)".

Both conditional fields are stated in prose and enforced nowhere. governancecontext carries the description "signal agents MUST reject governed activations that omit a valid context", and pricingoptionid is required when the getsignals response carried pricingoptions "when it has an incremental price"; in both cases the request schema constrains the value once it appears and says nothing about whether it was sent. Omitted on a priced signal, the seller has to catch it, with INVALIDPRICINGMODEL per the task page, a code that is not in the released enum.

Reusing one idempotencykey across two sellers hands both of them a join key, so the schema requires it to be unique per (seller, request) pair "to prevent cross-seller correlation".

Partial failure

activate-signal-response.json: "Returns either complete success data OR error information, never both. This enforces atomic operation semantics - the signal is either fully activated or not activated at all."

The oneOf enforces it: the success branch requires deployments and adds not: {required: ["errors"]}, the error branch requires errors with minItems: 1 and excludes both deployments and sandbox. A payload carrying both matches neither branch.

Only one destination per call keeps the error branch usable. A call with three destinations and one hard failure has no representation: reporting the failure loses the two successes, and reporting the successes leaves the failure with no reason attached. The only way out is islive: false on the failed deployment inside a success response, which carries no error code and no recovery classification, and core/error.json has no destination pointer to scope an error to one entry of destinations[].

Documentation and schema divergence

docs/signals/tasks/activatesignal.mdx describes the operation in terms the released schemas do not support. It reads as though five fields are required where required[] names three. Its "Response Data" section shows one object carrying both deployments[] and errors[], and its "Error Handling Philosophy" says a signal "can be deployed while still having warnings in errors array", where the oneOf forbids both shapes; only its <Note that the two are "mutually exclusive" matches the schema. It names error codes — ACTIVATIONFAILED, ALREADYACTIVATED, DEPLOYMENTUNAUTHORIZED, INVALIDPRICINGMODEL, SUBOPTIMALCONFIGURATION, SLOWACTIVATION, FREQUENCYCAPRESTRICTIVE — that enums/error-code.json does not carry, and task statuses deployed, pending and processing that enums/task-status.json does not carry. On key visibility it states only the access half of the rule. Implement against the schemas; the field-level comparison is on AdCP Explorer.

Codes outside the enum are still conformant: the enum's description lets sellers "return codes not listed here" and tells agents to fall back "to the recovery classification". No recovery class is published for the codes the task page names, so the fallback has nothing to read. Task status does not report liveness either: a completed task can carry a deployment with islive: false.

Segment identifiers

signalagentsegmentid addresses the signal at the signal agent, and activationkey.segmentid addresses it at the platform. One goes out on the request, the other comes back on the response, and neither substitutes for the other. AdCP's glossary entry for Segment ID names both without distinguishing them.

No released schema in 3.1.13 contains the string seat. docs/reference/glossary.mdx defines it anyway, as "a specific advertising account within a decisioning platform", and that same page scopes two error codes as "platform/seat" where the task page says "platform/account". The field carrying the meaning on the wire is account, the optional string on both destination branches. No spec file connects seat to account.

Activation in AAMP

AAMP defines no equivalent provisioning operation.

ARTF's protobuf Intent enum has ACTIVATESEGMENTS = 1, "activate user segments by their external segment IDs". That is a serve-time mutation at /user/data/segment on a bid request already in flight, rejectable by the orchestrator and dead when the auction closes, where AdCP activation is planning-time provisioning that yields a durable key. The nearest wire-level counterpart, POST /agentic-audience/match in the seller agent, scores a match STRONG | MODERATE | WEAK | POOR and calls its own score "mock-quality (deterministic from sha256 of identifier)".

Deal.activationinstructions, an untyped string map carrying no description, is the only field named for activation in iab-agentic-primitives v0.5.0. AdCP's destination object, deployment status and deactivate verb have no counterpart there.

---

# Ad Context Protocol

Source: https://adtechglossary.com/concepts/adcp/

AdCP (Ad Context Protocol) is an open advertising standard from AgenticAdvertising.org whose stable 3.1.13 release registers 64 operations across ten schema groups, carried over MCP and A2A at planning time and plain HTTP at serve time.

AdCP, the Ad Context Protocol, is an open advertising standard published by AgenticAdvertising.org: a vocabulary of tasks a buyer's agent calls on a seller's agent to buy media. On the sell side, a sales agent is an MCP (Model Context Protocol) server exposing a publisher's inventory. The buy side is what AdCP calls an orchestrator: a client that calls sales agent tasks and exposes no server of its own.

The whole standard is one GitHub repository: a versioned JSON Schema registry and a documentation site, licensed Apache 2.0. CHARTER.md calls AgenticAdvertising.org "a pending 501(c)(6) nonprofit trade association incorporated in Delaware", and the FAQ states the relationship with the other standards body directly: "AdCP is maintained by AgenticAdvertising.org (AAO), an independent specification body — not a subsidiary or working group of IAB Tech Lab".

The README names the normative surface: "The schemas in static/schemas/source/ and the protocol documents in docs/ define the normative AdCP contract." The acronym is expanded both ways inside that repository: docs/ and the glossary say Ad Context Protocol, while the README's first line, CHARTER.md, governance/membership-agreement.md and the 2.0.0 release-notes entry say Advertising Context Protocol. AAMP's acronym has four expansions in circulation.

AdCP 3.1.13 registers 64 operations

One media buy is getproducts to find inventory, createmediabuy to book it, synccreatives if the seller hosts the creative library, then getmediabuydelivery to read back what ran. All but the creative step are Required for a Media Buy sales agent in docs/protocol/required-tasks.mdx. The other 60 operations sit around that spine, registered in dist/schemas/3.1.13/index.json across ten schema groups.

| Schema group           | Operations in 3.1.13 | What the group covers                                                                        |
| ---------------------- | -------------------- | -------------------------------------------------------------------------------------------- |
| Governance             | 22                   | Property governance, brand and content standards, and the checks run against them            |
| Media Buy              | 11                   | Finding, booking and reporting on inventory, getproducts through getmediabuydelivery |
| Creative               | 8                    | Building, previewing and syncing creative, and the formats it is built to                    |
| Brand Protocol         | 6                    | Brand identity retrieval, rights discovery, acquisition and lifecycle                        |
| Accounts               | 5                    | Account listing, usage reporting and account financials                                      |
| Sponsored Intelligence | 4                    | Conversational brand experiences inside AI assistants                                        |
| Protocol (shared)      | 3                    | Tasks common to every role: getadcpcapabilities, gettaskstatus, listtasks         |
| Signals                | 2                    | getsignals and activatesignal                                                          |
| Trusted Match          | 2                    | Serve-time activation of pre-negotiated packages: contextmatch, identitymatch          |
| Compliance             | 1                    | The compliance testing tool, complytestcontroller                                        |

Governance is a third of the surface on its own. Fourteen of its 22 operations are create, update, get, list and delete over three objects — property lists, collection lists and content standards, which has no delete. The other eight calibrate content against a standard, check a plan against governance, validate what actually delivered, and pull the plan audit log.

AdCP launched as three protocols: Signals Activation, Curation and Media Buy. Signals Activation and Media Buy shipped, Curation is still a README row reading "Coming soon", and the two groups that landed instead, Sponsored Intelligence and Governance, were not on the original list.

The groups split across two protocol layers, and the reason is latency: "Planning-time tasks use MCP and A2A transports; serve-time decisions use the Trusted Match HTTP profile where the latency budget is impression-time" (README.md). Seven groups sit in the negotiation layer, over MCP or A2A, the two agent transports AdCP runs on; Trusted Match is alone on the serving side, on plain HTTP. The whole surface, operation by operation, is at AdCP Explorer.

The documentation site renders from unreleased main, so it also describes syncagentnotificationconfigs as a shared conditional task for every agent role. No release registers that operation.

One file carries the version

dist/schemas/latest.json names the published release, 3.1.13. Three other surfaces in the same repository state a version, and each states a different one.

| Surface                            | Version stated | Status                                                               |
| ---------------------------------- | -------------- | -------------------------------------------------------------------- |
| dist/schemas/latest.json         | 3.1.13         | The published stable release                                         |
| docs/reference/versions.mdx      | 3.1.12         | The "which version should I use" page, one patch behind the registry |
| static/schemas/source/index.json | 3.1.1          | Unreleased main; the source stamp moves only when a release is cut |
| Wire field adcpversion          | "3.1"        | Release precision. Patches are never negotiated                      |

3.1.3 shipped on 13 July 2026 and is marked "Do not use" for adding a stable schema field in a patch. Its artifacts stay downloadable for auditability, so a version directory existing in the registry does not mean that release is safe to build against.

What a "3.1" pin does against a seller that speaks only 3.0 is stated two incompatible ways inside one file, docs/reference/versioning.mdx. One passage has the client fail with VERSIONUNSUPPORTED. The negotiation algorithm earlier in the same file downshifts to the highest supported release at or below the pin, which for a 3.0-only seller means serving 3.0 and proceeding. core/version-envelope.json sides with the downshift; getadcpcapabilities has the argument in full.

Proposals and insertion orders, and no deal object

What a buyer actually handles is a proposal and, if the buy is signed, an insertion order. core/proposal.json is "a proposed media plan with budget allocations" whose committed form executes via createmediabuy, and core/insertion-order.json is "a signing wrapper attached to a committed proposal" that "does not introduce new deal terms". A proposal is accepted or refused rather than negotiated: price does not move across rounds, and a price that does move before signature is settled out of band.

The 3.1.13 release contains no deal, quote or negotiation object — no schema file and no property name. The word deal appears only as prose inside schema descriptions and as one value of enums/response-type.json, where it is one of four things a publisher can ask a Trusted Match context match to return. Multi-round price movement is an AAMP behaviour, and even there it is reference-implementation behaviour with no ratified spec, which is why deal and quote differ by stack.

What AdCP is often confused with

Two protocols are frequently confused with AdCP and operate one layer below it. ACP is OpenAI and Stripe's Agentic Commerce Protocol; UCP is Google's Universal Commerce Protocol, built with Shopify, Walmart and Target. Both standardise checkout rather than media, and AdCP's FAQ classifies them as commerce protocols. AdCP also declines to replace the files a publisher already serves: adagents.json "extends the ads.txt/sellers.json relationship semantics rather than replacing them" (see discovery files).

AAMP is the other stack rather than another layer. Term-by-term mapping, and which way the citation between the two runs, is on the terminology lookup; the architectural comparison is at Agentic Ad Lab.

Related terms: AAMP, MCP and A2A, Sponsored Intelligence, Trusted Match Protocol, deal.

---

# AdCP to AAMP terminology map

Source: https://adtechglossary.com/concepts/adcp-vs-aamp-terminology/

The AdCP to AAMP terminology map pairs the vocabularies of the two agentic advertising standards term by term, showing which words translate between them. Of the eight words both stacks use, only Product and Account mean the same thing in each.

The AdCP to AAMP terminology map is a term-by-term correspondence between the two agentic advertising vocabularies. Eight words appear in both. Two mean the same thing, four mean something different in each stack, and two exist as objects on only one side. Each row cites the schema file it comes from.

AdCP terms come from the stable 3.1.13 release; the AAMP terms come mostly from iab-agentic-primitives v0.5.0, the wire contract both agent repositories pin and which its own front page states is not released. Neither corpus mentions the other, so no equivalence here has been agreed by either body. The nearest thing to an official comparison is a six-row table in AdCP's FAQ headed "As of April 2026", which calls AdCP "3.0 GA" while the schema registry publishes 3.1.13 and describes AAMP's public schemas as "being defined" against 48 published JSON Schemas. No AAMP document describes AdCP.

Four shared words that mean different things

| Term                              | In AdCP 3.1.13                                                                            | In AAMP                                                                | What breaks if they are mapped                                                                                         |
| --------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Package | "A specific product within a media buy (line item)"                                       | "Curated inventory package for media kit discovery"                    | AdCP's Package sits inside a buy that already exists. AAMP's is a bundle advertised before anyone has bought anything. |
| Proposal                          | The publisher's strategic recommendation; a committed one executes via createmediabuy | The buyer's offer under negotiation, proposalid seller-issued       | The publisher writes one and the buyer writes the other, so the write path inverts.                                    |
| Agent           | "The authenticated entity making API calls", identified by the auth token                 | An A2A card plus a registry identity record                            | AdCP's Agent is whoever holds the token. AAMP's is a document published in advance.                                    |
| Rate card                         | ratecard on core/account.json, an opaque identifier with no schema behind it         | RateCard.json, a full object, "private to the pair ... NEVER public" | Only AAMP defines what is inside one, and then forbids publishing it.                                                  |

getproducts returns "products with pricing specific to this account's rate card", so AdCP has rate cards without ever saying what is in one.

Objects that map by function rather than by name

| AdCP                                         | AAMP                                       | Reading                                                                                                                                                                                                |
| -------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Media buy, core/media-buy.json             | Order, Order.json                        | The campaign container. AAMP merges the buyer's OpenDirect Order into the seller's ExecutionOrder and the seller's record is authoritative, so after a change request the buyer's copy is a cache. |
| Package, core/package.json                 | Line, Line.json                          | Line.json states that "Line is the only execution unit on the wire".                                                                                                                               |
| Product            | Product, Product.json                    | "Represents available advertising inventory" against "Sellable unit of publisher inventory".                                                                                                           |
| Account, core/account.json                 | Account, Account.json                    | AdCP's "determines rate cards, payment terms, and billing entity"; AAMP's does the same job.                                                                                                           |
| Natural-language brief on getproducts   | Media kit, MediaKit.json                 | A prose brief against a catalogue with tier-gated views: public ranges, exact pricing once the caller authenticates.                                                                                   |
| Creative manifest, 13 canonical format kinds | Creative, Creative.json, plus Assignment | AAMP's is "Metadata only — never executable markup". Twelve of AdCP's 13 kinds have a schema under formats/canonical/; custom does not.                                                            |

They line up this well because AAMP's direct-buying model came from OpenDirect: agentic-direct ships opendirect.json at version 2.1.0, and Order.json describes the AAMP order as a container that "merges the buyer's OpenDirect Order with the seller's ExecutionOrder". Media buy to Order and Package to Line hold up once the seller's record is accepted as authoritative, which Order.json states explicitly. The brief-to-media-kit row is the exception: a prose brief and a tier-gated catalogue answer different questions.

Agent and seller roles do not line up

| AdCP                                | AAMP                                  | Notes                                                                                                                                |
| ----------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Sales agent | Seller agent | AdCP's is "An MCP server that exposes publisher inventory for discovery and purchase". The phrase "sales agent" is absent from AAMP. |
| Seller (the role)                   | Seller agent                          | AdCP keeps the commercial role and the software apart. AAMP does not.                                                                |
| Orchestrator                        | Buyer agent   | protocol/required-tasks.mdx: "Orchestrators are not MCP/A2A servers — they call sales agent tasks."                                |

Two of those rows are renamings and survive an integration untouched: sales agent to seller agent, orchestrator to buyer agent. The third is not. AdCP's seller is the commercial party and its sales agent is the MCP server answering on that party's behalf. AAMP mints one agentid per agent, hangs trust status off it, and the endpoint becomes the identity, so one seller agent fronting two publishers books both publishers' inventory under a single identity. AAMP publishes no field binding an agentid to a commercial party.

The registry that mints every AAMP agentid has one published implementation, an eight-file example repository, and no conformance suite runs anywhere in the corpus. AdCP publishes a numbered stable release and a compliance runner that reports a pass or a fail.

Terms with no counterpart

Eleven concepts exist in AdCP with nothing to map onto in AAMP:

- Signal agent
- Brand agent
- Governance agent, 22 operations
- adagents.json and brand.json
- Specialism, plus a compliance runner that executes storyboards
- Signal definition and signalref
- Audience, hashed identifiers, syncaudiences
- Policy categories, a ten-value enum
- Sponsored Intelligence, 4 operations
- Nine -option.json pricing models under pricing-options/
- AXE, deprecated in AdCP's first year and replaced by Trusted Match

Ten exist in AAMP with nothing to map onto in AdCP:

- Registry-registered agent, agentid minted at registration
- Media kit, MediaKit.json, tier-gated catalogue
- Quote, Quote.json, non-binding, carries expiresat
- Negotiation: accept, counter, finaloffer, reject, with a round counter
- Deal, Deal.json, dealid seller-issued
- Access tier and trust status
- ChangeRequest.json, post-booking change with its own lifecycle
- Mutation and the nine-value Intent enum
- Embedding and embeddingspaceid, in agentic-audiences
- ConsentContext.json, carrying all three interoperable consent-string carriers

AdCP's buy is a purchase against published terms, and nothing moves between the published price and the signature. AAMP's is a bilateral negotiation that ends holding a deal object which did not exist when the conversation started. In the other direction, AdCP's governance and signals vocabulary has no AAMP counterpart of any kind: CreativeApproval and DecisionRecord exist inside the seller reference implementation, on no wire, and AAMP's audience work is a vector-scoring prototype whose specs/v1.0/schema/agentinterface.schema.json is zero bytes.

What breaks if the two vocabularies are swapped

Three points do not survive a translation layer. AdCP can name the commercial party behind a call and AAMP names the endpoint, so one agent representing two sellers collapses them. A getproducts brief and a tier-gated media kit are different transactions rather than two spellings of one. Quote, negotiation round and deal are AAMP objects with no AdCP equivalent, so a build on AdCP's vocabulary has nowhere to record a price that moves before signature.

The stack-level argument is at Agentic Ad Lab. The AAMP pins behind this map are listed in AAMP Explorer, the AdCP schema surface in AdCP Explorer. Related terms: package, product, quote, deal, agent, OpenDirect 2.1.

---

# Agent

Source: https://adtechglossary.com/agents/agent/

In AdCP an agent is the authenticated caller identified by its auth token, distinct from a Sales Agent (the server exposing inventory) and an AI Agent (the assistant), while AAMP makes an agent a registry-issued record instead.

An agent, in AdCP, is the authenticated entity making API calls, identified by its authentication token. The definition is narrow: it covers a brand's in-house team and an unattended buying system equally. An AdCP agent can be a cron job holding an API key, with no model anywhere in the loop. AdCP's FAQ describes AdCP as a protocol that lets AI agents collaborate across advertising platforms, but the glossary definition covers whatever software authenticates.

| Term                                | What it is                                  | How it is identified                      |
| ----------------------------------- | ------------------------------------------- | ----------------------------------------- |
| Agent                               | The authenticated entity making API calls   | Authentication token                      |
| Sales Agent | The MCP server exposing publisher inventory | Endpoint URL, declared in adagents.json |
| AI Agent                            | The AI assistant a human talks to           | Not a protocol object                     |

AAMP uses agent for a registry record. The two definitions differ on four points:

| Question                       | AdCP 3.1.13                                                                     | AAMP                                                                |
| ------------------------------ | ------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| What "agent" primarily denotes | The authenticated caller                                                        | A registry-issued party record                                      |
| Identity comes from            | A token, plus a signature or a per-seller onboarding record                     | An agentid minted by the registry at registration                |
| Enumerated?                    | No. Role qualifiers are documentation headings and supportedprotocols values | Yes. AgentType has five values                                    |
| Does identity affect price?    | No                                                                              | Yes. truststatus caps the tier, the tier caps pricing visibility |

Agent in AAMP

In AAMP an agent is a record the registry issues at registration. In the unreleased iab-agentic-primitives library (v0.5.0), identity.py makes agentid required on the Agent model, and the registry mints it. AgentType is a closed enum of buyer, seller, toolprovider, dataprovider and other, so buyer is one of its values; AdCP's role names are documentation headings. TrustStatus has five values, is "never self-asserted", and caps the access tier an agent can trade at.

AAMP publishes no glossary, and the record itself is specified only in that unreleased library. AdCP's published schemas contain no equivalent to agentid.

Role qualifiers

AdCP's conformance reference organises the protocol by role, and its section headings are the canonical list. Each role is defined by the operations it must implement, and an agent declares which it plays through supportedprotocols.

| Role                                          | Domain claim in supportedprotocols                   |
| --------------------------------------------- | ------------------------------------------------------- |
| Sales agent (seller)                          | mediabuy                                             |
| Orchestrator (buyer)                          | none; orchestrators are not servers                     |
| Creative agent                                | creative                                              |
| Signal agent         | signals                                               |
| Brand agent           | brand, plus sponsoredintelligence for the SI tasks |
| Governance agent | governance                                            |
| Content standards agent                       | governance                                            |
| Creative governance agent                     | governance                                            |

The three governance roles all claim the same governance domain. Nothing in supportedprotocols tells them apart; they are separated only by the documentation sections that define them.

In 3.1.13 supportedprotocols accepts mediabuy, signals, governance, sponsoredintelligence, creative, brand and measurement. measurement is experimental and scoped to catalog discovery. The qualifier records which operations the agent is expected to serve; the entity itself is an agent as soon as it authenticates.

Agent, account, brand and operator

AdCP's accounts and agents guide separates four entities that a billable operation involves, and Agent is the one most often collapsed into the other three. Brand answers whose products are advertised, resolved via /.well-known/brand.json. Account answers who gets billed and at what rates. Operator answers who acts on the brand's behalf, identified by domain. Agent answers what software is placing the buy, identified by the authenticated session, and its gloss adds that an agent "may operate on behalf of multiple operators and brands."

Consolidated billing has a value of its own: agent is one of three accepted values of supportedbilling, the agent that "consolidates billing across brands and is invoiced by the seller". One credential can therefore be invoiced for buys placed across several brands.

How AdCP identifies the caller

Nothing in an AdCP request body names the caller. A tools/call for getproducts carries a bearer token in the header and campaign arguments in the payload, and AdCP's accounts and security guide describes what happens next: "The server validates this token and identifies the agent making the request." enums/error-scope.json defines a per-buyer-agent rejection scope and attaches a condition to it:

 Sellers MUST emit per-agent scope only when buyer-agent identity has been established via signed-request derivation or a credential-to-agent mapping in the seller's onboarding record; emitting it without established identity is a cross-tenant onboarding oracle.

The condition is on established identity, not on a successful login. Emitting the scope without established identity discloses whether the caller's credential maps to an onboarded agent.

Three things carry identity. A token arrives on the request. An [authorizedagents[].url entry](/agents/discovery-files/) sits on the publisher's domain. A commercial mapping sits in an onboarding record the caller cannot read. The AAO directory maps agenturl to publishers and its schema declines to let that mapping confer trust, since "The publisher's own adagents.json remains the trust root". No AdCP document states which of the three is authoritative.

principal (deprecated)

AdCP retired the word in its glossary, flagged the entry Deprecated term, and split it into Account (billing, rate cards, platform mappings) and Agent (authentication and API access). The term remains in the documentation, including inside MUST clauses: the syncagentnotificationconfigs reference states that "This task MUST only be accepted when the transport request resolves to a stable authenticated principal". It also survives in schema descriptions in the 3.1.13 registry, where error-code.json explains CREDENTIALINARGS in terms of "buyer-principal credentials that should arrive on the inbound transport". It is never a JSON key, so no parser breaks on it. Each surviving use has to be read as either the Account sense or the Agent sense.

agent as an enum value

The literal string agent is an enum value in the 3.1.13 schema bundle, and it denotes something different in each file that carries it.

| Enum file                  | What agent means there                                        |
| -------------------------- | --------------------------------------------------------------- |
| enums/billing-party.json | The party the seller invoices                                   |
| enums/account-scope.json | An account with no brand or operator split                      |
| enums/error-scope.json   | The per-buyer-agent authorization axis                          |
| enums/signal-source.json | A signal source addressed by agenturl, not the caller at all |

In signal-source.json alone, agent denotes the signal vendor addressed by agenturl, "Signal native to a signal source identified by agenturl", and not the caller.

---

# Agent Card

Source: https://adtechglossary.com/agents/agent-card/

An agent card is the JSON identity document an agent publishes at a well-known URL under the A2A protocol: who operates it, where its endpoints are, which protocol version it speaks, what skills it claims and how to authenticate against it.

An agent card is the JSON document an agent publishes about itself at a well-known URL: who operates it, where its endpoints live, which protocol version it speaks, what skills it claims, and how to authenticate. The format comes from A2A, the general agent-to-agent protocol, and advertising inherited it. A2A 1.0's discovery documentation gives the path as /.well-known/agent-card.json.

The fullest worked example in either corpus is the AAMP seller agent's card, served at GET /.well-known/agent.json without authentication in IABTechLab/seller-agent (v2.4.1).

| Field                                   | What it carries                                                                   |
| --------------------------------------- | --------------------------------------------------------------------------------- |
| name, description, url, version | Identity and base URL for all protocol endpoints                                  |
| provider.name, provider.url         | The organisation operating the agent                                              |
| capabilities.protocols                | opendirect21 today; a2a "will be listed once an inbound A2A server ships"     |
| skills[]                              | Five declared skills: discovery, pricing, proposals, negotiation, deals |
| authentication.schemes                | apikey, bearer                                                               |
| inventorytypes                       | Populated dynamically from the live product catalog                               |
| supporteddealtypes                  | pg, pmp, preferreddeal, privateauction                                  |

Two A2A shapes and two live filenames

In A2A v0.3 the transport sits at the card root as url plus protocolVersion. In 1.0 it moves into supportedInterfaces[], with per-interface url, protocolBinding and protocolVersion. A card is structurally an A2A card when it carries one of those two forms. AdCP targets 1.0 and notes that v0.3 "remains widely deployed and is supported through the compatibility period"; its A2A guide documents v0.3 compatibility as opt-in, through enablev03compat=True.

No document reconciles the two filenames in use. A2A 1.0's discovery documentation gives /.well-known/agent-card.json and never mentions agent.json. AdCP's A2A guide gives agent.json twice while showing 1.0-shaped samples; its governance specification and managed-networks guide use agent-card.json. The AAMP seller agent serves agent.json from its own router while its bundled A2A client fetches agent-card.json, and buyer-agent handles both filenames on two code paths inside one repository. A consumer that fetches only one path will miss agents serving the other.

What a fetched card gives a caller

In AdCP the card still opens the discovery chain, and AdCP's guide to calling an agent is explicit about how little it hands over. An agent card or tools/list "returns tool names", and "AdCP MCP servers no longer publish per-tool parameter schemas in tools/list — every tool shows {type: 'object', properties: {}}. Don't try to infer shape from there."

The AAMP seller agent's OpenAPI declares the agent card's 200 response schema as {}, and components.schemas contains no AgentCard at all.

The card still carries the routing fields: operator identity, the transport URL, the protocol version behind it, and the auth scheme. Each of those is verifiable on the first request.

AdCP has a runtime call to fall back on when the card comes back thin. AAMP has none, because no AAMP operation asks an agent what it can do. In AAMP the card is the only capability source, and the file with the empty response schema is what defines it.

Capability discovery in v3

AdCP v3 moved capability discovery off the file and onto the wire. From the v3 release notes:

 getadcpcapabilities replaces both adcp-extension.json and the MCP agent card with runtime capability discovery. It returns supported protocols, account billing models, portfolio information, targeting systems, and governance features — all schema-validated.

Neither agent-card nor agentcard occurs anywhere in the 3.1.13 schema bundle, and the glossary has no entry for the term. AdCP's A2A guide opens its AdCP Extension section with a note recommending getadcpcapabilities and then documents the extensions array, on a worked sample carrying "adcpversion": "2.6.0" inside a v3 document. The governance property specification still shows a card declaring capabilities.tasks[] with seven tasks and schemaversion: "v1", which is the static capability declaration v3 removed for sales agents.

Card shapes in AAMP

| Card                     | Where it lives                            | capabilities is                         | Trust field           | Structurally A2A? |
| ------------------------ | ----------------------------------------- | ----------------------------------------- | --------------------- | ----------------- |
| seller-agent AgentCard | /.well-known/agent.json                 | typed object                              | truststatus        | No                |
| buyer-agent AgentCard  | registry plus agent.json                | list of AgentCapability                 | trustlevel         | No                |
| agentic-direct card      | /a2a/{role}/.well-known/agent-card.json | A2A capabilities                        | none                  | Yes, A2A v0.3.0   |
| Agent.json             | iab-agentic-primitives, unreleased        | typed AgentCapabilities plus skills[] | truststatus        | No                |
| RegistryAgent          | the live IAB registry record              | flat capabilities[]                     | verificationstatus | No                |

The seller agent serves what its own docstring calls an "A2A-protocol-compliant agent card" at an A2A well-known path, while a code comment in the same repository records that A2A "has no server yet; re-add a2a when an inbound A2A endpoint actually exists" — hence a protocol list of opendirect21 and nothing else. Trust is approved in one enum and verified in the other. IAB Tech Lab's own reconciliation note describes them as "Two incompatible cards" and as "Card schemas incompatible across repos".

The iab-agentic-primitives library (v0.5.0) folds both into one Agent primitive at spec/jsonschema/Agent.json, published under the OpenAPI summary "ONE card schema for both agents". That library is unreleased, and the reconciliation does not reach the live IAB registry, whose record diverges field by field: agentid as a string against id as an integer, name against agentname, url against endpointurl plus repositoryurl, a typed AgentCapabilities plus skills[] against a flat capabilities[] plus iabcapabilities[], one truststatus enum against verificationstatus plus domainverified plus iabmember.

The two are not being converged: "Rather than break that card ... EP-5.4 adds a new, additive RegistryAgent wire model ... the Agent Card is unchanged." IAB Tech Lab's own gap report then marks the card UNVERIFIED, because "truststatus semantics are asserted by our own spec, not against AAMP publications", the tooling having no AAMP card specification to test against.

AdCP and AAMP side by side

| Question                           | AdCP 3.1.13                                                               | AAMP                                                                                     |
| ---------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Is the card the capability source? | No. getadcpcapabilities answers at runtime                            | Yes for the seller agent, and it is the only source                                      |
| Path                               | agent.json in the A2A guide, agent-card.json in governance            | agent.json for seller and primitives, /a2a/{role}/agent-card.json for agentic-direct |
| Who is found first                 | The publisher domain, through adagents.json | The registry, through GET /agents?agenttype=seller         |
| Auth to read                       | Left to the operator                                                      | None. The seller documentation says "No authentication is required"                      |
| Published card schema              | None in the 3.1.13 bundle                                                 | None ratified; Agent.json is in an unreleased library                                  |

---

# Agent Registry

Source: https://adtechglossary.com/agents/agent-registry/

An agent registry is a directory of advertising agents, their endpoints, capabilities and trust signals. Two run: AgenticAdvertising.org's catalog for AdCP, which confers no authority, and IAB Tech Lab's for AAMP, where trust status caps price.

An agent registry is a directory of advertising agents: who they are, where their endpoints live, what they claim to do, and whether anyone has vouched for them. Two are running: the catalog of AgenticAdvertising.org (AAO), the paid-membership trade association that stewards AdCP, and the Agent Registry of IAB Tech Lab, the standards body behind AAMP. They take opposite positions on whether a registry may grant trust. In AAMP, trust status caps the price tier an agent can be quoted; the AAO catalog carries no trust signal at all.

|                 | AAO catalog (AdCP)                               | Agent Registry (AAMP)                        |
| --------------- | ------------------------------------------------ | -------------------------------------------- |
| Read the list   | anonymous GET, 200, full public catalog      | 401 Authentication required, JWT needed    |
| Get listed      | an AAO member enrols you; no self-registration   | free and open, members and non-members       |
| Public API spec | openapi/registry.yaml, 456 KB, no auth         | "documented in the Portal", behind a login   |
| Entries         | 23 visible to an anonymous caller, every one MCP | 40 shown in the portal UI, per the hub guide |

Neither registry is a precondition for transacting. No AdCP operation touches the directory, and in AAMP an unregistered counterparty resolves to unknown and trades at the public tier.

How an agent gets listed

AAO enrolment buys discovery. It confers no authority: a publisher's own adagents.json stays the trust root whether or not an agent appears in the catalog.

The catalog "contains only AAO-attested, member-enrolled agents", and an AAO member "must explicitly enroll the agent on their member profile". The same documentation states: "You cannot self-register today." Entries default to visibility: "membersonly", and reaching public requires a primarybranddomain and a paid membership tier.

A public request from an account below that tier is stored as membersonly with a visibilitydowngraded warning, and reported to the caller as success.

The catalog itself is readable without credentials, and every visible entry declares protocol: "mcp". AdCP defines its tasks over both MCP and A2A, and the catalog carries a field to tell them apart. Anonymous callers see only the public records, so the visible list is a floor rather than a total.

A listing does not guarantee a reachable endpoint. Around half of the publicly listed agents complete an anonymous MCP handshake, and three listed sales agents return a product catalogue to an unauthenticated getproducts. The agent-by-agent result is in the AdCP registry, measured.

IAB Tech Lab's launch announcement says its Tools Portal "is open to both members and non-members and is free to register and use", validating each company against its GPP ID and TCF Global Vendor List ID. Reading it is a different matter: GET https://registry.iabtechlab.ai/api/agents answers {"error":"Authentication required"}. Three base URLs for that registry circulate in the AAMP repositories, and registry.iabtechlab.ai is the one that answers; the agent discovery files guide untangles them and is also the source of the 40-agent portal figure. The registry's routes, auth envelope and record shape are documented in iab-agentic-primitives rather than by IAB Tech Lab directly.

Whether a registry confers trust

AdCP's registry documentation refuses the job:

 This endpoint is discovery, not authorization. The publisher's own adagents.json remains the trust root.

Publisher-attested signingkeys live in adagents.json on the publisher's own domain, and a verifier "MUST reject any signature whose keyid is not in that pinned set, regardless of jwksuri contents". The registry never holds key material, and none of AdCP's operations is a registry operation: the directory sits outside the protocol surface entirely.

AAMP takes the other position and prices it. Registry presence sets trust status, and trust status caps the access tier an agent can claim.

| Trust status | Ceiling in seller-agent | What that tier is shown        | Ceiling in iab-agentic-primitives | What that tier is shown        |
| ------------ | ------------------------- | ------------------------------ | ----------------------------------- | ------------------------------ |
| unknown    | public                  | price ranges only, no discount | public                            | price ranges only, no discount |
| registered | seat                    | exact prices, no discount      | seat                              | exact prices, no discount      |
| approved   | advertiser              | full discounts plus volume     | agency                            | tier discounts                 |
| preferred  | advertiser              | full discounts plus volume     | advertiser                        | full discounts plus volume     |
| blocked    | none, hard reject         | nothing                        | public                            | price ranges only              |

Of the five statuses only registered is automatic; the rest are operator decisions. On the sample rate card in the buyer agent's media-kit documentation, under a column headed "Typical Discount", the ladder is worth roughly 5 percent at seat, 10 at agency and 15 at advertiser off the same base CPM.

The library both IAB reference agents pin calls the ladder legacy. iab-agentic-primitives annotates TRUSTTIERCEILING "(Legacy AAMP trust-tier model; retained for the EP-7.1 harness)", and its sandbox registry note records that the real registry "does not implement" that model and has "no self-asserted access-tier / trust-tier enum". The two maps disagree in two rows. On approved it is advertiser tier against agency tier, 15 percent off a live deal against 10. On blocked it is a hard reject against a public ceiling: one map refuses the agent, the other prices it at rate card.

In the shipped seller agent the ladder is not wired up. The registry client is a stub: agent search returns [] unconditionally, lookups hand back mock data stamped "[STUB] Pending AAMP API integration", and the real-API client in the same file is switched off because aampregistryurl defaults to "". The seller agent's documentation states this under "Current Limitations": the integration "is stubbed pending the public API specification. Currently, agent trust is managed locally by the operator."

Out of the box every counterparty resolves to UNKNOWN, and UNKNOWN buys at the public tier. A counterparty is added through POST /registry/agents/discover. Because trust is held locally, each deployment ends up with its own list.

Revocation and change feeds

AdCP's registry ships a cursor-based change feed at GET /api/registry/feed, with an SSE variant, 90-day retention and 410 Gone when a cursor expires. Event types include agent.removed, agent.verificationlost and authorization.revoked. AAMP has nothing in that shape: the seller agent files "Automatic trust refresh (periodic re-verification against registries)" under planned improvements. Trust status has no expiry and no re-verification step.

The two registries store different things. The AAO catalog takes an agent url, is idempotent on create, and carries no trust signal; a submitted agent type is overwritten with the crawler's latest snapshot. The IAB record takes agentname and primarydomain and carries three trust signals, verificationstatus, domainverified and iabmember, of which only domainverified says anything about the agent's own infrastructure. An IAB registered records a validated GPP ID and TCF Global Vendor List ID, not a check of the agent's endpoint. An AAO listing records member enrolment.

---

# Agentic Advertising

Source: https://adtechglossary.com/concepts/agentic-advertising/

Agentic advertising is the category name for advertising planned, bought and sold by AI agents acting for a buyer and a seller, rather than by humans in dashboards.

Agentic advertising is the category name for advertising planned, bought and sold by AI agents acting for a buyer and a seller, rather than by people working in dashboards. It is a category label rather than a specification, and no document in either the AdCP or the AAMP corpus defines it.

Agentic advertising and programmatic advertising

|                 | Programmatic                            | Agentic advertising                                                    |
| --------------- | --------------------------------------- | ---------------------------------------------------------------------- |
| Who decides     | A remote bidder, per impression         | The platform holding the user context, or a pair of negotiating agents |
| What moves      | A thin bid request out                  | Catalogues, brand rules, goals and constraints in                      |
| Unit of work    | One impression, sub-second              | A campaign, a media buy, a negotiation                                 |
| Standard in use | OpenRTB, VAST, ads.txt                | AdCP 3.1.13, or the AAMP repositories                                  |
| Human role      | Configures a dashboard, then supervises | States intent, then reviews what an agent did                          |

Neither replaces the other, and AdCP's FAQ says so: "The layers compose — a single AdCP createmediabuy can spawn thousands of impression-layer events. A platform can implement both." An agentic buy usually terminates in a programmatic auction. That FAQ answer is also the only place in either corpus that says what agentic buying means, and it is AdCP describing AAMP. The data flow behind the second row is set out under agentic buying.

What can be checked instead of a definition

"Agentic" is not a conformance claim, and three checkable things stand in for it. getadcpcapabilities is a Required task in docs/protocol/required-tasks.mdx, and docs/reference/versioning.mdx tells buyers that a seller not exposing it is a pre-v3 implementation. A specialism is a named capability a seller lists in getadcpcapabilities.specialisms, with a wire ID such as sales-guaranteed; each one carries a bundle of YAML compliance tests that AgenticAdvertising.org (AAO) runs against a live agent, so a specialism listed without a run result is untested. On the AAMP side the unit is a repository and a tag, since there is no AAMP version: four AAMP repositories carry git tags and four carry none, the hub included, and AAMP Explorer tracks what each is pinned to.

Neither corpus can yet attest a production deployment, because both sides are still building the mechanism that would. AdCP's trust mark, AAO Verified, is stamped "Request for Comments". Its (Spec) axis is available now, and what it is earned against is a "test deployment, local dev, sandbox-only stack", explicitly "not production tolerance"; the axis that covers a real production endpoint is called (Sandbox), and it is "Foundation shipping" rather than available. On the AAMP side, iab-agentic-primitives v0.5.0 is unreleased and agentic-direct's MCP handlers call generateMockResponse. Named deployments do exist, and are catalogued in a sourced ledger on the hub.

Where the term is used

The closest thing to a definition in either corpus is a line in an AdCP course for decision makers: "programmatic sends a thin request out; agentic advertising brings your data in." The line appears in a training module rather than in the schema registry. The same module quotes Ben Masse of Triton Digital, one of the four interim board directors of AgenticAdvertising.org, from the egta CEO Summit: "From bidding to reasoning. From impressions to relationships. From milliseconds to months."

AdCP's glossary, docs/reference/glossary.mdx, carries the Agentic Commerce Protocol (ACP), another body's protocol covering checkout rather than media; the Agentic eXecution Engine (AXE), deprecated and "Replaced by the Trusted Match Protocol (TMP)"; and AgenticAdvertising.org, the member organisation that stewards AdCP itself. The phrase agentic advertising is not among them, and the nearest thing to it in the specification is a parenthetical on docs/building/concepts/industry-landscape.mdx, "agentic (AI agents managing full campaign lifecycles)".

The phrase is the first two words of the AAMP hub README, # AAMP - Agentic Advertising Management Protocols, whose opening calls AAMP "an open-source framework developed under IAB Tech Lab to support the evolution of agentic transactions within digital advertising ecosystems" — a different phrase, also undefined. AAMP publishes no glossary. Two repositories, agentic-rtb-framework and agentic-direct, never use the phrase, and the acronym itself does not hold steady: iab-agentic-primitives/SANDBOXREGISTRY.md expands AAMP as "Agentic Advertising Marketplace Protocol". AAMP has the rest of that list.

Vendors publish definitions of their own.

| Who                                 | Their definition                                                                                                  |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Anthony Katsur, CEO of IAB Tech Lab | "agentic is just systems executing and interacting across advertising workflows"                                  |
| Index Exchange                      | Systems that "act independently to achieve defined goals within set guardrails"                                   |
| Adgentek                            | "the planning, buying, and selling of advertising by AI agents that transact with each other over open protocols" |
| Scope3, an AdCP member              | A taxonomy of agent types: buying, sales, signals, creative, governance                                           |

None of these cites a version or a conformance test. Index Exchange's names MCP, AdCP and ARTF without a version for any of them; the other three name no specification at all. Index Exchange calls the state of the term "agentic confusion".

Agentic advertising is broader than agentic buying, which covers the procurement step and has a site of its own. It is separate again from agentic commerce: ACP and UCP standardise checkout and payment inside AI assistants, and AdCP's glossary calls them the layer complementing its own. Related terms: AdCP, AAMP, Sponsored Intelligence, and the terminology map for the object vocabularies rather than the category words.

---

# Agentic Buying

Source: https://adtechglossary.com/concepts/agentic-buying/

Agentic buying is media procurement performed by software agents: a buyer agent and a seller agent discover, price and agree a media buy, so the unit transacted is a booked buy rather than an impression won at auction.

Agentic buying is media procurement performed by software agents. A buyer agent states what a campaign needs, a seller agent replies with products and prices, and the two agree a media buy without human intervention at each step. The unit that changes hands is a booked buy agreed between two parties rather than an impression won against a bid.

AdCP's FAQ gives the term its only definition in either specification corpus, with the same scope: "how a buyer agent and a seller agent negotiate, transact, and govern a media buy across product discovery, pricing, creative, signals, and governance."

That same answer draws the line between the two agentic advertising stacks — "AAMP is agentic bidding; AdCP is agentic buying" — a characterisation AdCP qualifies as "based on AAMP materials published to date", alongside "we do not yet publish a formal technical comparison because AAMP is still defining its normative surface". Neither phrase appears in the AAMP repositories, and AdCP's glossary carries neither the term nor agentic advertising.

Where the context sits at decision time

In AdCP's training material for decision makers, programmatic "sends thin signals out to a remote bidder without context", while agentic advertising "brings rich data in to the platform that holds the context and generates the response". A bid request carries a page URL, a device type and perhaps an identifier; the retailer, the CTV app or the assistant receiving it already holds the basket, the purchase history and the session. Agentic buying pushes brand rules, goals and product catalogue into that party instead of pulling a thin request out of it.

An end-to-end walkthrough of the transaction, before any protocol vocabulary, is at whatisagenticbuying.com.

Where each stack sits relative to the auction

|                                          | AdCP 3.1.13                                | AAMP corpus                                       |
| ---------------------------------------- | ------------------------------------------ | ------------------------------------------------- |
| Operations                               | 64                                         | 143                                               |
| Serve-time operations                    | 2 (contextmatch, identitymatch)      | 1 (GetMutations, ARTF)                          |
| Shared object schemas                    | published registry, dist/schemas/3.1.13/ | 48, in iab-agentic-primitives                   |
| Repositories the stack's own index lists | one, the schema registry                   | six on the hub README, of which one is serve-time |

AdCP's total is one release; the AAMP total spans nine independently versioned repositories, so the totals are not equivalent. What compares is the share of each stack that runs at serve time: two operations of 64 on one side, one of 143 on the other.

Both of AdCP's impression-layer operations belong to the Trusted Match Protocol. None of the 48 schemas in AAMP's shared wire contract describes a bid; they describe Order, Line, Quote, Deal, Negotiation, Proposal, ChangeRequest and RateCard. Order.json describes itself as a "Campaign container (insertion order) holding one or more lines", and the seller agent's README describes that project as "An AI-powered inventory management system for publishers and SSPs to automate programmatic deal negotiation, booking, and distribution using IAB Tech Lab standards." The only bid-shaped field in those 48 schemas is bidfloor, on Deal.json and on the booking response that embeds it, which "adapters translate to the raw OpenRTB float ... at the DSP edge". AdCP's FAQ describes the same relationship when it says one createmediabuy can spawn thousands of impression-layer events.

ARTF is the one AAMP repository the agentic-bidding label fits and the only AAMP artifact stamped Version 1.0 FINAL, while iab-agentic-primitives, the repository carrying those 48 schemas, is neither linked from the hub README nor released. Both reference agents pin it as their wire contract. Whether that makes AAMP a bid-request mutation stack or a booking stack is argued at Agentic Ad Lab.

What agentic buying is not

Google's Universal Commerce Protocol (UCP) and the Agentic Commerce Protocol (ACP) from OpenAI and Stripe standardise payment and fulfilment inside AI assistants; neither books media, and AdCP's FAQ files them under commerce in a separate answer. A conversational front end on a demand-side platform is a separate case: agentic buying requires a machine counterparty rather than a machine interface, and a chat window over a DSP leaves the buy assembled and executed by the same system, with the human in the same place.

The two object vocabularies — media buy, or Order and Line — are set side by side on the terminology map.

---

# Intent (ARTF)

Source: https://adtechglossary.com/realtime/artf-intent/

Intent in ARTF is the reason an agent gives for an edit to a live bid request, carried on the wire as an 8-value protobuf enum that the framework document and the Agent Manifest both contradict.

Intent in ARTF is the reason an agent gives for an edit it wants to make to a bid request in flight. ARTF is the Agentic Real-Time Framework, one of the repositories in IAB Tech Lab's AAMP programme and the only one released as a Tech Lab standard, at v1.0 in November 2025. It is published as agentic-rtb-framework, since renamed agentic-real-time-framework, and the old URL redirects.

Agents ship as container images, and an orchestrator runs them against live traffic and accepts or rejects each mutation they propose. That orchestrator is the party running the auction: RTBRequest carries a tmax described as the time "the exchange allows for mutations to be received", and the originating party is typed TYPEPUBLISHER, TYPESSP, TYPEEXCHANGE or TYPEDSP. The wire field is a protobuf enum, the framework document and the Agent Manifest each name intents their own way, and only the enum is compiled.

The Intent enum

Nine members are defined. INTENTUNSPECIFIED is the proto3 zero value, leaving eight usable.

| Value | Name                 | Comment in the proto                                 |
| ----- | -------------------- | ---------------------------------------------------- |
| 0     | INTENTUNSPECIFIED | proto3 placeholder, no comment                       |
| 1     | ACTIVATESEGMENTS  | Activate user segments by their external segment IDs |
| 2     | ACTIVATEDEALS     | Activate deals by their external deal IDs            |
| 3     | SUPPRESSDEALS     | Suppress deals by their external deal IDs            |
| 4     | ADJUSTDEALFLOOR  | Adjust the bid floor of a specific deal              |
| 5     | ADJUSTDEALMARGIN | Adjust the deal margin of a specific deal            |
| 6     | BIDSHADE          | Adjust the bid price of a specific bid               |
| 7     | ADDMETRICS        | Add metrics to an impression                         |
| 8     | ADDCIDS           | Add extended content IDs                             |

The enum lives in rust/proto/agenticrtbframework.proto, package com.iabtechlab.bidstream.mutation.v1, which reserves 1000 to 1999 "for experimental/test intents". It reaches the wire twice. Mutation.intent says what one proposed edit is for, one intent per edit, on the bidstream mutation object (field 1). RTBRequest.applicableintents is the list the orchestrator will accept, sent before the agent replies (repeated field 7).

The framework document declares a different type

AgenticRealTimeFrameworkVersion10FINAL.md declares string intent = 1; where the shipped proto declares Intent intent = 1;. The Go and Rust bindings are generated from the proto; nothing is generated from the framework document.

None of the five names the document uses in its examples and glossary exists in the enum:

| Name in the framework document | Nearest enum value                        | Exact match |
| ------------------------------ | ----------------------------------------- | ----------- |
| activateSegments             | ACTIVATESEGMENTS                       | no          |
| activateDeals                | ACTIVATEDEALS                          | no          |
| expireDeals                  | SUPPRESSDEALS                          | no          |
| adjustDeals                  | ADJUSTDEALFLOOR, ADJUSTDEALMARGIN | no          |
| adjustBid                    | BIDSHADE                               | no          |

pb.IntentactivateSegments does not exist, so Go source carrying a document name will not compile, and the Go agent's federation config rejects the same string in a config file. Issue #10, opened in March 2026 and unanswered, asks how to prevent a container mutating deals it does not own, phrasing the question around "expireDeals or adjustDeals". Both names come out of the normative document.

The Agent Manifest, a third vocabulary

A separate vocabulary rides on the container image: JSON in an image label keyed agent-manifest, where a container declares "the intents they will invoke". The spec adds: "If the orchestrating entity cannot support the requirements and intents of a container, it should not be started."

| Name                     | Description in the specification                                                         |
| ------------------------ | ---------------------------------------------------------------------------------------- |
| bidResponseGeneration  | Generate bid responses in real time based on request data                                |
| bidValuation           | Evaluate incoming bid requests and determine bid amount                                  |
| bidRequestModification | Propose mutations to a bid request prior to auction execution                            |
| auctionOrchestration   | Route or prioritize bid requests across multiple buyers                                  |
| metadataEnhancement    | Insert or modify auction metadata such as fraud or viewability signals                   |
| dynamicDealCuration    | Curate deals in real time, optimize margins or enforce dynamic inclusion/exclusion lists |
| audienceSegmentation   | Activate or enrich user cohorts and audience segments                                    |

These are capability categories: what kind of agent this is, not what edit it wants. bidResponseGeneration and auctionOrchestration have no enum counterpart, and no enum value maps onto exactly one manifest intent, so an orchestrator matching a manifest against applicableintents has no published mapping to follow.

The specification gives the manifest two label names. The key is agent-manifest, and a later section says "the manifest may be stored as a string with the container label com.iabtechlab.artf.descriptor with a Base64 value", alongside com.iabtechlab.artf.container-version.

The manifest's own intents list — a different field from Mutation.intent — differs in every file that declares one. The framework specification lists seven {name, description} capability objects, docs/00-EXAMPLE.md lists five enum names, the Go Dockerfile lists seven and omits ADDCIDS, and rust/Dockerfile lists three in a label that is not valid JSON. No schema and no code validate the manifest, so the malformed label is never caught.

Which values each reference agent implements

The Rust bindings carry every value in the enum. The Go const block and both name maps stop at ADDMETRICS = 7, and the Go handler for the missing value says why: "ADDCIDS intent requires protobuf regeneration to be fully supported." That handler returns nil, nil.

applicableintents matters more, because pre-flight negotiation is where ARTF's governance story lives. The field is present in the Rust bindings at tag 7 and absent from the Go ones: the Go reference agent hardcodes an empty slice under the comment "For now, pass nil which means all intents are applicable", and all five samples set a field it cannot read. A ValidIntents list in its federation config carries all eight names and matches with strings.EqualFold, so the binary accepts addcids as configuration for a value its own bindings cannot express.

The JSON path drops the field instead. The MCP tool pulls applicableintents out of a request as raw strings, validates none of them, and never puts them on the pb.RTBRequest it builds. Under federation those strings reach filterMutationsByIntent, which matches case-sensitively against enum names, so a request asking for activateSegments gets back zero mutations and no error.

Intent in AdCP and in AAMP's seller agent

Four schema properties in AdCP 3.1.13 have names containing "intent", all four inside Sponsored Intelligence, and all four free text describing a human's request rather than an agent's capability. si-get-offering-request.json calls its intent an "Optional natural language description of user intent for personalized results". AdCP has no mutation vocabulary because it has no mutation object; its serve-time layer is the Trusted Match Protocol, and capability is declared at runtime through getadcpcapabilities rather than stamped into image metadata at build time. The verbs collide too: ACTIVATESEGMENTS edits one auction in flight, while activatesignal provisions a durable activationkey.

Within AAMP the term is not shared either. seller-agent v2.4.1 carries NegotiationState.lastintent, an untyped Optional[str] that a chat classifier sets to pricinginquiry, availabilityinquiry, dealrequest or counteroffer. It shares no type with ARTF in either direction.

Related terms: bidstream mutation, Trusted Match Protocol, activation, Sponsored Intelligence. The repository is covered file by file in AAMP Explorer.

---

# Audience Constraints

Source: https://adtechglossary.com/governance/audience-constraints/

Audience constraints in AdCP are the plan-level include and exclude rules a governance agent evaluates seller targeting against during check_governance, where exclusions take precedence over inclusions.

Audience constraints in AdCP are the include and exclude rules a buyer attaches to a campaign plan so a governance agent can judge whether the seller's targeting is allowed. The object has two properties, include and exclude, and no others.

governance/audience-constraints.json is the schema. include: "The combined targeting should satisfy at least one inclusion criterion", with no grouping and no nesting. exclude: "Exclusions take precedence over inclusions." Each is an array of audience selectors with minItems: 1, one of the two must be present (minProperties: 1), and additionalProperties is false, so an empty array and an empty object both fail. The schema also states what exclude is for: "protected groups, vulnerable communities, regulatory restrictions, or brand safety."

On a plan the property is named audience, not audienceconstraints. The $ref in governance/sync-plans-request.json hangs off a plan property called audience, and a plan item is additionalProperties: false, so the other name — used in docs/building/concepts/security-model.mdx, "Plan-level audienceconstraints and governance policies are machine-enforceable expressions of human judgment" — produces a rejected syncplans call rather than a warning. Only planid, brand, objectives, budget and flight are required, so a plan can arrive carrying no constraint at all; the schema never says what an absent audience means, and unconstrained is the only reading available to an agent.

The four audience selector shapes

core/audience-selector.json is a oneOf over four variants, discriminated by type (signal or description), then by valuetype.

| type        | valuetype  | Payload                                           | What it expresses                        |
| ------------- | ------------- | ------------------------------------------------- | ---------------------------------------- |
| signal      | binary      | value: true \| false                            | The user matches the signal, or does not |
| signal      | categorical | values: string[], minItems: 1                 | Specific values of the signal            |
| signal      | numeric     | minvalue, maxvalue, optional, inclusive     | A range                                  |
| description | —             | description (1–2000 chars), optional category | Natural language, when no signal exists  |

Every signal variant demands signalref or signalid through an anyOf, and signalid is deprecated: true, "retained for compatibility with older clients". New code points at a signal definition.

The description variant covers a buyer with an intent and no catalogue entry. Its schema examples are "likely EV buyers", "high net worth individuals" and "vulnerable communities", and "vulnerable communities" is also one of the phrases the container's own exclude description reserves for exclusions.

Where the schema stops checking

include is an unordered OR, and the schema defines no AND and no nesting. A buyer who wants both in-market for EVs and a household-income floor writes two selectors with no operator to join them, and the plan records the union rather than the intersection.

Inside a selector, validation is loose. All four variants are additionalProperties: true and the numeric branch requires only type and valuetype, so an unknown key, a selector with no bounds at all, and minvalue: 100 with maxvalue: 5 all validate — the last because the ordering rule is stated in prose only. Nothing downstream can distinguish a mistyped range field from an absent one. The oneOf rejects only a mistyped valuetype, which matches no branch.

A binary selector with value: false inside exclude also validates. value means "whether to include (true) or exclude (false) users matching this signal", and the container's rule is already "must not overlap with these", so the payload carries two negations and 3.1.13 does not say which wins.

How a governance agent reads the constraints

A checkgovernance request carries planid and the action under review, never the constraint object itself, so the agent has to resolve the stored plan before it can judge anything. The schema splits an intent check (tool plus payload, proposed) from an execution check (planneddelivery, committed). core/planned-delivery.json has audiencetargeting, built from the same audience-selector.json the buyer wrote the constraint in, and governance agents "MUST use this for bias/fairness validation and SHOULD ignore audiencesummary". Both sides speak one type, and the governance agent diffs them.

The reply cannot name what failed. A findings[] item is additionalProperties: false, policyid is optional, and categoryid is agent-internal with callers told they "MUST NOT pattern-match" it. No field in the object can name the offending selector. mode on the response is optional and x-status: experimental, and in audit mode "the governance agent always returns approved", so an approved verdict does not indicate whether the agent was enforcing.

minaudiencesize and restrictedattributes

minaudiencesize is a k-anonymity floor on the plan, and an agent that cannot size the audience must "produce a finding with reduced confidence rather than silently passing".

The floor "Applies to the estimated combined (intersection) audience when multiple criteria are used", while include is an OR and a union is never smaller than its parts. The specification does not reconcile the two: "criteria" may mean the seller's combined targeting or the plan's inclusion list, and nothing in 3.1.13 states which reading applies.

restrictedattributes bars personal-data categories from targeting anywhere in the campaign, from a ten-value enum cited to "EU DSA Article 26 compliance"; that enum belongs to policy categories.

AAMP's audience plan

AAMP has no field of that name. What it has is an AudiencePlan, specified in buyer-agent/docs/api/audienceplanwireformat.md, marked "Status: Active" and implemented in Pydantic on both sides. The AAMP column below describes that document rather than a published schema.

|                           | AdCP audience (3.1.13)  | AAMP AudiencePlan                                  |
| ------------------------- | ------------------------- | ---------------------------------------------------- |
| Roles                     | include, exclude      | primary, constraints, extensions, exclusions |
| Set algebra               | undefined; include is OR  | intersect / union / subtract, per role               |
| Ref provenance            | none                      | explicit / resolved / inferred, required       |
| Confidence                | none                      | 0–1, MUST be null when explicit                    |
| Consent metadata          | none                      | compliancecontext on agentic refs               |
| Content hash              | none                      | canonicalised SHA-256 over the four roles            |
| Capability negotiation    | none                      | 400 audienceplanunsupported, per-path            |
| Published schema          | yes, $id-pinned, strict | no                                                   |
| k-anonymity floor         | minaudiencesize       | prose only, in a draft                               |
| Restricted-attribute enum | 10 values                 | none                                                 |

On the wire, DealBookingRequest.audienceplan is {"type": "object", "additionalProperties": true}, described as "open object; typed model lands with the audience-plan bead", and iab-agentic-primitives v0.5.0 carries no audience schema file at all. The two protocols are set against each other in AdCP vs AAMP.

An audience selector is not AdCP's Audience object, the buyer-uploaded list registered through syncaudiences; the two are set out side by side under audience vs signal.

---

# Audience vs Signal

Source: https://adtechglossary.com/signals/audience-vs-signal/

An audience is buyer-owned CRM data uploaded to one seller account with sync_audiences and not portable across sellers, while a signal is a targeting dimension published by someone else and discovered with get_signals.

An audience is data the buyer owns and uploads to a seller account. A signal is a named targeting dimension that somebody else publishes and the buyer discovers. AdCP's syncaudiences reference page draws the line in one sentence:

 Audiences are distinct from signals: signals are named targeting dimensions discovered through product signal options, provider-published signal definitions, or getsignals; audiences are data you own and upload.

|                            | Audience                                                                   | Signal                                                                                                                                 |
| -------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Who owns the data          | The buyer                                                                  | A seller, signal source, or data provider                                                                                              |
| How it enters the protocol | Uploaded with syncaudiences                                             | Discovered with getsignals                                                                                                          |
| Protocol area              | Media Buy                                                                  | Signals                                                                                                                                |
| Identifier                 | Buyer-assigned audienceid                                               | signalref, with a scope discriminator                                                                                             |
| Kind                       | audiencetype: crm, suppression, lookalikeseed                    | signaltype: marketplace, custom, owned                                                                                        |
| Portable across sellers    | No, by schema                                                              | Two of three scopes resolve outside the seller                                                                                         |
| Members                    | Hashed emails, hashed phones, universal IDs | Not enumerable by the buyer                                                                                                            |
| Applied at buy time via    | audienceinclude / audienceexclude                                    | signaltargetinggroups (flat signaltargeting is deprecated)                                                                      |
| Priced in the protocol     | No price field on the request or the response                              | pricingoptions[] at discovery, resolving to core/signal-pricing.json: cpm, percentofmedia, flatfee, perunit, custom |
| Needs an activation step   | No                                                                         | Often, via activatesignal                                                                                   |

core/package-signal-targeting.json tells implementers not to cross the two: "Use audienceinclude/audienceexclude only for buyer-managed first-party audiences registered through syncaudiences."

How an audience enters the protocol

sync-audiences-request.json requires idempotencykey and account, plus one field per audience, audienceid; everything else is optional, including audiencetype, which is what changes the seller's behaviour. deletemissing: true removes every buyer-managed audience not in the request. When a list falls under a platform minimum, sellers "MUST emit 'toosmall' (not 'ready' with a low matchedcount)" and populate minimumsize. The field list is in AdCP's syncaudiences reference.

Portability across sellers

An audienceid cannot cross sellers. core/targeting.json states the rule on audienceinclude and again on audienceexclude: "References audienceid values from syncaudiences on the same seller account — audience IDs are not portable across sellers." The glossary puts it as "Audiences are account-scoped." Each seller relationship requires its own upload and produces its own match rate, and the protocol offers no path to ask whether the same person was reached on two of them.

What an uploaded audience does buy is a binding rule at delivery: "audienceinclude is a hard constraint — only users on the list are eligible." Lookalike expansion is the opposite, and AdCP says so: "lookalike intent expressed in the brief cannot be verified through the protocol; confirm via seller-side reporting."

Trusted Match evaluates membership buyer-side per impression rather than making audienceid portable. The publisher sends an opaque identity token, the buyer's own Identity Match endpoint returns eligible package IDs, and the list is never uploaded. It requires a TMP router at the publisher, and all ten Trusted Match schemas carry "x-status": "experimental".

Support is a capability check on either path. targeting.json says "Seller must declare support in getadcpcapabilities", and the declaration is a presence check on mediabuy.audiencetargeting. No object means no audiences, and no error code in 3.1.13 is scoped to unsupported audience targeting.

Signals are only slightly more portable. A signalref carries a scope discriminator with three branches, product, dataprovider and signalsource, and only product is confined to one seller relationship, which is where every audience already lives. The three scopes are set out under signal definition.

Signal types

A signal is not always third-party data. The wire field is signaltype, resolving to enums/signal-catalog-type.json, whose title is "Signal Availability Type", and validators follow that enum:

| Value         | enumDescription                                                                                                                                   |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| marketplace | "Resold third-party segments (provider authorization verifiable via the provider's adagents.json)"                                                |
| custom      | "Source-native segment built on demand from models, composites, or buyer inputs - not attributable to a standing upstream provider"               |
| owned       | "First-party segments derived from data the signal agent or seller directly owns (retailer purchase data, publisher behavioral data, telco data)" |

A signal can therefore be first-party data. owned means the seller or the signal agent holds it; an audience means the buyer does.

lookalikeseed sits on the boundary. The buyer uploads the seed, the seller models on it, and the result is derived from data the seller now holds, which matches the owned description. AdCP does not settle it: the seed list is the audience, and the modelled segment never gets an audienceid.

AdCP also widened its own definition mid-release. Documentation shipped up to 3.1.0-beta.3 reads "signals are third-party data products you discover and activate"; from 3.1.0-beta.4 onward it reads "named targeting dimensions".

glossary.mdx disagrees with the enum: it gives Signal Type six values, four of which exist nowhere in 3.1.13, while omitting custom. That same glossary defines Audience and ten Signal  compounds and has no entry for Signal itself. The field-level detail is in signal definition.

Audiences and signals in AAMP

No signal object exists in any AAMP repository, and no CRM upload path: neither the wire contract nor either reference agent has a signal-shaped field.

Audience-shaped fields do exist, and every one of them in iab-agentic-primitives is typed {"type": "object", "additionalProperties": true} or the nullable version of that, with no sub-schema behind it. QuoteRequest.json says why: "Audience plan slot (open object; the typed model lands with the audience-plan bead)." RECONCILIATION.md files it under "Explicitly out of scope (stated, not accidental)". Two incompatible shapes are already in use.

| Source                                                                                               | What an audience plan is                                                                      |
| ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| iab-agentic-primitives conformance golden vector                                                   | {"planid": "ap-9", "segments": [{"id": "1001", "role": "reach"}]}                          |
| buyer-agent/docs/api/audienceplanwireformat.md §2.1, "the authoritative wire-format definition" | {schemaversion, audienceplanid, primary, constraints, extensions, exclusions, rationale} |

The two shapes share no field names, both validate against the open object, and neither has been ratified as the format.

AudienceRef, the one typed audience object AAMP has, points at an IAB Audience Taxonomy ID, an IAB Content Taxonomy ID, or an embedding URI. All three are data somebody else published, which by AdCP's definition makes them signals. The reference seller agent's one audience endpoint is POST /agentic-audience/match. The protocol-level comparison is at AdCP vs AAMP.

---

# Brand Agent

Source: https://adtechglossary.com/agents/brand-agent/

A brand agent is the AdCP agent that answers questions about a brand identity and licenses its rights. In AdCP 3.1.13 it is declared as an agents[] entry with type "brand" in brand.json. AAMP has no equivalent.

A brand agent is the AdCP agent that answers questions about a brand: who owns it, what it looks like, and whose likeness or voice may be generated on its behalf. AdCP's architecture module describes the role as: "Manages brand identity and guidelines via brand.json".

Four different things go by the name. This entry covers the first.

| Sense                                                                   | What it is                                                       | Where it is specified                                                                   |
| ----------------------------------------------------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Brand identity agent                                                    | Answers identity questions about a brand and licenses its rights | AdCP brand.json, as an agents[] entry with type: "brand"                          |
| Sponsored Intelligence brand agent | Sits inside an AI assistant and talks to a user                  | AdCP's Sponsored Intelligence tasks, registered separately from the identity operations |
| Buy-side brand agent                                                    | Executes media buying on the brand's behalf                      | Scope3's published taxonomy; type: "buying" in the same AdCP enum                     |
| Branded assistant                                                       | An assistant with a company logo in the chat window              | Nothing                                                                                 |

The term is not in AdCP's own glossary, which defines Agent, Sales Agent and Signal Agent, and uses "brand agent" only inside other terms' definitions.

What a brand agent answers

Creative agents are the main callers, and they call before generation rather than during a buy. From AdCP's brand specialist guide: "A creative agent fetches brand.json (or calls getbrandidentity authorized), then pulls the wordmark, applies the exact palette and type scale, adopts the tone of voice, and obeys the restrictions." The rights-licensing walkthrough has a buyer agent calling it too.

Answers come in two tiers. Any caller gets the public baseline unauthenticated: house, names, description, industries, kellertype (the brand-architecture classification), basic logos, tagline. Assets, voice synthesis, tone, restrictions and rights availability need a linked account, set up once by calling syncaccounts. Until then the response lists the withheld sections in availablefields, so a caller can tell an unauthorised response from an incomplete file.

How a brand agent is declared

A brand agent is declared in one file, brand.json, fetched from https://example.com/.well-known/brand.json under RFC 8615. There is no registry to join. Two shapes declare one: a standalone brand agent document, or a type: "brand" entry in the agents[] array of a fuller file, either a house portfolio or a brand's canonical document. AdCP's brand.json reference treats the two routes as equivalent, and all five file variants are laid out on discovery files.

In dist/schemas/3.1.13/brand.json, properties.brandagent carries "deprecated": true and this note:

 Deprecated: use agents array with type 'brand' instead. Brand agent that provides dynamic brand data via MCP.

rightsagent goes the same way. The replacement is an agents[] entry whose type comes from an eight-value enum titled "Brand Agent Type".

| type        | What that agent does                                            |
| ------------- | --------------------------------------------------------------- |
| brand       | Brand identity data (logos, colors, tone, guidelines) via MCP   |
| rights      | Rights discovery, pricing and acquisition for licensable assets |
| measurement | Campaign measurement, attribution and reporting                 |
| governance  | Brand safety, compliance and policy enforcement                 |
| creative    | Creative asset generation, review and approval                  |
| sales       | Sells inventory for publishers and media owners                 |
| buying      | Executes media buying for the brand                             |
| signals     | Audience signal discovery and activation                        |

Both sales and buying appear in the same enum, so an entry records only that the brand declared the agent, not which side of the trade it sits on. The sales agent entry sets out the same collision in AdCP's role names.

Mechanically the change is a rename with a discriminator added: {"url": ..., "id": ...} under brandagent becomes {"type": "brand", "url": ..., "id": ...} inside agents[]. type, url and id are required, everything else is optional, and an unset jwksuri defaults to /.well-known/jwks.json on the origin of url.

AdCP's brand-json.mdx reference still tables brandagent as an ordinary optional object, agents has no row in that table, and the file's one deprecation note is about rightsagent. The schema says deprecated rather than removed and names no removal version, so both shapes stay readable: a producer writing new files uses agents[], and a consumer has to accept either.

Operations and conformance

Six AdCP operations are registered to the brand agent. The four Sponsored Intelligence operations are registered separately and are not in this table.

| Operation             | What it does                                              | In required-tasks.mdx |
| --------------------- | --------------------------------------------------------- | ----------------------- |
| getbrandidentity  | Identity data; core public, more for authorised callers   | Required                |
| verifybrandclaim  | Verify one claim: subsidiary, parent, property, trademark | Absent                  |
| verifybrandclaims | Bulk variant, results positionally aligned                | Absent                  |
| getrights          | Search licensable rights, natural-language first          | Conditional             |
| acquirerights      | Binding acquisition; pick a pricingoptionid           | Conditional             |
| updaterights       | Lifecycle of an existing grant                            | Conditional             |

The conformance table and the registered operations do not line up in either direction. creativeapproval is listed Conditional, "required when the agent reviews AI-generated content", with no operation of that name behind it; it is the payload a buyer submits to the approvalwebhook from acquirerights. verifybrandclaim and verifybrandclaims are the reverse case: both are callable, and neither appears in the conformance table, so nothing in 3.1.13 says whether they have to ship. The one hard requirement stated is that brand agents MUST declare brand in supportedprotocols.

The rights half is flagged experimental

acquirerights can issue scoped generationcredentials, bounded by a rightsconstraint on uses, countries and an impression cap, after which generation stops. AdCP's brand specialist guide names Midjourney for likeness and ElevenLabs for voice as providers that verify those credentials at generation time. Both names appear in documentation, not in the schemas.

All of it sits in the brand.rightslifecycle experimental cluster under a strict declaration rule: any implementation of a task in it MUST declare the cluster id. "Partial implementation is allowed; silent implementation is not." AdCP gives its reason for the flag as a "Legal-construct surface added late in the 3.0 cycle" whose first deployments will expose edge cases in partial rights, sublicensing and revocation.

Brand agent in AAMP

AAMP defines no brand agent. Three artifacts in the IAB Tech Lab repositories use the word, and none is a callable brand service.

| What AAMP has         | Where                                                  | What it actually is                                                                                                    |
| --------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| brandingagent      | buyer-agent, in its CrewAI agent config              | An LLM persona, role: "Branding Specialist", picking premium display and video placements                            |
| advertiserbrandid | iab-agentic-primitives, on the avails request        | A 36-character string, with no schema behind it and nothing to call                                                    |
| agentrole: "brand" | agentic-audiences, in embeddingformat.schema.json | One member of a six-value enum, in a draft whose sibling specs/v1.0/schema/agentinterface.schema.json is zero bytes |

The first row is the one a search surfaces, and it is a persona inside the buyer agent rather than a service anyone can call. The nearest thing AAMP has to brand identity on the wire is the advertiserbrandid string.

The buy-side sense

Scope3's published definition is the buy-side one: "an AI buying agent that acts on behalf of a brand — translating objectives, budgets, and brand standards into advertising decisions". That is type: "buying", another value in the same Brand Agent Type enum. AdCP's own decision-maker material reaches for the buy-side reading too, calling a brand agent "a personal shopper". AdCP's schemas implement the identity sense.

The well-known path is contested as well. Brand Context Protocol v0.7, published by Encoded Brands and dated 2026-07-05, serves /.well-known/brand.md. Its specification says the brand.json output projects into AdCP's "brandagent/getbrandidentity contract", which is the field AdCP deprecated, and neither corpus acknowledges the other. A document can be valid BCP output and still carry the shape AdCP is retiring.

---

# Buyer Agent

Source: https://adtechglossary.com/agents/buyer-agent/

A buyer agent is the demand-side software in an agentic media transaction: it takes a campaign brief, finds sellers, decides what to buy, books it, and hands the deal ID to a DSP for activation. AdCP calls the role an orchestrator.

A buyer agent is the demand-side software in an agentic media transaction: it takes a campaign brief, finds sellers, decides what to buy, and books it. It is not a DSP; it books the media and hands the deal ID to the DSP, which activates it. The AAMP buyer's README states that boundary itself: "Obtain Deal IDs for DSP activation in The Trade Desk, DV360, Amazon DSP, and other platforms."

Both protocols carry the role and shape it differently. AAMP ships a deployable, registered service; AdCP names the role orchestrator. Scope3's published taxonomy treats the buyer agent as a brand agent instead; AdCP keeps the two apart, and the brand agent gets its own conformance section in the same file that refuses the buyer one.

Buyer agent in AAMP

AAMP's buyer is software you deploy. It runs, holds an identity, pushes that identity to a registry other software can query, and answers on HTTP routes of its own. The AAMP hub README calls it a "Reference implementation of demand-side agent logic and decision workflows". Its input is a structured CampaignBrief, where AdCP's orchestrator sends a natural-language brief string on getproducts; Brief Gateway sets the two shapes out field by field.

The discovery flow, from the buyer agent's seller-discovery documentation:

1. Query the agent registry for sellers: GET /agents?agenttype=seller&capabilities=ctv.
2. Fetch each seller's agent card: GET /.well-known/agent.json.
3. Check its trust status at the registry: GET /verify?agenturl=....
4. Transact: quote, negotiate, book.

Before any of that, the buyer publishes itself. registerbuyer(buyercard) POSTs the buyer's own card to {registry}/agents "so that seller agents can discover and verify this buyer", so a seller can run the same verification in the other direction. AdCP has no equivalent, because it has nothing for a registry to hold.

The buyer agent (v2.3.0) exposes 13 OpenAPI paths against the seller agent's 74, and AAMP Explorer reconciles the two vocabularies. Those 13 paths are a control plane for whoever operates the buyer, not an interface a seller calls: /bookings and its approvals, /products/search, /events, /reports/{jobid}, orders, two /meta routes, /health. Card serving is not among them, because registerbuyer() pushes the card to the registry and the registry is what sellers query.

Orchestrator in AdCP

The orchestrator is the only role in AdCP's conformance reference with no task table. Every other section opens with a | Task | Requirement | Notes | grid of operations the role must implement. "Orchestrator (buyer)" opens with a constraint instead:

 Orchestrators are not MCP/A2A servers — they call sales agent tasks.

In place of a table it gets five obligations, each about how to call somebody else's tasks. A conformant orchestrator MUST authenticate; send the required fields per request schema; handle async task states and webhook delivery of completion artifacts; use mediabuyid for every later operation; and respect creativedeadline. The constraint is on protocol surface, not on network listeners: no MCP or A2A tools, no agent card, no registry entry, nothing that addresses the orchestrator by name. An inbound listener exists anyway, since pushnotificationconfig requires a url.

AdCP does not define the role. Its glossary has entries for "Sales Agent" and "Signal Agent" and none for "Buyer Agent" or "Orchestrator", while the phrase runs through the documentation. In the shipped schemas buyeragent appears only inside a description string in get-adcp-capabilities-response.json.

The omission is visible in the schemas. create-media-buy-request.json requires idempotencykey, account, brand, starttime and endtime, and carries no buyer object. Identity is the auth token plus an account grant, which account-authorization.json calls "The authenticated caller's grant against a specific account". On the buy side the word AdCP uses is the bare "agent".

| Question                     | AdCP 3.1.13                                                                     | AAMP buyer-agent v2.3.0                                                 |
| ---------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Normative role name          | Orchestrator (buyer); "buyer agent" only in learning docs                       | Buyer agent                                                               |
| Is it a server?              | No. "Orchestrators are not MCP/A2A servers"                                     | Yes. It deploys, registers a card, and answers on 13 OpenAPI paths        |
| Published identity           | None specified for the buy side                                                 | Registered in the agent registry with a buyer card                        |
| How it finds counterparties  | adagents.json on publisher domains, plus the AgenticAdvertising.org registry  | The AAMP agent registry, queried by agenttype and capability           |
| How its authority is bounded | A governance agent validates the plan before spend | Access tier, capped by registry trust status |
| Source type                  | Published specification                                                         | Reference implementation at one tag                                       |

AdCP's FAQ files AAMP at the impression layer, and the hub's comparison takes that apart. The buyer repository is one of the counterexamples: it books programmatic direct over IAB OpenDirect 2.1 and hands deal IDs to DSPs, which is campaign-layer work.

Card incompatibility

iab-agentic-primitives/spec/jsonschema/Agent.json is where AAMP types its agents, and its agenttype defaults to "buyer". Its schema description says the model "Unifies the seller repo's AgentCard and RegisteredAgent (the buyer repo shipped an incompatible card schema; this model is the single replacement for both)." That replacement is not shipped, because the primitives library is unreleased, so the buyer's own card stays incompatible with the seller's: it calls the trust field trustlevel where the primitives say truststatus. The agent card entry sets out all five shapes in use.

What a buyer agent needs to transact

An AdCP buy needs a credential, an outbound MCP or A2A client, and a webhook receiver that verifies RFC 9421 signatures against the sales agent's published JWKS. There is no registration step and no published buy-side identity. An AAMP buyer needs the same, plus a deployed service, a published card and a registerbuyer() call.

The difference shows up in the seller's pricing. verifiedbuyercontext in the seller agent caps a claimed tier at what the seller can verify.

| What the buyer presents                 | What the seller can verify           | Resulting tier                           |
| --------------------------------------- | ------------------------------------ | ---------------------------------------- |
| An agenturl the registry resolves    | The registry record behind the URL   | The claimed tier, capped by trust status |
| A seller-issued API key, no agenturl | The key it issued                    | The claimed tier, "trusted as claimed"   |
| Neither                                 | Nothing. "the claim is unverifiable" | Floored to PUBLIC                      |

A buyer with only a credential still transacts, at the floor tier, and that tier does not carry to the next seller.

---

# Deal

Source: https://adtechglossary.com/negotiation/deal/

A deal is a negotiated buying arrangement between one buyer and one seller, identified by a seller-issued deal ID the buyer activates in its DSP. In AAMP it is the booking record a quote becomes; AdCP defines no deal object.

A deal is a negotiated buying arrangement between one buyer and one seller, identified by a deal ID the seller issues and the buyer activates in its DSP. Seller-issued identifiers follow IAB OpenDirect, which the buyer agent's documentation names as the precedent: "the IAB OpenDirect pattern where the sell-side is the system of record".

In AAMP the deal is a schema object: the booking record a quote becomes once a buyer agent commits to it. spec/jsonschema/Deal.json requires five fields — dealid, dealtype, product, pricing, terms — and settles who mints the identifier in a single line: "ID minting: dealid is seller-issued." The seller agent creates one at POST /api/v1/deals. The schema sits in iab-agentic-primitives v0.5.0, unreleased at that version.

Three deal types

dealtype is a three-value enum, and the schema states that the short form is the wire form: "The short wire encoding is canonical."

| Value | Expansion               | Pricing     | Guarantee                             |
| ----- | ----------------------- | ----------- | ------------------------------------- |
| PG  | Programmatic Guaranteed | Fixed price | Guaranteed impressions                |
| PD  | Preferred Deal          | Fixed price | Non-guaranteed, buyer gets first look |
| PA  | Private Auction         | Floor price | Competitive, invited buyers           |

The retired long-form encodings (programmaticguaranteed, preferreddeal, privateauction) are recorded in the schema as aliases and marked "NOT valid wire values".

What booking adds to a quote

A booked deal carries the same five required fields as the quote it came from, with dealid in place of quoteid, and each object back-references the other. What booking adds is activation — openrtbparams, activationinstructions and supplychain — plus a status vocabulary of twelve values against the quote's four. The only property that does not survive booking is availability, which a booked deal has already consumed.

Three fields carry activation. openrtbparams holds the bidstream parameters and supplychain is the OpenRTB schain object, "optional so pre-schain deals still validate". activationinstructions is a string-to-string map with no schema description; the seller agent fills it with a sentence of English per DSP, keyed ttd, dv360 and xandr, telling a trader where to paste the deal ID.

How a deal is booked

DealBookingRequest asks for quoteid and an idempotencykey, and nothing else. Its description: "This is the commit point — the referenced quote becomes bound." buyeridentity, consentcontext, audienceplan and notes are optional, because everything priced already sits on the quote. buyeridentity holds the identifying details a buyer chooses to reveal, which set the access tier its price is computed at, and the schema caps what they can buy: "The tier derived from these fields is capped server-side by the registry-verified trust status of the calling agent — it is never self-asserted."

The dealid then becomes a bidstream object: the RTB framework's intent enum includes ACTIVATEDEALS, SUPPRESSDEALS, ADJUSTDEALFLOOR and ADJUSTDEALMARGIN.

Deal status

DealStatus enumerates proposed, negotiating, accepted, booked, active, makegoodpending, partiallycancelled, completed, rejected, failed, cancelled, expired. Its docstring describes the enum as "ONE deal status vocabulary, unioned from the four competing sets", and it records retired aliases rather than dropping them, including partiallycanceled to partiallycancelled, a US/UK spelling split that appears in two agents' enums.

DealStatus does not cover every status in circulation. The seller agent's own DealBookingStatus in models/quotes.py carries a fifth value, confirmed, that the twelve do not include, and the deal export and push paths in that repository compare a status against the same literal. Its ad server client works from a fourth vocabulary again, normalising ad server statuses to draft, active, paused and archived, three of which have no counterpart in DealStatus.

state/DealLifecycle.json is the one file that says what the ad ops states are for, moving active to makegoodpending on "Makegood requested for under-delivery" and back on "Makegood resolved, delivery resumed".

Auction type on a booked deal

openrtbparams.at tells a DSP whether to bid a booked deal's agreed price or bid into an auction. OpenRTB 2.6, vendored by IAB Tech Lab into the agentic RTB framework, defines field 6 of the Deal message as "1 = First Price, 2 = Second Price Plus, 3 = the value passed in bidfloor is the agreed upon deal price", so at=3 is the fixed price and at=1 is the first-price auction a private auction runs. Deal.json defaults OpenRTBParams.at to 3, and the seller agent's dealsapi.py follows that mapping.

The published prose disagrees, and it is the side that is wrong: docs/api/quotes.md and the dealservice.py path that POST /api/v1/deals calls send at=1 for programmatic guaranteed and preferred deals and gloss at=3 as "private auction". At at=1 the agreed number is only a floor, the bidder re-values the impression and skips it whenever its valuation lands under the floor, and a guaranteed line tagged at=1 underdelivers into a makegood. Deal.json declares no conditional between dealtype and at, so the inverted pairing validates as a well-formed deal.

Deal, quote and campaign container

| Object                                         | What it is                                       | Binding                                          |
| ---------------------------------------------- | ------------------------------------------------ | ------------------------------------------------ |
| Quote                   | A seller's price for one product over one flight | Non-binding, expires, reserves nothing           |
| Deal                                           | The booking that quote becomes                   | Seller-issued dealid, activatable in a DSP    |
| Media buy or Order | The campaign container a booking sits under      | AdCP's createmediabuy object; AAMP's Order |

AdCP has no deal object

AdCP 3.1.13 defines no deal schema. None of its 64 published operations books one, and no property in the registry is named for a deal. The word appears in two descriptions: enums/response-type.json lists deal as one of four Trusted Match response types, "Deal ID for programmatic execution", and core/insertion-order.json describes AdCP's signing wrapper by what it refuses to do, "The IO does not introduce new deal terms".

|                      | AAMP                             | AdCP 3.1.13                                           |
| -------------------- | -------------------------------- | ----------------------------------------------------- |
| Priced artifact      | Quote, quoteid                | Proposal, proposalid, proposalstatus: committed |
| Commit call          | POST /api/v1/deals             | createmediabuy                                    |
| Seller mints         | dealid                        | mediabuyid, confirmedat                        |
| Signature wrapper    | none                             | insertionorder / ioacceptance                   |
| Bidstream activation | openrtbparams, supplychain | none                                                  |

AAMP's dealid is carried in bid requests. AdCP 3.1.13 registers no bidfloor, wseat or schain property, and its commit point produces a media buy rather than a deal.

---

# Discovery Files

Source: https://adtechglossary.com/agents/discovery-files/

Discovery files are documents a domain owner publishes at a fixed /.well-known/ path to declare which agents may act for that domain; AdCP defines two, adagents.json and brand.json, and AAMP defines none.

A discovery file is a document a domain owner publishes at a fixed /.well-known/ path to declare which agents may act for that domain. An agent card, served from the same /.well-known/ prefix, is the reverse: an agent's statement about itself. AdCP defines two discovery files, and AAMP defines none.

| File            | Hosted by                                    | Schema title              | Answers                                                        |
| --------------- | -------------------------------------------- | ------------------------- | -------------------------------------------------------------- |
| adagents.json | Publisher domains, and data provider domains | AdCP Agents Authorization | Which agents may sell this inventory, or resell these signals? |
| brand.json    | Brand and house domains                      | Brand Discovery           | Who is this brand, and who speaks for it?                      |

Other strings share the namespace and none has a schema. /.well-known/adcp/sales and /adcp/signals are agent endpoints that appear only in examples. adcp-ownership.txt carries the domain-control challenge: the registry issues a single-use nonce, echoed back from that path inside fifteen minutes, or the same proof runs through a adcp-owner.{domain} DNS TXT record. Neither of the two schemas has changed across the stable 3.1.x releases.

What a buyer computes from the two files

The two files are read against each other, and validation "checks both sides": the publisher's adagents.json (does it authorise this agent with the claimed delegationtype?) and the operator's brand.json (does it declare this property with a matching relationship?). The result is a five-state signal with one documented buyer action per state.

| State              | Meaning                                                                                          | Buyer action                                                                      |
| ------------------ | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| inline           | The seller is the brand owner, no delegation involved                                            | Proceed                                                                           |
| mutualassertion | Both sides published matching declarations                                                       | Proceed                                                                           |
| onesidedbrand  | The seller's brand.json claims a publisher that hasn't reciprocated                            | "Do not treat as authorization. Any domain can claim any publisher unilaterally." |
| onesidedhouse  | The publisher's adagents.json names a seller whose brand.json doesn't acknowledge it         | Hold for human review                                                             |
| standalone       | Neither side publishes, bearer-token trust only, which is where a silent domain puts every buyer | Out-of-band authorisation, or refuse                                              |

AdCP credits the mutual-assertion pattern to ads.txt and sellers.json, and what it adds is the second side: an entry in a publisher's adagents.json counts as authorisation only when the named agent's own brand.json declares the same property back.

The string mutualassertion appears in no published schema, in 3.1.13 or earlier. The five states live in three .mdx documents and nowhere else, and docs/trust.mdx labels the model an RFC linked to a GitHub issue rather than settled specification. Two conformant implementations can compute different verdicts about the same publisher without either violating a schema.

The two cross-checked enums are different lengths. delegationtype has three values: direct, delegated, adnetwork. relationship has those three plus owned, which the schema documents as having "no adagents.json delegationtype counterpart", and no rule says what a validator does with the leftover. AAMP's trust status is a typed field on the wire; AdCP's five states are not in any schema.

The five brand.json variants

| #   | Variant                             | Use when                                   |
| --- | ----------------------------------- | ------------------------------------------ |
| 1   | Authoritative Location Redirect     | The canonical document is hosted elsewhere |
| 2   | House Redirect                      | The brand domain rolls up into a house     |
| 3   | Brand Agent | An MCP agent serves brand identity         |
| 4   | House Portfolio                     | A house publishes its brands               |
| 5   | Brand Canonical Document            | A brand self-publishes its own identity    |

A canonical document is the schema's brand definition: id and names required, the rest optional, plus housedomain for a brand in a house. Variant 4 wraps that definition in brands[], inline or by pointer, and adds house-level trademarks and authorizedoperators.

Variants 1 to 3 are mutually exclusive with each other and with 4 and 5. Variants 4 and 5 compose: brandrefs[] points down from the house, housedomain points back up, and each side must name the other. Nesting stops there — "A brand cannot itself declare brandrefs[]" — so a house that lists its brands inline keeps editorial control: "If Converse wants to update its logo, someone edits Nike, Inc.'s file".

Both redirect variants take an optional redirectreason with seven values, four of which "suggest the resolved target is in transition and consumers SHOULD shorten cache TTL until stable".

The schema's own top-level description lists four of the five. Brand Canonical Document is missing from it, and the same sentence says the file is hosted "on house domains" when variant 5 puts it at the brand's own /.well-known/brand.json. A reader working from that description rather than from the definitions under it will miss a valid variant.

adagents.json: six authorisation variants over one base

A pointer file carries authoritativelocation; an inline file carries the catalog arrays, contact, catalogetag and authorizedagents[].

Entries in authorizedagents[] are discriminated on authorizationtype: four variants scope inventory (propertyids, propertytags, inlineproperties, publisherproperties), two scope data (signalids, signaltags). All six inherit url, authorizedfor, signingkeys, encryptionkeys and lastupdated from core/authorized-agent-base.json, "centralized to prevent drift across all authorization-type variants". Because the publisher rather than the agent publishes those keys, a buyer can check an agent's signature against the domain's own declaration.

authorizedagents: [] carries no authorisation meaning. Validators "MUST NOT read it as deny-all, authorize-all, or a revocation, MUST NOT treat its presence as an error, and MUST still consume the catalog arrays." The registry emits exactly this shape: its writes are "an identity-only write surface: the stored document always carries authorizedagents: []". A validator that reads an empty array as deny-all rejects every publisher the registry has written.

Fetching carries its own risk: one deploy at an authoritative location changes authorisation for every publisher in the network. AdCP's managed-networks guidance writes the fetch rules at MUST: the response is capped at 5 MB for the pointer and a recommended 20 MB for the dereferenced file, redirects are refused, and both hops carry short timeouts. On a transient 5xx the cached file is served rather than failing closed, a deliberate availability choice.

Discovery files in AAMP

AAMP defines no domain-hosted authorisation file and no brand identity file. It does use /.well-known/ for the agent's own card, the opposite direction of assertion. The nearest approach is a docstring: iab-agentic-primitives documents a registry endpoint answering "whether a publisher domain authorizes a given agent URL, per the publisher's /.well-known/authorized-agents.txt file." No schema or field list for that file is published, and the test double "does not fetch the publisher's authorized-agents.txt".

Authority sits in a different place in each stack. AdCP's discovery path starts at a file the domain owner publishes and moves on to a runtime capability call, and the authorisation entry carries the agent's signingkeys and encryptionkeys. AAMP's starts at a registry query and moves on to an agent card fetch, with no key attestation in the discovery path, so the registry operator holds the position the domain owner holds in AdCP.

---

# Governance Agent

Source: https://adtechglossary.com/agents/governance-agent/

A governance agent is an external service a buyer configures to validate campaign actions before they execute; both the orchestrator and the seller call check_governance against it, and in AdCP 3.1.13 that surface is still marked experimental.

A governance agent is an external service a buyer configures on its account to validate campaign actions before they execute. AdCP's FAQ scopes the checks to "budget limits, brand safety, regulatory compliance".

docs/trust.mdx gives the reason for "external": "the agent that spends money is never the agent that approves the spend." Neither the buyer's orchestrator nor the seller's sales agent qualifies, so both call the same third party.

In dist/schemas/3.1.13/account/sync-governance-request.json, governanceagents is an array with minItems: 1 and maxItems: 1, so an account carries exactly one. The endpoint must be HTTPS ("pattern": "^https://"), and capabilities go at .well-known/agent-card.json, the same agent card path every other AdCP role uses.

AdCP assumes a third-party market without naming it: docs/governance/campaign/specification.mdx tells buyers to verify their own tokens so they can catch "a misbehaving governance vendor", and AdCP names no governance vendors and publishes no conformance list.

What a checkgovernance call carries

checkgovernance takes a phase: purchase, modification, delivery. It answers approved, denied or conditions. A conditions verdict is a failure that names what would pass: the response carries a field, a reason, and a requiredvalue where that value is machine-actionable, and the caller must "re-call checkgovernance with the adjusted parameters before proceeding". Denied and conditions put the seller under the same duty, to honor the verdict; the FAQ's wording is "you can't override a governance decision or modify budgets." Findings carry a severity of info, warning or critical, plus a confidence between 0 and 1.

The governance agent returns approval as governancecontext, a compact JWS. The buyer attaches it to the protocol envelope on the purchase request; the seller persists it and replays it on every later checkgovernance call in that action's lifecycle. Verification was optional in 3.0; in 3.1 every seller must verify signature, aud, exp, jti replay and revocation against a JWKS resolved through syncgovernance.

When governanceagents is present on the account, the seller "MUST call checkgovernance before confirming any media buy". The seller does not owe outcome reporting, which belongs to the orchestrator through reportplanoutcome, and it does not owe an audit-log store, since a seller is "not required to maintain or hand over" one.

A governance check does not always block a buy

docs/trust.mdx and docs/protocol/design-principles.mdx both carry the same caveat:

 checkgovernance is a seam, not an enforcer. A seller that has not configured a governance agent, or a misconfigured one, will not call checkgovernance at all — the protocol does not prevent a non-conformant seller from transacting.

Three conditions stand between the protocol's MUSTs and a blocked buy. syncgovernance is one of the five Accounts operations, and required-tasks.mdx marks it Conditional: "Required when the buyer uses campaign governance", so an account with nothing synced has no agent to call. Sellers implementing campaign governance "declare governance.campaign in experimentalfeatures", and nothing compels the declaration. A configured agent can also run in a non-blocking mode: enums/governance-mode.json is audit | advisory | enforce, and audit means "Log all checks, never block ... the governance agent always returns approved." AdCP's walkthrough has the buyer starting there.

AdCP's two hardest schema triggers, on regulated policycategories and on euaiactannexiii, both bind the buyer's plan object and fire before a plan is synced, so a seller that never calls checkgovernance never meets either one.

Governance operations in AdCP 3.1.13

AdCP 3.1.13 routes 22 operations through governance, more than it gives any other area. The x-status field on each request schema marks four of them experimental.

| Sub-protocol      | Operations                                                                                                                       | Count | x-status in 3.1.13 |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----- | -------------------- |
| Campaign          | syncplans, checkgovernance, reportplanoutcome, getplanauditlogs                                                   | 4     | experimental         |
| Property lists    | create/get/update/delete/listpropertylists                                                                       | 5     | stable               |
| Collection lists  | create/get/update/delete/listcollectionlists                                                                     | 5     | stable               |
| Content standards | create/get/update/listcontentstandards, calibratecontent, validatecontentdelivery, getmediabuyartifacts | 7     | stable               |
| Creative          | getcreativefeatures                                                                                                          | 1     | stable               |

Only checkgovernance stands between a buy and its execution, "the universal validation gate". The other eighteen operations manage reusable lists; calibratecontent and validatecontentdelivery do not gate execution. AdCP does not treat "governance agent" as a single role either: docs/protocol/required-tasks.mdx heads three sections "Governance agent", then switches to "Content standards agent" and "Creative governance agent" for the other two sub-protocols.

Policy categories that force human review

The live constraint is an if/then on the plan object in dist/schemas/3.1.13/governance/sync-plans-request.json: put fairhousing, fairlending, fairemployment or pharmaceuticaladvertising in policycategories and humanreviewrequired becomes required with const: true. A second if/then does the same for policyids containing euaiactannexiii, and no prose page in the repository mentions it.

The authoritative policy category list is that enum, and the prose pages disagree with it: docs/governance/annex-iii-obligations.mdx and docs/reference/whats-new-in-v3.mdx give four categories, while docs/trust.mdx gives three, omitting pharmaceuticaladvertising.

Governance in AAMP

No AAMP repository names the role. iab-agentic-primitives v0.5.0 defines DecisionRecord.json, "a durable record of why a money/state decision was made", alongside CreativeApproval and ConsentContext, and none of the 13 operations in spec/openapi/iab-agentic-api.yaml references any of the three types.

The one gate AAMP operates is trust status inside the reference seller agent, a five-value enum capping a buyer's access tier, which governs who transacts rather than what may be bought. Both protocols are measured against the same question in what agentic ad protocols don't standardize.

---

# Hashed Identifier

Source: https://adtechglossary.com/signals/hashed-identifier/

A hashed identifier is a SHA-256 digest of a normalized email address or E.164 phone number sent in place of the cleartext value, which AdCP classifies as pseudonymous PII rather than anonymous or privacy-preserving.

A hashed identifier is a SHA-256 digest of a normalized email address or phone number, sent in place of the cleartext value. The practice is older than either protocol: buyers and sellers have exchanged hashed email for years to match a customer list against a seller's audience without moving the addresses themselves. AdCP defines two such fields, and the buyer does the normalizing.

| Field          | What the buyer must hash                          | Schema pattern   |
| -------------- | ------------------------------------------------- | ---------------- |
| hashedemail | Lowercase, trimmed email address                  | ^[a-f0-9]{64}$ |
| hashedphone | E.164-formatted phone number, e.g. +12065551234 | ^[a-f0-9]{64}$ |

The buyer hashes its customer list, the seller hashes the identifiers it already holds, and the people whose digests collide are the matched audience. The share the seller finds is the match rate.

Match rates depend on both sides normalizing identically before hashing. The pattern is lowercase hex, so a case-mismatched hash fails validation instead of silently failing to match, and the normalization rule itself sits in the field description rather than in a partner integration guide.

Both fields also sit on core/user-match.json, which attributes conversions through logevent, so the term reaches measurement as well as the audience-versus-signal question.

A hashed identifier is still personal data

The hashedemail description says so in the schema:

 Pseudonymous PII, not anonymous — the email namespace is small enough that an unsalted SHA-256 is recoverable via precomputed dictionaries. Treat as PII for retention, consent, and access-control purposes.

The set of real email addresses is small enough to enumerate, so tables of addresses and their hashes are cheap to build and already exist. Against such a table an unsalted digest is a lookup key for the address rather than a barrier to it.

The normative version is in privacy-considerations.mdx:

 Operator documentation, data-processing agreements, and compliance disclosures MUST NOT describe unsalted hashedemail or hashedphone as "privacy-preserving", "anonymous", or "de-identified". Hashing is data minimization at the transport boundary, not anonymization.

AdCP's privacy documentation names the specific GDPR obligations it considers engaged. Art. 15 access and Art. 17 erasure both apply: a request arrives as an email address and has to resolve to records keyed by that address's hash. Art. 11 relieves only a controller that genuinely cannot identify the person, and AdCP's gloss is that "that bar is higher than 'we hashed it'". Matching against a seller's graph is a processing activity in its own right, with its own lawful basis to find.

Salting and HMAC

privacy-considerations.mdx names four primitives that would qualify as privacy-preserving: salted hashing with operator-held secrets, HMAC with a shared secret, private set intersection, an attested TEE. None is in the protocol, and implementers who need one are told to layer it on top.

Salting defeats the dictionary attack. It also defeats the match, unless both parties hold the same salt — which makes it a key-management problem, and AdCP specifies no key exchange. On the TEE option, AdCP's position is that attestation "does not eliminate the disclosure but it closes the offline-retention vector".

Cleartext identifiers AdCP accepts

| Carrier                                      | What it accepts                                                | Caveat in the spec                                                        |
| -------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------- |
| audiencemember.externalid                | Cleartext CRM or loyalty ID, required on every member          | buyer-assigned and buyer-scoped; the seller cannot resolve it to a person |
| usermatch.clientip + clientuseragent | Cleartext IP and UA, and that pair alone satisfies the anyOf | "for probabilistic matching"                                              |

Five anyOf branches sit on user-match.json. Two are the hashed fields. One is clientip plus clientuseragent, accepted in cleartext as an alternative to either hashed field and described only as probabilistic matching; the privacy page never mentions clientip.

A third cleartext CRM identifier is declared with nowhere to put it. getadcpcapabilities lets a seller advertise that it matches platformcustomerid, an ID in a namespace it already shares with the buyer, and describes buyers putting those values into AudienceMember.identifiers. There is no identifiers container: the properties on audience-member.json are flat, and the field appears in exactly one schema file in the release.

known-limitations.mdx says "If you need cleartext PII on the wire, AdCP is not the right carrier", then scopes the claim to email and phone.

What counts as a UID

Every audience member needs an externalid, plus at least one of hashedemail, hashedphone or uids[]. The uid-type enum behind that third branch holds rampid, rampidderived, id5, uid2, euid, pairid, maid, hashedemail, publisherfirstparty, worldidnullifier and other. AdCP's glossary lists six of them, omitting hashedemail, and calls a UID "an already-resolved, privacy-preserving user token from an identity graph", a description the privacy page forbids for hashedemail, which is itself one of the uidtype values.

worldidnullifier carries a narrower claim than its name suggests: an unlinkable pseudonym scoped to one relying party, which "carries NO personhood or age assertion on its own". Composite identifiers are not modelled at all: the hashed-name-plus-postcode pattern Google Customer Match uses has no field here and is "not yet standardized — use the ext field for platform-specific extensions", so a buyer that matches on name and postcode is outside the schema.

In Trusted Match, identities[].usertoken is documented as something the buyer cannot reverse to PII, while its sibling identities[].uidtype $refs the enum whose hashedemail entry says the opposite.

The privacy-architecture page patches that in prose rather than in the enum, telling publishers that strongly-reidentifying tokens "carry higher re-identification risk than opaque provider IDs" and that including them is "a deployment decision, not a default". It tells buyers to prefer opaque provider IDs when a request carries several identity types, so that a misbehaving router discarding everything except the hashed email gains nothing by doing so.

Hashed identifiers in AAMP

AAMP's control-plane schemas define no per-person identifier. The one place a person is hashed is the identity block in agentic-audiences: namespace and valuehash, both bare strings with no constraint, plus a confidence number. The schema names no algorithm and sets no pattern, and requires neither the identity block nor the consent block beside it, so a conformant message can carry a person-hash with no consent attached. That repository is self-labelled Draft v0.1, "LiveRamp's initial proposal", with a schema $id still pointing at the pre-donation LiveRamp/user-context-protocol repository.

AAMP regulates consent at the deal instead of at the identifier. ConsentContext.json carries GPP and TCF strings, usprivacy, and an SGP diligence status, all "carried opaque: no decoding/vendor-list validation is claimed." The one person-level ID it moves is inherited: OpenRTB v2's user.eids and buyeruid are vendored whole into the Agentic RTB Framework, and the framework adds no hashing rule of its own.

---

# MCP and A2A

Source: https://adtechglossary.com/concepts/mcp-and-a2a/

MCP and A2A are general-purpose agent transports with no advertising semantics: AdCP requires a sales agent to support at least one, AAMP adds REST over OpenDirect 2.1, and neither protocol requires an agent to declare which transport it speaks.

MCP and A2A are general-purpose agent transports. MCP, the Model Context Protocol, is Anthropic's specification for how a model calls an external tool. A2A, Agent2Agent, covers how autonomous agents send each other messages and run long tasks; Google donated it to the Linux Foundation, and a technical steering committee governs it now.

Both define message framing and task lifecycle only. Operations, field names and obligations come from AdCP and AAMP. Supporting MCP or A2A does not by itself imply support for any AdCP operation, because neither transport specification defines advertising operations.

Neither stack requires an agent to say which of the two it speaks: AdCP has no general field for it, and AAMP has an unconstrained one. AdCP and AAMP also target different major versions of A2A, so a buying client reaching both parses both agent card shapes.

With no declaration to read, the transport has to be probed. /.well-known/agent.json first: a card that parses means A2A, and the card's shape says which A2A, root url for v0.3 or supportedInterfaces[] for 1.0. No card, and an MCP session carries protocolVersion on initialize. getadcpcapabilities over whichever one answered confirms the domains and says nothing about the transport underneath. Neither specification defines this sequence.

Transport requirements in each stack

AdCP requires a sales agent to support MCP or A2A; which one is the implementer's choice. Its required-tasks page reads: "Sales agents MUST also support at least one transport (MCP or A2A) and declare mediabuy in supportedprotocols." supportedprotocols lists AdCP domains (mediabuy, signals, governance, sponsoredintelligence, creative, brand, measurement), and a transport never appears in it.

|                        | MCP                                                 | A2A                                                        |
| ---------------------- | --------------------------------------------------- | ---------------------------------------------------------- |
| Framing                | JSON-RPC 2.0 over Streamable HTTP, responses as SSE | message/send carrying a DataPart of { skill, input } |
| Discovery              | tools/list                                        | Agent card                          |
| Typed response sits at | Tool result / structuredContent                   | task.artifacts[0].parts[0].data                          |
| Conversation context   | Manual, the client passes contextid              | Protocol-managed                                           |
| Webhooks               | pushnotificationconfig in the tool arguments    | Native PushNotificationConfig                            |
| Version handshake      | MCP protocolVersion on initialize               | None                                                       |

AdCP's protocol-comparison page states that the two "provide identical AdCP capabilities using the same unified status system. They differ only in transport format and async handling". The difference lands in the code the implementer owns: under MCP the client threads contextid through every call by hand, and under A2A the protocol carries it.

MCP's protocolVersion versions the MCP wire and says nothing about the AdCP payload riding inside it, and A2A offers no initialize to hang a handshake on, so adcpversion travels in the payload instead. No conformance rule sets an MCP version floor, though structuredContent needs MCP 2025-03-26 or later, a requirement recorded in AdCP's operating guidance rather than in its conformance rules.

AdCP's MCP servers publish tools with empty inputSchema objects, so a client takes its request shapes from the published schema files under dist/schemas/3.1.13/ rather than from tools/list. The calling-an-agent page says those servers no longer publish per-tool parameter schemas, so every tool comes back as {type: 'object', properties: {}}; the known-limitations page defers a runtime getschema tool on the grounds that the decision "depends on MCP tools/list continuing to carry inputSchema" and warns that stripping it "would create the exact wire-surface gap getschema was meant to close."

Trusted Match is a serving-path surface rather than a buying transport, and it runs over "JSON over HTTP/2 POST. All implementations MUST use this transport".

AAMP's three transport paths

AAMP has three paths, and the rule for picking between them sits in a reference implementation's docs rather than in a specification. buyer-agent's protocols document, which governs that framework's own tool calls, makes MCP "the default for all CrewAI tool operations", reaches for A2A on "exploratory discovery and complex negotiations where natural language interpretation adds value", and leaves REST over OpenDirect 2.1 to operator dashboards and legacy integrations.

agentic-direct hardcodes protocolVersion: '0.3.0' in server/src/a2a/agent-card.ts. ARTF, the Agentic Real Time Framework, appears only in the RTB path and leads with gRPC: one service, RTBExtensionPoint.GetMutations, on port 50051, plus an MCP tool extendrtb on 50052 as the standalone secondary. The AAMP hub README does not mention MCP, A2A or transport.

Which transport an agent speaks

getadcpcapabilities is the first call made against any AdCP agent. Its response schema requires exactly two things, adcp and supportedprotocols, and supportedprotocols is the domain list. The only place the transport vocabulary is constrained is the Sponsored Intelligence surface, inside an optional block. A sales agent must support MCP or A2A, but unless it also offers Sponsored Intelligence there is no field in which to say which one it chose.

AAMP defines capabilities.protocols but constrains nothing in it: iab-agentic-primitives/spec/jsonschema/Agent.json declares the field as {"items": {"type": "string"}, "type": "array"} — no enum, nothing pinning those strings to MCP or A2A or to anything. capabilities is absent from Agent.required, so a card with no declared transport validates clean.

|                        | AdCP 3.1.13                                       | AAMP                                                                                                                                    |
| ---------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Transport required?    | Yes, MCP or A2A                                   | Not required                                                                                                                            |
| Field that declares it | sponsoredintelligence.endpoint.transports[]    | Agent.capabilities.protocols                                                                                                          |
| Constrained?           | enum: ["mcp", "a2a"], minItems: 1             | Bare array of string                                                                                                                    |
| Required?              | Only if the agent declares Sponsored Intelligence | No, capabilities is absent from Agent.required                                                                                      |
| What the API binds     | Endpoints are deployment-specific                 | POST /a2a/jsonrpc, GET /.well-known/agent.json, no /mcp path, from the shared OpenAPI rather than from a specification obligation |

AAMP's artifacts point three ways: the shared OpenAPI binds A2A and REST across 13 operations with no MCP path in it, all four golden vectors declare ["a2a"], and the reference agents' docs call MCP the default.

A2A version targets

AdCP targets A2A 1.0, with v0.3 supported "through the compatibility period". 1.0 replaces the root url and protocolVersion with a supportedInterfaces[] array carrying per-interface url, protocolBinding and protocolVersion, and drops the kind discriminator that v0.3 puts on every Part.

agentic-direct hardcodes 0.3.0, the tier AdCP files under compatibility. Neither AdCP's docs nor the A2A project's own site gives that compatibility period an end date, so a client reaching both stacks parses both card shapes. Backward compatibility is "not enabled by default", and a v0.3 client hitting a 1.0-only server fails unless that server opted in.

AdCP's protocol-comparison page shows A2A examples carrying "kind": "text" and "kind": "data", the v0.3 form, and names no A2A version. Its industry overview credits A2A to Google as maintainer.

Common confusions

An A2A Task.status.state of completed describes the call, not the buy. A completed A2A task can come back carrying a rejected artifact, with a reason and suggestions[]. A client that reads the task state as the commercial outcome records media buys the seller never agreed to.

AdCP's polling surface reuses the tasks/ names from MCP and A2A, and the wire shapes differ, so the shared names do not indicate a shared message format.

---

# Media Buy

Source: https://adtechglossary.com/media-buying/media-buy/

In AdCP, a media buy is the purchased-campaign object created by create_media_buy, carrying the total budget, lifecycle status, an optimistic-concurrency revision and an array of packages.

A media buy is the object AdCP produces when a buyer commits to spend: money and lifecycle on the buy, inventory one level down in [packages[]](/media-buying/package/). createmediabuy mints one; getmediabuys and updatemediabuy read and edit it. The canonical schema is dist/schemas/3.1.13/core/media-buy.json, titled "Represents a purchased advertising campaign": 17 properties, 6 required.

AdCP's own glossary describes it more broadly, as "a complete advertising campaign containing packages, budget, targeting, and creative assets". The object carries neither targeting nor creative fields; both live on the package.

How a media buy is created

createmediabuy takes the total budget as {"amount": 50000, "currency": "USD"}, requires both halves and both flight dates, and carries the packages inline. The seller mints mediabuyid and returns the buy.

The request also accepts a proposalid: a proposal in the committed state means firm pricing with inventory reserved until its expiresat, so a buyer that has already agreed terms passes the proposal rather than re-stating it.

Required fields and response shapes

The six required fields in core/media-buy.json are mediabuyid, status, confirmedat, totalbudget, packages and revision. The other eleven are optional — account, health, impairments, rejectionreason, cancellation, context, invoicerecipient, creativedeadline, createdat, updatedat, ext — so revision is guaranteed on every buy and the timestamps are not.

confirmedat is required but may be null: the key is present on every media buy and carries null until "seller commitment occurs in deferred/manual approval flows". A client that treats a missing key and a null value alike reads a buy still awaiting approval as committed.

No operation payload in the release refers to core/media-buy.json. Only the file's own $id and the schema registry index point at it, each of the three operations that return a media buy inlines its own object, and nothing marks core/media-buy.json deprecated.

| Shape                             | Where it lives      | Properties | Required |
| --------------------------------- | ------------------- | ---------- | -------- |
| core/media-buy.json             | registry index only | 17         | 6        |
| getmediabuys → mediabuys[] | inline              | 25         | 7        |
| createmediabuy success        | inline              | 17         | 4        |
| updatemediabuy success        | inline              | 14         | 2        |

The create response drops six core fields (cancellation, createdat, health, impairments, rejectionreason, updatedat) and stops requiring status and totalbudget. updatemediabuy guarantees mediabuyid and revision and nothing else. get-media-buys-response.json is a strict superset of core and it is the shape that lands in the handler; its eight extra fields are currency (a required ISO 4217 code, the denomination totalbudget lacks), starttime and endtime derived from the packages, availableactions and validactions, statusasof for when the seller last refreshed status, and the on-request history and webhookactivity.

availableactions tells a buyer which operations this buy will accept now and on what terms. Each entry carries a mode of selfserve, conditionalselfserve or requiresapproval, so a client knows before it calls whether a change needs seller approval. validactions is the same list as bare strings, carries a "Removed in 4.0" note, and consumers MUST prefer availableactions.

Currency and flight dates

core/media-buy.json types totalbudget as {"type": "number", "minimum": 0} and carries no currency property, while the request requires a currency and the response schema states the flattening: "this response field is the flattened scalar amount, with currency promoted to the sibling currency field." That sibling is required on getmediabuys and absent from core, so a budget modelled off core alone has no denomination. AAMP models the same money as a Money object in integer micro-units, on a schema that bans float for money outright: "IEEE 754 floating point is non-deterministic for money math."

createmediabuy requires both flight dates and neither appears on core/media-buy.json, while core/package.json still says of its own starttime that "When omitted, the package inherits the media buy's starttime."

Status and health

enums/media-buy-status.json lists seven values: pendingcreatives, pendingstart, active, paused, completed, rejected, canceled. There is no draft. A media buy does not exist until createmediabuy succeeds, so planning happens against products and proposals.

health runs on a second axis: ok or impaired, aggregated from impairments[] and independent of status — "Orthogonal to status — a paused, pending, or active buy can each be impaired." impairments[] is scoped one level down, "open impairments — upstream dependency state changes that affect delivery for at least one package on this buy", so one poll of the buy surfaces downstream degradation without walking every package.

health is optional on core/media-buy.json, omitted from the create response, and described as "Always set" in the enum file. It carries "default": "ok" with a description scoped to "when impairments[] is empty", so an absent health reads as healthy rather than as unreported. Nothing ties rejectionreason to rejected or cancellation to canceled either, so both may be absent on a conformant payload.

Updating a media buy

update-media-buy-request.json carries 16 properties and requires three: idempotencykey, account, mediabuyid. Pause and resume run through paused, canceled is "irreversible" and a seller MAY refuse it with NOTCANCELLABLE, both flight dates move, and newpackages[] adds inventory mid-flight against sellers advertising addpackages. The update request carries no totalbudget; the buy's money is fixed at create.

revision is the "monotonically increasing optimistic concurrency token", minimum: 1, and the only field present on all four shapes. On the update request it is optional, "for backward compatibility", so a seller owes a CONFLICT only when the client supplies it. The idempotencykey is required on the same request and stops a retry from booking the same change twice.

AAMP's Order

Order, defined in spec/jsonschema/Order.json as a "Campaign container (insertion order) holding one or more lines", is derived from IAB OpenDirect 2.1 and sits in a library that is unreleased, against AdCP's published 3.1.13.

spec/openapi/iab-agentic-api.yaml, the AAMP wire contract, has 13 paths and never names Order. The seller agent, the only implementation that creates orders, exposes POST /api/v1/orders with a body of three optional fields and a 200 response schema of {}.

|                            | AdCP media buy                         | AAMP Order                                                                   |
| -------------------------- | -------------------------------------- | ---------------------------------------------------------------------------- |
| Properties / required      | 17 / 6                                 | 14 / 6: orderid, accountid, name, budget, startdate, enddate |
| Flight dates on the object | absent                                 | startdate, enddate, both required                                      |
| Budget                     | totalbudget, a bare number          | budget, a Money object in integer micros                                 |
| Children                   | packages[] embedded by value         | Line objects referencing orderid                                        |
| Status vocabulary          | 7 values, no draft, spelt canceled | 11 values, has draft, spelt cancelled                                    |
| Concurrency token          | revision, required                   | none                                                                         |
| Deal linkage and consent   | neither on the object                  | optional dealid and consentcontext               |
| Referenced by an operation | no                                     | no                                                                           |

---

# Negotiation Round

Source: https://adtechglossary.com/negotiation/negotiation-round/

A negotiation round in AAMP is one recorded offer-and-counter exchange between a buyer agent and a seller agent, carrying both prices, the seller's action and the concession taken, while AdCP has no negotiation protocol.

A negotiation round is one recorded offer-and-counter exchange between two agents, appended to a persisted history. AAMP, IAB Tech Lab's Agentic Advertising Management Protocols, defines it as NegotiationRound in spec/jsonschema/Negotiation.json and describes it in one sentence: "A single offer/counter round in a negotiation." A negotiation action is the verb a message carries: accept, counter, reject or finaloffer. The library holding both is unreleased, at version 0.5.0.

Commercially the exchange is narrow. The seller's floor price and bargaining strategy stay on the seller's side, the buyer's target and walk-away stay on the buyer's, and the only things that cross are the two prices, the verb and the concession the seller has already given.

How a round is exchanged

What is under negotiation is a quote or a proposal, and the buyer agent moves first. It sends a NegotiationMessage naming the quote or proposal, an action and a price. The seller answers with a round record holding both prices, the action it took and the concession that action represents. Rounds accumulate on a Negotiation container, which requires only negotiationid and whose status runs active, accepted, rejected, expired. Accept the price and the quote becomes a deal.

| Field                       | Required | What it holds                                     |
| --------------------------- | -------- | ------------------------------------------------- |
| roundnumber              | Yes      | Sequential, minimum: 1                          |
| buyerprice               | Yes      | Money, what the buyer offered this round        |
| sellerprice              | Yes      | Money, what the seller countered or accepted at |
| action                    | Yes      | NegotiationAction                               |
| concessionpct            | No       | Seller concession this round, default 0.0         |
| cumulativeconcessionpct | No       | Total seller concession so far, default 0.0       |
| rationale                 | No       | Free text, default empty string                   |
| timestamp                 | No       | Date-time, defaulted server-side                  |

Both prices are Money, integer micros at a million to the unit, and the schema is blunt about why: "Float is BANNED on the wire for money... that defect must not be fossilized into the spec." The seller agent's integration doc types both prices as float anyway. The one filled-in history the specification ships, in Negotiation.golden.json, is two rounds long: a counter, then an accept. No floor price appears anywhere in it.

The four actions

NegotiationAction is a four-value enum. The enum exists because a price once shipped with no verb attached: NegotiationMessage.json blames its missing default on "the action-less bare-price payload that caused the historical 422".

| Action        | Must carry a price | Ends the negotiation |
| ------------- | ------------------ | -------------------- |
| counter     | Yes                | No                   |
| finaloffer | Yes                | No                   |
| accept      | Optional echo      | Yes                  |
| reject      | Must not           | Yes                  |

TERMINALACTIONS in protocol/negotiation.py is a frozen set of two, accept and reject, with the comment "finaloffer is NOT terminal — it invites exactly one more response." The reference seller agent allows more than one: its engine leaves the negotiation active after a finaloffer ("COUNTER and FINALOFFER keep status as 'active'") and its router sends both priced actions down one path, so a buyer can answer as often as its round budget allows.

What the schema enforces

NegotiationMessage is the buyer's move. It requires idempotencykey and action, and carries buyerprice, rationale, plus whichever of negotiationid, quoteid or proposalid identifies what is being negotiated. When negotiationid is absent, the message opens a new negotiation on the referenced quote or proposal.

The schema checks nothing else. The price grammar sits in a description string where no validator will reach it — "REQUIRED for 'counter'/'finaloffer'; optional echo on 'accept'; omitted on 'reject'" — with no if, allOf, oneOf or dependentRequired behind it. The specification's own golden vectors bear that out: both of the vectors it marks invalid validate against NegotiationMessage.json. The rule is enforced in one place only, a @modelvalidator in the reference Python package, whose README tells implementers to "conform to the spec, not to this package". reject inherits the same gap: the round record wants a buyerprice on every round and the message that walks away is forbidden to send one, so negotiationservice.py falls back to the seller's price and a walk-away is persisted as the buyer having offered the seller's own number, while the other mapping path, contractmappers.py, records $0.00. No golden vector covers a reject round.

The endpoint ignores two fields the wire requires. POST /api/v1/negotiations/messages never reads idempotencykey, though the same seller honours one for deal booking, and it never reads roundnumber, so the contention error it documents cannot be raised.

Round and concession limits

The schema defines no round limit, no concession ceiling and no lifetime, though status can reach expired. The numbers belong to the reference seller agent, which gives a public buyer three rounds and an 8 percent cumulative concession ceiling and an advertiser buyer six rounds and 20 percent. Per-round caps for all four tiers and a worked walkthrough sit on AAMP Explorer. On the other side, the buyer runs its own clock and quits when "seller hasn't moved since last round".

The container states why those numbers are missing: the seller's floor price, base price, strategy and concession limits are "seller-internal guardrails ... deliberately absent from the shared schema", and even roundsremaining is optional, "Rounds left before the seller walks away, if disclosed".

The reference seller's documentation contradicts itself about whether public and seat tier buyers may negotiate at all: one page gives both a strategy, at three rounds and four, another marks public "No" and seat "Limited", its default rate card sets negotiationenabled=False for both, and the buyer agent's guide says the two tiers "cannot" negotiate. The shipped code lets them. negotiationengine.py maps every tier to a strategy with no gate above it, neither it nor the service reads negotiationenabled, and any unmapped tier falls through to the most aggressive strategy. Which tier a buyer is granted in the first place is capped by its trust status.

Negotiation in AdCP

core/product-allowed-action.json reserves a slot for one: termsref, an "Optional pointer into buy-terms negotiation" that "accepts any string for now" pending a buy-terms RFC. That RFC has not shipped, and AdCP's FAQ is ahead of it, telling buyers they can require fee disclosure "through buyterms", a field that appears nowhere in dist/schemas/3.1.13/.

Otherwise AdCP 3.1.13 defines no negotiation surface and says so in its own schema text. core/insertion-order.json: "These are read-only summaries, not negotiation surfaces — deal terms live on products and packages." None of the 64 published operations makes or answers an offer, and no schema file has "negoti" in its name. Where the word appears it is a planning-layer concept rather than an offer, and in dispute the documented recovery is to "negotiate offline".

---

# OpenDirect 2.1

Source: https://adtechglossary.com/concepts/opendirect/

OpenDirect 2.1 is IAB Tech Lab's REST standard for booking guaranteed ad inventory, and AAMP's control plane inherits its Account, Order, Line and Product objects, though no AAMP repository implements more than 13 of the standard's 23 objects.

OpenDirect 2.1 is IAB Tech Lab's REST standard for booking guaranteed and reserved advertising inventory: the direct deals that used to move by email and spreadsheet. It defines 23 objects covering accounts, orders, inventory, creative and reporting. It predates agentic buying and defines no agent behaviour.

AAMP is built on it because IAB Tech Lab already owned a ratified object model for the transaction AAMP's control plane automates, so the agent repositories started from Account, Order, Line and Product rather than inventing four nouns of their own.

The object graph is a booking workflow. Accounts own Orders, Orders hold Lines, Lines book Products. An Assignment attaches a Creative to a Line, and a ChangeRequest amends one already booked. The nesting is in the path: /accounts/{id}/orders/{id}/lines.

Version 1.0 shipped in January 2015 and 2.1 in April 2024. The standard's page on iabtechlab.com is stamped "last updated 8 July 2024", lists no implementers and runs no conformance programme, and it does not mention agentic work or AAMP.

AAMP's inheritance from OpenDirect

seller-agent's README claims it books "using IAB Tech Lab standards (OpenDirect 2.1, Deals API v1.0, sellers.json)". buyer-agent lists "REST (OpenDirect 2.1)" as one of three transports, the one for "operator dashboards and legacy integrations", with MCP as the default. The AAMP hub repository, a README index and a licence file, makes no reference to OpenDirect, OpenRTB or AdCOM.

The copy vendored into agentic-direct keeps the standard's own metadata block, naming OpenDirect v2.1 Final under Creative Commons Attribution 3.0 and referencing AdCOM, OpenRTB and the DP-AA DOOH Extension, with the example base URL https://opendirect.example.com/v2.1 still in place.

Three implementation subsets

agentic-direct/opendirect.json defines 13 OpenDirect. schemas, and its 2.1.0 is OpenDirect's version number rather than its own. (The file is an MCP server manifest, keyed on schemas, tools and resources; the repository's README describes it as an OpenAPI 3.0 schema and it has no paths key.) iab-agentic-primitives is the schema library both reference agents import, v0.5.0 and unreleased, and it inherits more than the shapes: its Order "merges the buyer's OpenDirect Order with the seller's ExecutionOrder", and its AvailsRequest notes that "spec-named fields use the OpenDirect 2.1 all-lowercase wire names". seller-agent is the running reference server, 74 OpenAPI paths, and the only one that answers a request. All three are IAB Tech Lab repositories, and none is designated as the one to build against.

| OpenDirect 2.1 object group                                                                     | opendirect.json manifest | iab-agentic-primitives    | seller-agent REST             |
| ----------------------------------------------------------------------------------------------- | -------------------------- | --------------------------- | ----------------------------- |
| Booking chain: Account, Order, Line, Product, Creative, Assignment, Organization, ChangeRequest | all 8                      | all 8                       | Product, Order, ChangeRequest |
| Avails and search: Avails, AvailsStatus, ProductAvailsSearch, ProductSearch, ProductTargeting   | none                       | Avails, ProductAvailsSearch | POST /products/avails       |
| Inventory detail: Placement, AdUnit                                                             | both                       | neither                     | neither                       |
| Party detail: Address, Contact, AdvertiserBrand                                                 | Address, Contact           | none                        | none                          |
| Comms and reporting: Message, Stats, ProviderData, EID, UID                                     | Message                    | none                        | none                          |
| Objects present                                                                                 | 13 of 23                   | 10 of 23                    | 4 of 23                       |

The first two columns count schema definitions; the third counts entities with a REST path. AdvertiserBrand, ProductSearch, AvailsStatus, ProductTargeting, ProviderData, Stats, EID and UID appear in none of the three, which is the reporting and identity half of the standard.

The manifest carries Address and Contact but no Avails or search objects; iab-agentic-primitives carries Avails and ProductAvailsSearch but no party-detail objects. Neither body publishes a crosswalk of what survived.

Conformance testing runs to one file. seller-agent/tests/unit/testopendirectwireconformance.py covers a single endpoint, POST /products/avails, and what it pins is spelling: productid, startdate and enddate have to parse under their lowercase spec names, and the camelCase aliases must not be accepted or emitted. It pins lowercase because the source document ships both: OpenDirect's Account attribute table is all lowercase, while the normative /accounts example returns "Accounts", "AdvertiserId" and "Id" in PascalCase, plus an AgencyId the table never defines. Three of that endpoint's six request fields are spec-named; requestedImpressions, budget and targeting have, the docstring says, "no spec name to converge to".

What OpenDirect does not define

Negotiation, quote, access tier, trust status, agent card and embedding appear nowhere in the standard, which is why 14 of the 22 core primitives in iab-agentic-primitives have no OpenDirect ancestor by name, Agent, Quote, Negotiation and MediaKit among them.

Inheriting the standard also carried a cost on money typing. OpenDirect 2.1 carries price as a decimal float. iab-agentic-primitives numbers its contested design calls in the schema descriptions, and FD-11 bans float money on the wire, because binary floating point cannot hold decimal money exactly; the ban is an executable check in src/iabagenticprimitives/conformance/standards.py. Across four Avails schemas, price "stays a float per the OpenDirect 2.1 decimal dialect".

OpenDirect and AdCP

AdCP's published docs and schema registry never mention OpenDirect, while naming IAB Tech Lab in dozens of files and referencing OpenRTB, AdCOM and VAST throughout. Its documentation tooling does index the OpenDirect repository, alongside roughly 28 others; the objects AdCP publishes are defined independently of it.

Media Buy and Package are where Order and Line went, and the two stacks line up object by object on the terminology lookup.

Common confusions

OpenDirect and OpenRTB do not sit in the same plane. OpenDirect belongs to AAMP's control plane, where a human would once have signed an insertion order; OpenRTB 2.6 belongs to the agentic RTB framework at serve time, imported as com/iabtechlab/openrtb/v2.6/openrtb.proto. AAMP is credited to "OpenRTB, AdCOM and OpenDirect", three inheritances in three different planes, and the full stack comparison separates them.

---

# Package

Source: https://adtechglossary.com/media-buying/package/

An AdCP package is one product inside a media buy, the equivalent of a line item in an ad server, carrying its own budget, pacing, flight dates, format selection and creative assignments.

A package in AdCP is one product inside a media buy, and it is what other ad systems call a line item. dist/schemas/3.1.13/core/package.json describes itself in one line: "A specific product within a media buy (line item)". Each package names a single product and carries its own budget, pacing, flight dates, format selection, targeting overlay and creative assignments, so a campaign running three products is one buy holding three packages.

What a package carries

| Group             | Fields                                                                                                                            | Note                                                                                                                             |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Identity          | packageid, productid                                                                                                        | Only packageid is required                                                                                                    |
| Money             | budget, pricingoptionid, bidprice, pricebreakdown, impressions                                                      | bidprice is "the exact bid/price to honor unless the selected pricing option has maxbid=true", in which case it is a ceiling |
| Pacing and flight | pacing, starttime, endtime, paused, canceled, cancellation                                                          | pacing is even, asap or frontloaded, and even is the documented default                                               |
| Creative          | formatids, formatoptionrefs, formatkind, params, creativeassignments, formatidstoprovide, creativedeadline | Three selectors may co-exist; precedence is defined in prose, not in the schema                                                  |
| Targeting         | targetingoverlay, catalogs                                                                                                   | Restriction overlays only                                                                                                        |
| Commitments       | measurementterms, performancestandards, committedmetrics, optimizationgoals                                           | committedmetrics is "the binding reporting contract for this package"                                                         |
| Bookkeeping       | agencyestimatenumber, context, ext                                                                                        |                                                                                                                                  |

Three of those fields decide what the package spends. budget is a plain number in the media buy's currency, pacing sets how it is spent across the flight, and bidprice sets the unit price — fixed, unless the selected pricing option carries maxbid=true, in which case the same number is a ceiling.

Targeting is an overlay, not the buy

core/targeting.json states the division: "Optional restriction overlays for media buys. Most targeting should be expressed in the brief and handled by the publisher." The buyer describes the audience in the brief, the seller selects the inventory, and the package layer only narrows what the seller selected. Its 28 properties, none required, are functional restrictions: geography, age verification, device platform, language, keyword targeting.

Three are marked deprecated: true: axeincludesegment, axeexcludesegment and signaltargeting, whose replacement signaltargetinggroups is where grouped include and exclude composition moved. audienceinclude and audienceexclude take IDs minted by syncaudiences on the same seller account, and those IDs do not travel to another seller — the practical half of the audience versus signal distinction.

How a package is created

AdCP 3.1.13 ships four package schemas with different required-field sets.

| Schema                                 | Direction                | Properties              | Required         | Accepts unknown keys |
| -------------------------------------- | ------------------------ | ----------------------- | ---------------- | -------------------- |
| core/package.json                    | seller to buyer          | 29                      | 1 (packageid) | yes                  |
| media-buy/package-request.json       | buyer to seller          | 24                      | 3                | yes                  |
| media-buy/package-update.json        | buyer to seller          | 21, 7 of them forbidden | 1                | yes                  |
| trusted-match/available-package.json | seller to match provider | 5                       | 3                | no                   |

The one sent on createmediabuy is package-request.json, and three fields make a complete package:

A package is created by reference: the buyer names a product and the seller fills in whatever that product already implies — pricing, formats, measurement terms, allowed actions. The request schema has no packageid property at all, because the seller mints the ID and returns it on the 29-property core/package.json object, which a buyer reads and never constructs.

required is not the whole obligation. productid sits outside required, but its description carries a MUST: "sellers MUST echo the request package's productid on every response package object that represents that requested package". One level up, core/media-buy.json lists packages in required but sets no minItems, so a media buy with zero packages validates clean.

updatemediabuy uses both request shapes in a single payload. Existing packages go through packages[] as package-update objects, new ones through newpackages[] as full package-request objects. A package added mid-flight is a create, so its immutable fields are set then and freeze from that point.

available-package.json has five properties and is the only package object in the registry that rejects unknown keys. It is synced to Trusted Match providers, AdCP's serve-time layer, when the buy is created, so a match provider knows which packages exist on it; nothing sends it per request.

Immutable fields after create

package-update.json has a root-level not.anyOf that rejects any payload containing productid, formatids, formatoptionrefs, formatkind, params, capabilityids or pricingoptionid. Its own description calls them "fully-immutable fields" and says the rule is "schema-enforced via the not constraint at the root of this object".

Product, pricing option and every format selector are therefore fixed at create. Changing the creative format on a live package means cancelling it and creating a replacement, which the seller mints as a new package under a new packageid. One rule in that description never made it into the constraint: committedmetrics is append-only, and sellers must reject edits to existing entries.

Format selection

All three selectors can sit on one package and none is required: formatids for "legacy named-format IDs", formatoptionrefs for "structured 3.1+ format option references", and formatkind plus params as the "direct canonical selector". formatkind draws from a 13-value enum: image, html5, displaytag, imagecarousel, videohosted, videovast, audiohosted, audiodaast, sponsoredplacement, nativeinfeed, responsivecreative, agentplacement, custom.

Precedence is defined in the createmediabuy task reference: "Selector precedence is deterministic: formatoptionrefs[] wins when present; otherwise direct formatkind/params is used; otherwise the package defaults to all product options." Deprecated formatids[] is interpreted only on a negotiated legacy compatibility path.

Because that rule lives in a task reference rather than in a constraint, two implementations reading dist/schemas/ alone can disagree about which format was bought, and both payloads validate. The pricingoptionid that comes back carries no echo MUST and is not required on the response, so nothing ties it to the one that went out.

AAMP's Package and Line

AdCP's package maps to AAMP's Line, "Individual product booking within an order (OpenDirect Line)", which says of itself that it "is the only execution unit on the wire". The object AAMP calls Package is something else: a "Curated inventory package for media kit discovery. A curation layer on top of products", carrying isfeatured, seasonallabel, tags and a layer enum of synced, curated or dynamic — a pre-sale object, closer to an AdCP product. The library is unreleased and the AAMP hub README does not list it.

AdCP's package has 29 properties and 1 required. AAMP's Line has 13 properties and 8 required: lineid, orderid, productid, name, startdate, enddate, rate and quantity. AdCP's package requires one field because the seller fills the rest from the referenced product; Line requires eight because it is an OpenDirect booking line that a booking system supplies.

The two objects also diverge below the field names.

- Line.targeting is {"type": "object", "additionalProperties": true}, nullable and defaulting to null, against AdCP's 28 typed properties.
- events/eventtype.values.json defines four pacing events — pacing.snapshottaken, pacing.deviationdetected and two reallocation events — while no property named pacing exists anywhere in spec/jsonschema/.
- Creative binding sits in a separate Assignment object. An AAMP buyer books the line, then makes a second call before anything can run; AdCP keeps creativeassignments[] on the package.

The full crosswalk, object by object, is at AdCP vs AAMP terminology.

---

# Policy Category

Source: https://adtechglossary.com/governance/policy-category/

A policy category in AdCP is a registry-defined regulatory regime declared on a campaign plan, such as fair_housing or children_directed, which resolves to policies the campaign must obey and to attributes it must not target on.

A policy category in AdCP is a regulatory regime declared on a campaign plan: fairhousing, childrendirected, pharmaceuticaladvertising. Categories travel in plan.policycategories on syncplans and resolve to the policies the campaign must obey and the attributes it must not target on. The value space is open by design: "Values are registry-defined category IDs (intentionally freeform strings, not an enum — new categories are added as regulations evolve)." categoryid is pattern-constrained, ^[a-z][a-z0-9]$, and never enumerated, so the registry can add euaiactannexiii without a protocol release.

The registry's usfhatargeting.json gives as its first failing exemplar a landlord excluding "families with children" from rental advertising, citing the 2019 HUD v. Facebook settlement. That is the kind of campaign the fairhousing category is declared to catch.

Three senses of "category"

| Field                 | Where it appears                                | What it holds                                                                                                      |
| --------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| policycategories[] | on a plan, in the syncplans request          | freeform registry ids such as fairhousing, defined by governance/policy-category-definition.json              |
| category            | enums/policy-category.json, on a policy entry | regulation or standard; never appears on a plan                                                                |
| categoryid         | on a finding, in a checkgovernance response  | an opaque agent-internal id; buyers and sellers "MUST NOT pattern-match categoryid values against a fixed list" |

What a category definition contains

A registry category definition requires categoryid, name and description. Everything after that is enforcement: restrictedattributes[], requireshumanreview, industries[], relatedcategories[] and regulatoryframeworks[], whose policyids governance agents "use to resolve specific policies from the registry".

The forward lookup from a category to its policies returns nothing: policyids is empty in every seeded category. The reverse link works, by reading the policy files and keeping the ones whose policycategories name the category wanted.

The ten restricted attributes

enums/restricted-attribute.json is a closed ten-value enum that states its own provenance: "Combines GDPR Article 9 special categories with US civil-rights protected classes (FHA familialstatus, ADEA age)."

| Value                                                   | Basis given in the schema                                                         |
| ------------------------------------------------------- | --------------------------------------------------------------------------------- |
| racialethnicorigin                                  | GDPR Article 9(1); US FHA, ECOA, EEOC protected class                             |
| politicalopinions                                    | GDPR Article 9(1); EU DSA Article 26 prohibits targeting on it                    |
| religiousbeliefs                                     | GDPR Article 9(1); US FHA, EEOC                                                   |
| tradeunionmembership, sexlifesexualorientation | GDPR Article 9(1)                                                                 |
| healthdata                                           | GDPR Article 9(1); US ADA. Includes inferred health data from behavioural signals |
| geneticdata, biometricdata                        | GDPR Article 9(1); US GINA, and biometrics where used for identification          |
| age                                                   | US ADEA (40+) for employment, US FHA for housing, EU AVMSD                        |
| familialstatus                                       | US FHA — households with children under 18, pregnancy, or custody of a minor      |

Most of the enum is transcribed from GDPR Article 9. age and familialstatus come from US civil-rights law instead, and their enum descriptions do not mention Article 9; they are also the two the registry and the published documentation handle differently.

The same field is used in both directions. A plan declares restrictedattributes for what must not be targeted, "horizontally across all audience criteria" rather than per selector. A signal definition declares the same field to say what the signal touches, so agents can "structurally match signals against a plan's restrictedattributes without relying on semantic inference".

Beside it on the plan sits restrictedattributescustom, freeform strings such as financialstatus or immigrationstatus. The schema says only that "Governance agents use semantic matching for these." Neither agent is obliged to publish the reading it used, and nothing in the schemas says what happens when the buyer's agent and the seller's agent read immigrationstatus differently. Enum values are compared as a set intersection; custom strings are matched semantically, and the schema does not say how.

Registry validation

age.json and familialstatus.json both fail attribute-definition.json, which declares regulatorybasis as an array of {name, jurisdictions, summary} objects where both files supply a bare string. The registry's linter covers policies/ only, so neither file is gated on the way in. Nothing in the schemas says how strict a loader should be, so a lenient loader accepts the malformed value while a strict loader drops both attributes, and the campaign is then unrestricted on age and familial status.

The published documentation drops the same two attributes. Its category table gives fairhousing 3 attributes against the shipped file's 5 and fairemployment 5 against 6, so an implementer following the documentation would leave familial-status targeting unrestricted. Only one policy id appears in both the published policy list and the shipped registry.

When a policy category forces human review

Two fields with similar names split the work. The registry category definition declares requireshumanreview; the plan must then assert humanreviewrequired: true. sync-plans-request.json ships two allOf conditionals enforcing that, so a bad plan fails schema validation before any agent evaluates it. If policycategories contains fairhousing, fairlending, fairemployment or pharmaceuticaladvertising, humanreviewrequired must be present and true. The same applies if policyids contains euaiactannexiii.

Those four are the seeded categories carrying requireshumanreview: true, and the four ids are hardcoded in the schema conditional. A new review-flagged category added to the registry is not enforced by schema validation until the schema is republished.

Every policy also carries an enforcement level on an RFC 2119 ladder: must rejects the plan, should warns, may writes a log line. Enforcement is gated by effectivedate. Human review is not: "Unlike enforcement, this flag applies as soon as the policy is resolved — it is NOT gated by effectivedate."

The obligation lands on the agent, which "MUST escalate any action on this plan for human review before execution".

Where policy text comes from

policy-entry.json separates registry text from caller text: inline policies are "treated as caller-untrusted", agents "MUST pin registry-sourced policy text (source: registry) as system-level instructions", and neither an inline policy nor a plan's objectives may relax them.

Governance of the registry itself is less clearly defined. No maintainer group is declared for the registry directories. CONTRIBUTING.md routes every change through a fork and a pull request against main, gated on a one-time IPR-policy agreement, and CHARTER.md puts the repository under AgenticAdvertising.Org, a pending Delaware 501(c)(6). The registry README's four-step recipe for adding a policy ends in npm run check:registry; there is no equivalent for a category or an attribute. Only the restricted-attribute enum is fixed by a released schema; category and policy ids come from the registry at runtime.

AAMP has no policy category

The vocabulary is absent from the IAB AAMP repositories: no policycategories, no restrictedattributes, no audienceconstraints, and none of the protected-class terms the AdCP enum names.

AAMP carries consent instead. ConsentContext rides with the Quote, Deal and Order carrying GPP, TCF, US Privacy and an SGP diligencestatus as opaque strings: "no decoding/vendor-list validation is claimed". Its nearest thing to a policy control is SGPENFORCE and SGPUNKNOWNVENDORPOLICY (block / warn / allow), environment variables in the buyer-agent reference implementation. They gate which counterparties an operator trades with, not what a campaign may target.

---

# Product

Source: https://adtechglossary.com/media-buying/product/

In AdCP, a product is a unit of sellable advertising inventory offered by a seller and returned by get_products, describing the properties it runs on, how it delivers, what it costs and what the seller can report on.

A product in AdCP is a unit of inventory a seller is willing to sell. It is returned by getproducts and turned into packages inside a media buy. The schema at dist/schemas/3.1.13/core/product.json describes it in four words: "Represents available advertising inventory". AdCP's glossary adds the part that separates it from a rate card line: inventory "discovered through natural language queries".

Commercially, a product is the seller's own definition of what it sells: which publisher properties it runs on, whether delivery is guaranteed, which pricing models are available on it, and what the seller undertakes to report. A buyer does not browse a catalog to find it; it describes a campaign and the seller returns the products it considers a match.

How many fields a valid product needs

core/product.json carries 49 properties, more than any other object in the release, and its required array lists seven. An anyOf adds a format field, so eight are needed to validate, and every shipped fixture also carries channels.

| Field                    | Status                          | What it holds                                         |
| ------------------------ | ------------------------------- | ----------------------------------------------------- |
| productid             | required                        | Unique identifier for the product                     |
| name                   | required                        | Human-readable product name                           |
| description            | required                        | Detailed description of the product and its inventory |
| publisherproperties   | required, minItems: 1         | The properties the product runs on                    |
| deliverytype          | required                        | guaranteed or nonguaranteed                      |
| pricingoptions        | required, minItems: 1         | Available pricing models for this product             |
| reportingcapabilities | required                        | What the seller can report on                         |
| formatoptions         | anyOf, absent from required | Inline format declarations, the 3.1+ path             |
| channels               | optional, in every fixture      | The channels the product is sold as                   |
| formatids             | anyOf, legacy                 | Named-format references                               |

An object carrying only the seven required fields fails validation, because an anyOf demands formatids or formatoptions as well. The rule that governs the eighth is prose inside the formatids description: "Products MUST carry formatids, formatoptions, or BOTH; at least one is required." Either field satisfies it. The two paths are not equal: formatids is legacy, on a published deprecation calendar, and when both are present the schema says "prefer formatoptions".

Eight is a count of top-level keys. reportingcapabilities is an object with six required sub-fields of its own, so thirteen named values are needed before a single publisher property or pricing option is filled in.

publisherproperties carries a normative instruction addressed to SDK implementers: "SDK implementers MUST enforce singular-only at runtime: each entry uses the singular publisherdomain form; the compact publisherdomains[] form is rejected on products". It names four toolchains that often drop the restriction silently and emit an unrestricted type, so a generated client will accept the compact form and a conformant seller will reject it.

Where the schema and the documentation differ

Both declare seven required fields, and they name different sevens. The docs page lists 39 fields against the schema's 49: reportingcapabilities is required in the schema and absent from the docs, formatoptions is an anyOf branch in the schema and required in the docs, collections and installments are documented under the names shows and episodes, and five documented fields do not exist in the release at all. The live docs site carries the same omissions.

Because additionalProperties is true, a product written from the documentation validates clean, its invented shows key riding along as an ignored extra, and nothing tells the author that the targeting they wrote was dropped.

Custom and expiring products

Three optional fields say a product need not be a fixed catalog row. iscustom is "Whether this is a custom product". expiresat is an "Expiration timestamp. After this time, the product may no longer be available for purchase and createmediabuy may reject packages referencing it." briefrelevance carries an "Explanation of why this product matches the brief (only included when brief is provided)". Nothing pushes a notice when the window closes, and the firmest statement of what happens next is the PRODUCTEXPIRED error, correctable by re-running getproducts.

None of the three appears in any example payload in the repository. The canonical product fixtures under static/examples/products/canonical/ are static catalog rows carrying the same small set of keys, and nytimeshomepagetakeovercustom.json is named custom without setting iscustom.

Targeting permissions

Three booleans default to false: signaltargetingallowed, propertytargetingallowed, collectiontargetingallowed. Each bundles something a buyer might have assumed they could filter on. With signaltargetingallowed false, signals "are bundled into the product terms". With collectiontargetingallowed false, "the product is a bundle — buyers get all listed collections". With propertytargetingallowed false, the product goes "all or nothing".

Only signaltargetingallowed has a schema conditional behind it: an allOf rejects any product that declares signaltargetingoptions without signaltargetingallowed: true. The other two read false whether or not the seller set them. What the surviving signal fields address is on audience vs signal.

Three protocols define an object called Product

A field-name crosswalk breaks at deliverytype, the first field anyone would map: the three enums hold two, three and seven values. AdCP keeps delivery and exclusivity in separate enums, the second holding none, category and exclusive. AAMP folds exclusivity into DeliveryType, and OpenDirect folds deal type in on top of that. AdCP's FAQ names AAMP but publishes no mapping to it, saying "AAMP is still defining its normative surface."

|                       | AdCP Product                                 | AAMP primitives Product                                                 | OpenDirect Product                                   |
| --------------------- | -------------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Properties / required | 49 / 7 listed, 8 to validate                 | 16 / 3: productid, sellerorganizationid, name                  | 31 / 7                                                                        |
| deliverytype       | guaranteed, nonguaranteed               | Exclusive, Guaranteed, PMP                                        | 7 values, including three PMP flavours and two OpenRTB deal types             |
| Where price lives     | pricingoptions, required on the object    | baseprice optional list price; negotiated rate on RateCard         | baseprice required, "Base retail price (not rate card)"                     |
| Per-brief minting     | iscustom, briefrelevance, expiresat | not modelled                                                            | activedate and retirementdate, catalog lifecycle rather than offer expiry |
| Artifact and status   | published release 3.1.13                     | unreleased library, v0.5.0 | MCP tool manifest, version 2.1.0                                            |

---

# Quote

Source: https://adtechglossary.com/negotiation/quote/

A Quote in AAMP is a seller agent's non-binding, expiring price offer for one product over one flight, which a buyer books into a Deal by quote_id. AdCP defines no equivalent object.

A quote in AAMP is the priced answer a seller agent gives for one product over one flight. The schema leads with the word non-binding: "A non-binding price quote from a seller (Deals API v1.0 quote phase)." A quote is a price and not a reservation — the seller has priced a window and holds nothing inside it, and the same availability can be quoted to another buyer. Quote.json states that "quoteid is seller-issued", and QuoteRequest.json states that the buyer never proposes one. The object belongs to the IAB Tech Lab's Agentic Advertising Management Protocols and sits in the iab-agentic-primitives v0.5.0 contract library, unreleased at that version.

The price is buyer-specific. The base number comes from the private rate card named in ratecardid, and the seller recomputes both discount percentages on every request, the first from the buyer's access tier and the second from the impressions asked for, so two buyers requesting the same product over the same flight get different numbers.

The lineage the description claims is thinner than it sounds. IAB Tech Lab's published overview of Deals API v1.0, finalised on 6 February 2026, says the MVP "does NOT support proposals, revisions, or negotiations", so the quote phase AAMP names is not in the published specification it names it from.

What a quote contains

| Field                                                                                                | Required | What it holds                                                                                                                                                                                                                                                     |
| ---------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| quoteid                                                                                           | Yes      | Seller-minted identifier; the buyer never proposes one                                                                                                                                                                                                            |
| dealtype                                                                                          | Yes      | PG (programmatic guaranteed), PD (preferred deal) or PA (private auction). The long-form strings are not valid wire values                                                                                                                                  |
| product                                                                                            | Yes      | ProductRef: productid, name, optional inventorytype                                                                                                                                                                                                     |
| pricing                                                                                            | Yes      | QuotePricing: base and final CPM or CPP as Money, pricingmodel, pricingtype — fixed to use as-is, floor to invite negotiation above the number, onrequest to leave the price fields empty — two discount percentages and a free-text rationale |
| terms                                                                                              | Yes      | QuoteTerms: flight dates, impressions or GRPs, guaranteed flag                                                                                                                                                                                                  |
| status                                                                                             | No       | available, booked, expired, declined; defaults to available                                                                                                                                                                                             |
| expiresat                                                                                         | No       | Nullable, default: null                                                                                                                                                                                                                                         |
| buyertier                                                                                         | No       | The AccessTier the price was computed for; defaults to public                                                                                                                                                                                                 |
| mediatype                                                                                         | No       | digital, ctv or lineartv; defaults to digital                                                                                                                                                                                                            |
| dealid, ratecardid, consentcontext, sellerid, availability, createdat, lineartv | No       | Booking linkage, rate card, consent strings, quoting agent, availability, issue time, linear TV detail                                                                                                                                                            |

Four of the five required fields are nested objects defined in the same library. onrequest pricing carries an instruction with it: "buyers must never fabricate a price for onrequest inventory".

Eleven of the sixteen fields are optional and most carry defaults, so an unset field and a deliberately defaulted one are indistinguishable on the wire. The minimum viable quote is a public-tier digital offer marked available.

The shared Money type carries amountmicros and a three-letter currency, so every price on the wire is an integer: "Float is BANNED on the wire for money [...] that defect must not be fossilized into the spec."

Quote lifecycle

A quote runs through four states. status defaults to available, moves to booked when a buyer commits, and ends at expired or declined.

No schema field fixes a lifetime. QuoteResponse.json says only that quotes "are ephemeral — the seller enforces a TTL and answers a quoteexpired error after it elapses", and expiresat is anyOf [date-time, null] with default: null, so a quote carrying no expiry validates. The only number anywhere is 24 hours, in one line of src/adseller/services/quoteservice.py: expiresat = now + timedelta(hours=24).

Two status codes kill a quote: quoteexpired, HTTP 410, once it elapses, and contention, HTTP 409, "the quote was already booked". Either one sends the buyer back for a new quote, and because the discounts are recomputed per request the replacement can carry a different price. Deal covers what a quote turns into at booking, and a negotiation round anchors on the same quoteid in between.

Requesting a quote

QuoteRequest.required is idempotencykey, productid and dealtype, and QuoteResponse.required is ["quote"], a single wrapped object.

docs/api/quotes.md in the seller agent is the only public prose description of the endpoint, and it predates that contract: it types targetcpm as a float and shows a response of "basecpm": 12.0, "finalcpm": 10.26 where the schema requires integer amountmicros, it documents a request table with no idempotencykey, and it puts the quote at the top level of the response. The code in the same repository moved to the canonical contract and the prose did not — docs/api/openapi.json types QuotePricing.basecpm as a $ref to Money.

AdCP defines no quote object

AdCP 3.1.13 contains no quote schema, none of its 64 published operations issues one, and docs/protocol/design-principles.mdx rules the idea out under Principle 2. It quotes the proposal it rejects — "Proposing a getpricequote task between getproducts and createmediabuy — a configure-price-quote step where the buyer submits targeting and the seller returns a firm rate" — and answers it with composition: "Most of what that proposal asks for already exists: account-scoped rate cards via account, firm prices via pricingoptions, the pricingoptionid lock at commit time, and buyingmode: "refine" for the iteration loop." The product does that work instead, through iscustom, briefrelevance and an expiresat that says only that the product "may no longer be available for purchase", with no status machine behind it.

The same document lists three conditions under which a quote step would be justified and concedes "Those three are real gaps". AAMP's quote answers all three, through terms.flightstart, flightend and impressions as pricing inputs, through expiresat with a four-state status behind it, and through pricing.rationale. AdCP 3.1.13 stands differently on each:

- Pricing that depends on flight dates and budget the buyer has not committed yet is partly covered. volume is a named adjustment, but the price lives on the product, across nine pricing-option schemas: cpm, cpc, cpa, cpv, cpcv, cpp, vcpm, flat-rate and time.
- A time-bound firm rate before commitment is open. validuntil appears nowhere under pricing-options/, and enums/error-code.json records the consequence as REQUOTEREQUIRED, raised when an updatemediabuy breaks the envelope the original price was set against: "AdCP 3.1 does not define an amendment-quote artifact that can be attached to updatemediabuy."
- An auditable explanation of what drove the price is closed, and machine-checkable. The ratebasis field the condition asked for never shipped under that name; price-breakdown.json landed instead, an ordered adjustment array whose invariant is that list price plus adjustments in sequence equals fixed price.

---

# Mutation (ARTF)

Source: https://adtechglossary.com/realtime/rtb-mutation/

A mutation is ARTF's proposed change to an OpenRTB bid request or response, carrying an intent, an operation, a path and at most one of five typed payloads, which the orchestrator may accept or reject.

A mutation is a proposed change to an OpenRTB bid request or bid response, sent by an in-path agent back to the orchestrator that called it. ARTF's name for the mechanism is the OpenRTB Patch Protocol, and the framework document treats a mutation as a request throughout: "Participant responses may request in-flight modifications via patch objects that include desired mutations which the orchestrator may accept or reject at their discretion."

No Patch message exists in the .proto files; the patch object of that sentence is prose, and what travels on the wire is RTBResponse.mutations[], a flat repeated field.

ARTF v1.0 is a published IAB Tech Lab framework document, past a public comment period that closed 15 January 2026. It is not a ratified interoperability standard, and v1.0 is a git tag on the ARTF repository.

The Mutation message

The canonical message lives in rust/proto/agenticrtbframework.proto, package com.iabtechlab.bidstream.mutation.v1.

| Field    | Number  | Type        | Comment in the proto                                                                                |
| -------- | ------- | ----------- | --------------------------------------------------------------------------------------------------- |
| intent | 1       | Intent    | "The purpose of the mutation"                                                                       |
| op     | 2       | Operation | "Defines the operation to perform (e.g. add, remove, replace) on the target data at the given path" |
| path   | 3       | string      | "The semantic business domain of where the operation will be applied"                               |
| value  | 100-104 | oneof     | "The structure of value depends on the specified intent"                                            |

The oneof value block has five branches — ids at 100, adjustdeal at 101, adjustbid at 102, metrics at 103 and contentdata at 104 — so a mutation carries one payload at most. Numbers 1000 to 1999 are reserved for experimental and test payloads, matching the Intent enum.

op takes OPERATIONADD, OPERATIONREMOVE or OPERATIONREPLACE, plus the OPERATIONUNSPECIFIED zero value proto3 requires. Those are JSON Patch's verbs without copy, move and test. Neither reference agent uses all three: internal/handlers/handlers.go emits ADD and REPLACE only.

The five payloads

IDsPayload is a repeated string, AdjustBidPayload a price double, and MetricsPayload and DataPayload repeated OpenRTB objects. AdjustDealPayload carries a bidfloor double and a Margin, which holds a value double and a calculationtype of CPM or PERCENT.

DataPayload diverges across the repository. Both protos and the Rust bindings have it; the Go bindings and docs/00-EXAMPLE.md do not, and the Go handler is a stub returning nil with a comment pointing at make bindings, a target that runs protoc over two files not in the repository root.

The margin discriminator

Margin.CalculationType has no UNSPECIFIED member and CPM is the zero value. An omitted discriminator decodes as an absolute adjustment, and a margin of 5 decodes as five CPM whether or not the sender set the field. A deliberate CPM cannot be distinguished from an unset field on the wire.

Atomicity and ordering

The specification is explicit: "Each patch is atomic. A mutation must be accepted in whole or rejected in whole. Multiple patches may be independently accepted or rejected - there are no transactions or any ordering guarantees across mutations."

Activating a deal and changing its floor are two mutations — ACTIVATEDEALS carrying an IDsPayload, ADJUSTDEALFLOOR carrying an AdjustDealPayload — and the oneof allows one payload per mutation, so an orchestrator can take one and drop the other.

No accept, reject or acknowledgement message exists in any of the three protos, and the transport is one unary method, rpc GetMutations (RTBRequest) returns (RTBResponse). The specification leaves the return path open: "Whether and how orchestrators will communicate choices to accept or reject patches to agent providers is left to the parties."

The path field

A path is a string such as /imp/{id}/pmp/deals/{dealId}. In the specification's own words, paths "identify business level entities rather than specific JSON locations". docs/00-EXAMPLE.md pairs each intent with a shape:

| Intent                                    | Expected payload    | Path example                   |
| ----------------------------------------- | ------------------- | ------------------------------ |
| ACTIVATESEGMENTS                       | IDsPayload        | /user/data/segment           |
| ACTIVATEDEALS, SUPPRESSDEALS        | IDsPayload        | /imp/{id}                    |
| ADJUSTDEALFLOOR, ADJUSTDEALMARGIN | AdjustDealPayload | /imp/{id}/pmp/deals/{dealId} |
| BIDSHADE                               | AdjustBidPayload  | /seatbid/{seat}/bid/{bidId}  |
| ADDMETRICS                             | AddMetricsPayload | /imp/{id}/metric             |

Seven intents are documented; the enum carries eight plus the zero placeholder, and the undocumented one is ADDCIDS. The intent vocabulary is its own entry.

No grammar constrains that string and no schema validates it, so two implementations can disagree about whether {id} is an impression index or an impression ID and both will compile. A mutation can land on the wrong impression, and no message in the protos reports back what the orchestrator did with it. The repository's own Go agent already diverges: for ADJUSTDEALFLOOR it emits /imp/{impID}/pmp/deals, dropping the {dealId} segment.

Which definition of Mutation to build against

rust/proto/agenticrtbframework.proto is the only self-consistent copy in the repository. The root proto matches it column for column except on the import: it asks for com/iabtechlab/openrtb/v2.6/openrtb.proto, no file sits at that path under proto/, so it cannot resolve its own import.

| Definition                         | intent / op type            | Payload branches | Intents            |
| ---------------------------------- | ------------------------------- | ---------------- | ------------------ |
| Tagged v1.0 specification document | string                        | 4                | prose strings only |
| Root proto/ (edition 2023)       | enum                            | 5                | 9                  |
| rust/proto/ (proto3)             | enum                            | 5                | 9                  |
| Checked-in Go bindings             | Intent / Operation, req | 4                | 8                  |
| Checked-in Rust bindings           | i32, no presence              | 5                | 9                  |
| docs/00-EXAMPLE.md               | enum                            | 4                | 8                  |

AddMetricsPayload, the metrics branch in the specification document and in docs/00-EXAMPLE.md, is not a message any proto defines; the message is MetricsPayload, and the Go bindings generate the branch as MutationAddMetrics. The bindings disagree on intent, op and path as well: the Rust bindings type them i32, i32 and String with no presence, so a mutation carrying no intent decodes cleanly as INTENTUNSPECIFIED, while the Go bindings mark the same three fields required in the proto2 style and make them pointers, so the same bytes come back as a decode error.

The tagged specification document assigns ext = 3 and tmax = 6 where the proto assigns tmax = 3 and originator = 6, so a doc-conformant encoder and a proto-conformant decoder mis-parse each other. It declares repeated mutation mutations = 2; with a type name that resolves to nothing, and gives worked JSON with intent strings like expireDeals that are not enum members under any spelling. The v1.0 tag points at this document.

AdCP has no counterpart

AdCP's FAQ answers "Does AdCP replace OpenRTB?" with "No. AdCP and OpenRTB operate at different layers and are complementary." No AdCP operation touches the bidstream: none of the 64 published tasks is auction-shaped, and the release defines no bid request, bid response or bid floor. AdCP's nearest real-time surface is the Trusted Match Protocol, a request-and-response identity check with no patch mechanism in it.

---

# Sales Agent

Source: https://adtechglossary.com/agents/sales-agent/

A sales agent is the seller-side server that exposes publisher inventory for discovery and purchase under AdCP, a role AAMP calls a seller agent and the newer AdCP schemas do too.

A sales agent is the seller-side server that exposes publisher inventory for discovery and purchase under AdCP. The seller is the commercial entity; the sales agent is the software it runs, and one seller may operate more than one agent.

AdCP's glossary keeps the two apart. The sales agent "handles product discovery, media buy creation, and campaign management", with "publisher ad servers exposing AdCP interfaces, sales house platforms" given as examples; the seller is "the AdCP participant role that provides advertising inventory... In AdCP schemas, 'seller' is the standard term for this role (not 'platform')".

What a sales agent must implement

AdCP's required-tasks reference heads its Media Buy section "Sales agent (seller)" and marks thirteen tasks Required, Conditional or Optional, seven of them Required.

| Task                           | Requirement | Notes                                                    |
| ------------------------------ | ----------- | -------------------------------------------------------- |
| getproducts                 | Required    | Inventory discovery                                      |
| getadcpcapabilities        | Required    | Agent capabilities; sellable formats stay product-scoped |
| createmediabuy             | Required    | Campaign creation and order confirmation                 |
| updatemediabuy             | Required    | Budget, targeting, pause, cancel                         |
| getmediabuys               | Required    | Operational state retrieval                              |
| getmediabuydelivery       | Required    | Package-level delivery metrics                           |
| provideperformancefeedback | Required    | Accept buyer optimisation signals                        |
| synccreatives               | Conditional | When the sales agent hosts a creative library            |
| logevent                    | Conditional | When event sources are configured                        |
| listcreatives               | Optional    | Creative catalog browsing                                |
| synccatalogs                | Optional    | Product/inventory catalog sync                           |
| synceventsources           | Optional    | Conversion tracking setup                                |
| syncaudiences               | Optional    | First-party CRM audience upload                          |

getadcpcapabilities is required of every AdCP agent rather than of sales agents specifically. The same section sets the transport rule: "Sales agents MUST also support at least one transport (MCP or A2A) and declare mediabuy in supportedprotocols." MCP and A2A are the two agent transports AdCP runs on, and a sales agent picks at least one. These tasks are the mediabuy subset of AdCP's operation registry.

The operators in scope are listed in docs/protocol/architecture.mdx: "publishers, sales houses, rep firms, SSPs, and ad networks". Buy-side-only participants call sales agents rather than operating them.

Authorisation is published in adagents.json

A publisher declares which sales agents may sell its inventory in adagents.json, served at /.well-known/adagents.json alongside the other discovery files. One entry names a URL, what it covers, and how the authorisation is scoped:

authorizationtype takes six values. Four of them scope inventory; the other two, signalids and signaltags, authorise a signal agent instead. The full field list is in AdCP Explorer's discovery view.

Sales agent and seller agent

Both names denote the same role, and both resolve to the same identifier: the agenturl declared in the publisher's adagents.json. AdCP's prose uses "sales agent" and the AAMP repositories use seller agent; AdCP schemas added since 3.0.1 use "seller agent" as well. core/seller-agent-ref.json, titled "Seller Agent Reference" and stamped x-status: experimental, carries one required property, agenturl, "as declared in the property publisher's adagents.json authorizedagents[].url". Trusted Match binds every available package to one of those references at sync time.

AdCP uses the two names inconsistently across its own sources:

| Where AdCP says it                     | What it calls the role   | What it says there                                                                       |
| -------------------------------------- | ------------------------ | ---------------------------------------------------------------------------------------- |
| docs/reference/glossary.mdx          | Sales Agent              | An MCP server exposing publisher inventory. Supply side, the publisher's own software.   |
| docs/trusted-match/specification.mdx | Seller agent             | "The buyer-side agent that sold the package into a publisher."                           |
| dist/schemas/3.1.13/adagents.json    | sales agents             | "Array of sales agents authorized to make inventory from this file available to buyers." |
| docs/governance/property/index.mdx   | SELLER AGENT (DSP/SSP) | A diagram box, which reads the seller agent as whichever platform sold the package.      |
| docs/intro.mdx                       | seller agent             | Describes a repository named salesagent as "a full-stack seller agent".                |

The specification does not reconcile the readings. The word pair is treated at length on the terminology page.

"Sales agent" also predates the protocol. In media it means a rep firm or sales house selling inventory on a publisher's behalf, staffed by people, a sense that remains in common use and that AdCP's glossary entry nods to when its examples end on "sales house platforms".

AdCP and AAMP side by side

| Question                     | AdCP 3.1.13                                                                              | AAMP                                                                                 |
| ---------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Name for the sell-side agent | Sales agent                                                                              | Seller agent                                                                         |
| Source type                  | Published specification with a versioned schema registry                                 | Reference implementations, no ratified wire spec                                     |
| Capability discovery         | getadcpcapabilities, a runtime task                                                  | An agent card at /.well-known/agent.json                    |
| Price negotiation            | Pricing options and rate cards, no counter-offer surface or quote object in the registry | Quote.json, Proposal.json, Negotiation.json in iab-agentic-primitives v0.5.0 |
| Sell-side authorisation      | adagents.json on the publisher domain                                                  | Trust status in an agent registry                         |

AAMP's schemas do not use the phrase "sales agent". iab-agentic-primitives/spec/jsonschema/Agent.json defines AgentType as a five-value enum, buyer, seller, toolprovider, dataprovider and other, defaulting to buyer. AAMP also has no single release number: each of its repositories versions independently, so "seller agent v2.4.1" is a per-repo tag rather than an AAMP version.

AdCP's buy-side counterpart is an orchestrator, the buyer-side client that drives the buy, and required-tasks is explicit that orchestrators "are not MCP/A2A servers — they call sales agent tasks." AAMP's buyer agent ships an HTTP API of its own, titled "Ad Buyer Agent API".

Related roles: plan validation belongs to a governance agent and brand identity to a brand agent, following the separation docs/trust.mdx draws between the agent that spends money and the agent that approves the spend. The protocols are compared side by side at AdCP vs AAMP.

---

# Seller Agent

Source: https://adtechglossary.com/agents/seller-agent/

A seller agent is AAMP's supply-side agent: it publishes a media kit, prices by buyer tier, negotiates and books deals. AdCP's glossary calls the same role a sales agent while its schemas ship a seller_agent field.

A seller agent is supply-side software that publishes a catalog of inventory, prices it by the buyer's verified identity tier, evaluates proposals, runs a bounded price negotiation, and mints a deal ID for DSP activation. No ratified specification defines the role. IAB Tech Lab's reference seller agent is the working definition, and it calls itself "an AI-powered inventory management system for publishers and SSPs ... using IAB Tech Lab standards (OpenDirect 2.1, Deals API v1.0, sellers.json)".

Seller agent and sales agent name the same job. AdCP's glossary has no entry for Seller Agent and defines Sales Agent instead, while its documentation uses both words and its schemas ship a selleragent field. The phrase "sales agent" does not appear in the IAB Tech Lab repositories. The term is tied to neither protocol: Magnite's SpringServe implementation is AdCP over MCP, announced as "Why We Built a Seller Agent Into SpringServe", and that post does not mention IAB Tech Lab.

What the seller agent exposes

GET /.well-known/agent.json needs no authentication and declares five skills: discovery, pricing, proposals, negotiation and deals. Those cover searching and browsing inventory, media kits and packages; pricing by buyer identity; accepting and evaluating proposals including counter-offers; running automated multi-round price negotiation; and minting OpenRTB-compatible deal IDs for DSP activation. The agent card entry sets the file out field by field.

The card lists supporteddealtypes as pg, pmp, preferreddeal, privateauction; the shared primitives schema documents the same field as 'PG', 'PD', 'PA'. Nothing in either repository reconciles the two spellings. capabilities.protocols lists opendirect21 and nothing else, and the discovery guide calls A2A "designed but not yet served". What ships today is REST and MCP, and nothing else in AAMP carries a buyer from discovery to a deal ID.

Pricing by buyer tier

Price depends on the buyer's access tier, which registry trust status caps. The buyer presents identity, the seller derives a tier, and the buyer's "effective tier is the minimum of their trust-based ceiling and their claimed identity tier". Of the five trust values only registered is automatic; the rest are operator decisions in the agent registry.

Tier then picks the negotiation strategy. The strategy name describes the seller's stance, so aggressive is the least generous of the four.

| Access tier  | Strategy     | Rounds | Concession cap per round | Cap across the negotiation |
| ------------ | ------------ | ------ | ------------------------ | -------------------------- |
| public     | aggressive | 3      | 3%                       | 8%                         |
| advertiser | premium    | 6      | 6%                       | 20%                        |

Two tiers sit between those two, and AAMP Explorer has the full table.

POST /proposals/{proposalid}/counter submits a counter-offer. Beside it sit GET /proposals/{proposalid}/negotiation and a quote endpoint pair, quotes being "non-binding price offers" with a 24-hour TTL. The canonical negotiation surface, POST /api/v1/negotiations/messages, lists idempotencykey among the two required properties of NegotiationMessage and documents it as "Same key - same response, no duplicate side effects". The negotiation router contains no idempotency handling: the key is required by the schema on every message and honoured on none.

What a seller agent needs around it

The seller agent sits in front of the ad server rather than replacing it. An AdServerClient connector fronts the real one (Google Ad Manager, FreeWheel, or a CSV adapter for demos), and the agent keeps its own state in SQLite or Redis. What it adds is the selling. POST /api/v1/deals/distribute "routes the deal to the appropriate SSP based on routing rules": PubMatic over MCP, Index Exchange and Magnite over REST. POST /api/v1/deals/push sends deal terms straight to buyer DSPs over IAB Deals API v1.0. GET /api/v1/supply-chain parses a sellers.json into an OpenRTB-compatible schain. The ad server, the SSP relationship and the sellers.json entry are all assumed to be in place already.

Seller agent in AdCP

AdCP models no negotiation surface: its media-buy action enum runs to 21 values and none is a negotiation. It registers that the haggling happens, since pricing-options/cpm-option.json says declared adjustments tell "buyer agents which adjustments are available before negotiation", and it does not model the negotiation itself.

AdCP's Trusted Match specification defines the term once, in its definitions table:

 Seller agent | The buyer-side agent that sold the package into a publisher. Identified by the agent URL declared in the publisher's adagents.json authorizedagents[].url.

That places the role on both sides of the trade at once, since adagents.json is a publisher's sell-side authorization file. Two other AdCP documents disagree: the Trusted Match buyer guide calls the counterparty "the publisher's sales agent", and brand.json describes its own selleragenturl field as the "URL of the sales agent that sells inventory for this collection". The two available readings, an editorial slip or a platform-side reseller distinct from the publisher's own sales agent, are set out on sales agent.

The field is required whichever reading wins. selleragent sits on trusted-match/available-package.json next to packageid and mediabuyid, carries x-status: experimental like Trusted Match itself, and holds an agenturl copied from the publisher's adagents.json plus an id "Reserved for a future registry-assigned stable seller identifier. Not used today". The field records which agent sold a package; no operation reads it.

Where the wire contract lives

The shared types are not in the seller repository. pyproject.toml pins iab-agentic-primitives[client] @ git+https://github.com/IABTechLab/iab-agentic-primitives.git@v0.5.0, and that library holds Quote, Negotiation, Proposal, MediaKit, Deal and Agent. Its own README says it is unstable, not yet released and not to be depended on in production; both shipping agents depend on it anyway, by git URL, at runtime, and it is not among the repositories the AAMP hub README lists.

Each AAMP repository versions independently, and the seller repository's own version numbers disagree with each other, so v2.4.1 is a repository tag rather than an AAMP release.

Roles AAMP does not define

AAMP has no brand agent, no governance agent, no signal agent and no creative agent. Three of those jobs still get done, as endpoints rather than agents. Identity is PUT /registry/agents/{agentid}/trust, an operator raising or blocking a trust status by hand. Policy is POST /approvals/{approvalid}/decide, a human decision stamped with the principal from the authenticated API key. Signal is POST /agentic-audience/match, whose own description calls the score "mock-quality (deterministic from sha256 of identifier)" with the real embedding model deferred to a later epic. The fourth job has no endpoint: AAMP has no creative agent and nothing equivalent to AdCP's creative operations.

---

# Signal Agent

Source: https://adtechglossary.com/agents/signal-agent/

A signal agent is an AdCP server that discovers and activates advertising signals over MCP or A2A, implementing get_signals and activate_signal, authorised signal by signal by data providers in adagents.json.

A signal agent is an AdCP server that discovers and activates advertising signals over MCP or A2A, on behalf of the data provider that owns them. The data provider publishes the authorisation to resell a segment on its own domain, and the signal agent operates against a file it cannot edit.

The thing being resold is a signal, a named and licensable audience or contextual segment addressed by an id like likelyteslabuyers. Activating one pushes it into a destination, a named seat on a named buying platform, so a campaign can target it.

AdCP's glossary gives the role two sentences: "A server (via MCP or A2A) that provides signal discovery and activation services. Enables natural language audience discovery and deploys signals to decisioning platforms." Authorisation gets one line: signal agents "are authorized by data providers via adagents.json to resell specific signals". AdCP writes the role both ways, "signal agent" and "signals agent", and has not settled on one.

Required tasks and access control

AdCP's required-tasks reference heads a section "Signal agent" and marks two tasks Required: getsignals for discovery and activatesignal for activation on decisioning platforms. With getadcpcapabilities, which every AdCP agent implements, a minimal signal agent implements three operations. docs/learning/foundations/a2-protocol-architecture.mdx also attributes "measurement and audience data" to signal agents, though measurement appears in neither the glossary entry nor either required task.

getsignals takes a signalspec, a "Natural language description of the desired signals" rather than a taxonomy code. activatesignal requires signalagentsegmentid, destinations[] and an idempotencykey, and that segment id is an "Opaque activation handle returned in ... each getsignals response entry". The same section adds one obligation beyond the two tasks: "Signal agents MUST enforce access control for private signals and activation keys." A private deployment, in the glossary's terms, is visible only to one buyer's accounts and is what that rule protects; a marketplace deployment is licensed across accounts.

Disclosure of how a segment was built is optional throughout. A signal definition requires only id, name and valuetype, and the provenance fields in core/signal-definition-enrichment.json — methodology, datasources, segmentationcriteria and a criteriaurl — are projected into a listing only when the request's fields array asks for them.

Who authorises a signal agent

dist/schemas/3.1.13/adagents.json states in its top-level description that the file lives at /.well-known/adagents.json "on publisher domains (for properties) or data provider domains (for signals)". A signal agent is therefore vouched for by the data provider whose segments it resells rather than by the publisher whose inventory a sales agent sells.

Two of the six authorizationtype variants scope data rather than inventory, signalids and signaltags, and both resolve against the top-level signals[] array in the same file, so the licence and the catalogue ship together. The other four scope inventory, and discovery files covers those.

One entry authorises a tag and everything under it, the other a single segment id. Each entry also inherits url, authorizedfor and an optional signingkeys from core/authorized-agent-base.json, so the data provider attests the signal agent's public keys on its own domain rather than the buyer discovering keys from the agent's.

Deleting an id from signalids withdraws the named agent's authorisation to resell that segment. AdCP defines no notification to the agent and no revokedsignalids[], and how fast a withdrawal takes effect is unspecified: docs/governance/property/adagents.mdx tells consumers to cache "for 24 hours minimum", and the one invalidation hint covering signals[] is catalogetag, which publishers "should publish".

The obligations follow the same file:

| Party            | What it hosts                                                                                  | What it implements                                                                               |
| ---------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Data provider    | /.well-known/adagents.json on its own domain, carrying signals[] and authorizedagents[] | No agent at all                                                                                  |
| Signal agent     | Nothing on the provider's domain                                                               | getsignals, activatesignal, getadcpcapabilities, and access control on private signals |
| Buyer            | Nothing                                                                                        | No signal-side obligation; verification is a fetch of the data provider's file                   |
| Publisher or SSP | adagents.json carrying properties[] rather than signals[]                                | Out of scope on the signals side                                                                 |

docs/signals/data-providers.mdx puts publishers and data providers in adjacent table rows, "Authorize agents to sell inventory" against "Authorize agents to resell signals". The buyer-side fetch is what docs/signals/overview.mdx means by "buyers don't have to take the signal agent's word for data provenance". AdCP names LiveRamp, The Trade Desk and Peer39 as example signal agents.

Signals in AAMP

No AAMP repository defines a signal or data-provider role, and no schema in iab-agentic-primitives v0.5.0 is a signal or an audience object. agentic-audiences carries a producer.agentrole enum of publisher, seller, buyer, measurement, brand and other: it has a value for measurement and none for a data provider. In that repository, specs/v1.0/schema/agentinterface.schema.json is zero bytes.

| Question                       | AdCP 3.1.13                                             | AAMP                                                                 |
| ------------------------------ | ------------------------------------------------------- | -------------------------------------------------------------------- |
| Is there a role for data?      | Signal agent, two required tasks                        | None                                                                 |
| Who declares what data exists? | The data provider, in signals[] on its own domain     | The seller, in supportedsignaltypes on its own package media kit |
| Who vouches for the reseller?  | The data provider, per signal, in authorizedagents[] | Nobody. There is no reseller                                         |
| Can a buyer verify the claim?  | Fetch the data provider's adagents.json               | No mechanism exists                                                  |
| What does matching return?     | Typed signals, activated to a named destination         | A score bucketed STRONG / MODERATE / WEAK / POOR                     |

AAMP's only structured signal vocabulary belongs to a seller describing itself. The reference seller-agent declares SignalType = Literal["identity", "contextual", "reinforcement"], carried on supportedsignaltypes in the package media kit and stamped specversion "draft-2026-01". The endpoint that consumes it does much less: POST /agentic-audience/match scores a match as int(sha256(identifier).hexdigest()[:8], 16) / 0xFFFFFFFF, a placeholder its OpenAPI description marks as awaiting the real embedding model in "Epic 2 (E2-2)".

AdCP's glossary names LiveRamp as an example signal agent, and agentic-audiences/README.md calls that repository "an open standard proposed by LiveRamp", with the embedding schema's $id pointing at github.com/LiveRamp/user-context-protocol. AdCP vs AAMP runs the comparison across both protocols.

---

# Signal Definition

Source: https://adtechglossary.com/signals/signal-definition/

A signal definition is one entry in a data provider's published adagents.json signals[]: AdCP 3.1.13 gives it 31 fields, seven of identity and shape, three of them required (id, name, value_type), and 24 optional provenance and consent disclosures.

A signal definition is the authoritative record of one targeting signal, published by the domain that owns the data. AdCP 3.1.13 puts 31 properties on the object and requires three: id, pattern ^[a-zA-Z0-9-]+$ and local to the domain; name; and valuetype, one of binary, categorical or numeric, which determines the shape of any targeting expression written against the signal.

core/signal-definition.json says where the record lives in its opening line: "Definition of a signal in published adagents.json signals[]. The publishing domain supplies the namespace, so this definition carries a local id rather than a signalref." A data provider hosts adagents.json on its own domain, and signals[] inside it holds the definitions. A product that offers the signal points at it with a signalref of scope dataprovider. The buyer resolves that ref to the provider's domain, fetches the file and reads the entry its owner published, so a seller's account of a segment can be checked against the owner's record. That check is what separates a signal from an audience the buyer uploaded.

Definition, listing and ref are three different schemas

| Schema                   | Role                                   | Where it appears                                          |
| ------------------------ | -------------------------------------- | --------------------------------------------------------- |
| signal-definition.json | the record the provider publishes      | a data provider's adagents.json signals[]             |
| signal-listing.json    | identity metadata lifted out of it     | product includedsignals, getsignals results         |
| signal-ref.json        | a pointer with a scope discriminator | targeting expressions, activation |

signal-listing.json states the boundary: "Product-local signals use the listing as the definition boundary and MUST include name and valuetype." signal-ref.json adds three scopes, product, dataprovider and signalsource, and states that "scope is the resolution path, not provenance".

get-signals-response.json carries a fourth shape, signalid, marked "DEPRECATED. Use signalref instead. Legacy SignalId retained for compatibility with older Signals Protocol clients." A buyer agent written against an older release still sends that shape, and a seller that reads only signalref will not see it.

Provenance and consent fields

Seven fields are identity and shape: id, name, description, valuetype, tags, allowedvalues, range. The other 24 describe where the segment came from and under what legal basis. AdCP factors 19 of those 24 into core/signal-definition-enrichment.json, the file the getsignals response reuses; the remaining five live on the definition and nowhere else.

Some of the 24 resolve to a value a buyer agent can branch on. The table below groups the ones that share an enum; the rest are URLs, nested objects, country lists and timestamps.

| Field                         | Value space                                                                                                                 |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| methodology                 | observed, declared, derived, inferred, modeled                                                                    |
| datasources                | 17 values, webusage and loyaltycard through publicrecordvoterfile                                                |
| subjecttype                | individual, household, business, contextual, none                                                                 |
| resolutionmethod           | deterministicid, probabilisticdevice, browser, geographic, contentsignal, mixed                              |
| audiencescope              | singledomain, crossdomainowned, crossdomainunowned, offline                                                    |
| idtypes                    | cookie, mobileid, platformid, userenabledid                                      |
| refreshcadence             | 8 values, intraday to annually; lookbackwindow shares the enum                                                      |
| consentbasis, art9basis | 4 GDPR Article 6 bases; then explicitconsent, manifestlymadepublic, substantialpublicinterest, vitalinterests |
| restrictedattributes       | the closed 10-value registry, 8 of them Article 9 special categories                        |

Two of these fields tell a buyer what not to do with them. criteriaurl points at a longer methodology document and then closes off the obvious use: "This is a disclosure pointer; buyers should not branch programmatically on the linked content." lastupdated "indicates freshness of the definition record, not an attestation that the underlying data or model was refreshed at that time".

The five fields that live only on the definition — subjecttype, resolutionmethod, idtypes, audiencescope and originatingdomain — never reach the wire. getsignals returns an allOf of exactly two schemas, signal-listing.json and signal-definition-enrichment.json, and the fields projection on get-signals-request.json enumerates 18 field names a buyer can ask for, none of them these five. The projection is not an entitlement: "fields is a projection request, not an entitlement grant; agents MAY redact requested definition fields unless the caller is authorized", and AdCP does not define what authorises a caller. Establishing whether a segment resolves deterministically or probabilistically therefore means fetching the provider's adagents.json directly.

The disclosure fields come from the IAB Data Transparency Standard

The 19 enrichment fields track the IAB Data Transparency Standard almost item for item. DTS v1.2, published April 2024, defines up to 20 standardised disclosure fields and ships them as a human-readable Data Label backed by an annual business audit. AdCP carries the same fields as JSON without the audit, replacing it with dtscompliantversion: the "IAB Data Transparency Standard version this signal definition self-attests as satisfying, when applicable." dtscompliantversion is self-asserted; no party countersigns it and nothing revokes it.

When the conditional disclosure rules fire

All five of the allOf conditionals on signal-definition.json wait for the provider to declare something first.

| If the definition declares                                                                                                                  | It must then carry        |
| ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| valuetype: categorical with a taxonomy                                                                                                 | taxonomy.valuemappings |
| audiencescope: singledomain                                                                                                             | originatingdomain      |
| methodology: modeled                                                                                                                      | a modeling block        |
| audienceexpansion: true                                                                                                                  | the same modeling block |
| any of offlinesurvey, publicrecordcensus, publicrecordvoterfile, publicrecordother, offlinetransaction in datasources | an onboarder            |

Each conditional puts a required on its own trigger field — {"if": {"properties": {"methodology": {"const": "modeled"}}, "required": ["methodology"]}} — so each keys on a field the provider is free to omit. A definition that omits methodology, audienceexpansion and datasources triggers none of the five, and a modelled lookalike validates clean as {"id": "autointendersq3", "name": "Auto Intenders Q3", "valuetype": "binary"}. additionalProperties is true on the definition, so unknown keys pass validation as well. policycategories is typed as a bare {"type": "string"} array while the documentation says "Values MUST match the canonical definitions in the Policy Registry", a constraint that exists in prose only; its neighbour restrictedattributes does $ref its enum.

AdCP states the consequence itself: "Without governance metadata, a governance agent must infer sensitivity from signal names — this is fragile and produces false positives."

Audience targeting in AAMP

AAMP's version of this object is one untyped field. Product.audiencetargeting in iab-agentic-primitives v0.5.0 is typed {"anyOf": [{"additionalProperties": true, "type": "object"}, {"type": "null"}], "default": null} with the description "IAB Audience Taxonomy targeting intent". No properties, no required keys. contenttargeting and adproducttargeting are shaped identically, and the seller-agent OpenAPI repeats the typing.

The only place a shape is committed to is Product.golden.json, the conformance fixture generated from that schema: "audiencetargeting": {"segmentids": ["1001"]}, an array of opaque strings. The Agentic Real-Time Framework, another repository in the same programme, reduces segments to a single protobuf enum value, ACTIVATESEGMENTS = 1.

The IAB Data Transparency Standard appears in no AAMP repository, under any of its names, though IAB Tech Lab wrote that standard and AdCP encoded 19 of its fields.

---

# Sources and Versions

Source: https://adtechglossary.com/about/sources-and-versions/

A pinned source commit is the exact repository revision a definition was written from. This glossary sources AdCP terms from published stable release 3.1.13, and AAMP terms from eight independently versioned repositories with no shared version number.

Every definition in this glossary is sourced from a named specification file at a pinned commit, the exact repository revision the definition was written from. AdCP, the Ad Context Protocol, is pinned to published stable 3.1.13 at commit a0fd0b5, Apache 2.0, copyright AgenticAdvertising.Org. AAMP cannot be pinned the same way: the hub README expands the acronym as Agentic Advertising Management Protocols and ships no version number of any kind, so AAMP terms are pinned to eight commits instead.

Two rules decide which number a page carries. A published release is preferred to a working tree, and a machine-readable registry to documentation prose. For AdCP that picks 3.1.13, from dist/schemas/latest.json, which reads { "latest": "3.1.13", "lateststable": "3.1.13", "channel": "stable" }; static/schemas/source/ is never read as a version, because it self-labels stability: "development". Operation counts come from the same registry, which puts 64 operations across ten areas in that release.

The eight AAMP repositories

There is no AAMP equivalent of latest.json, so every AAMP definition in this glossary traces back to one of these:

| Repository               | What it ships                     | Tag      | Commit    | Commit date |
| ------------------------ | --------------------------------- | -------- | --------- | ----------- |
| AAMP (hub)             | README index                      | untagged | 3b20e67 | 2026-04-16  |
| iab-agentic-primitives | 48 JSON Schemas, OpenAPI 3.1      | v0.5.0 | 2fc7029 | 2026-07-28  |
| seller-agent           | Reference implementation          | v2.4.1 | 2bb7ebc | 2026-08-05  |
| buyer-agent            | Reference implementation          | v2.3.0 | 0c3a154 | 2026-08-05  |
| agentic-rtb-framework  | Prose specification plus protobuf | v1.0   | 7f48161 | 2026-07-21  |
| agentic-audiences      | Draft specification               | untagged | 106ebd6 | 2026-07-27  |
| agentic-direct         | Mock-backed demo                  | untagged | 915bda9 | 2026-01-27  |
| registry-agent-example | Sample registry agent             | untagged | 1ff8dda | 2026-02-24  |

Four of the eight carry no tag. buyer-agent declares version = "0.1.0" in its pyproject.toml against a v2.3.0 git tag; this glossary cites the tag.

registry-agent-example and agentic-direct have not been touched since February and January 2026 respectively. They stay because definitions here cite them for what they do not contain: an agent.ts with no registry contract in it, and MCP tool handlers that return generateMockResponse.

AdCP version numbers by surface

Five first-party files at the pinned commit carry five different numbers.

| Surface at a0fd0b5                                                  | Number it carries |
| --------------------------------------------------------------------- | ----------------- |
| dist/schemas/latest.json                                            | 3.1.13            |
| docs/reference/versions.mdx, the version-status table               | 3.1.12            |
| dist/docs/3.1.13/reference/versions.mdx, the newest built docs tree | 3.1.0             |
| static/schemas/source/index.json                                    | 1.0.0             |
| package.json                                                        | 3.1.1             |

A number quoted from a documentation page is out of date on arrival, which is how third-party comparisons end up citing 3.1 or 3.1.2 while the schema registry has moved on.

The source tree registers a 65th operation the release does not, syncagentnotificationconfigs: present under static/, documented in its own doc page, absent from dist/, and outside the totals used here.

AAMP has no version number to pin

The hub README explains why: "Each repository uses independent semantic versioning." It also claims "The AAMP Hub references stable releases for ecosystem clarity", then references no release and no tag anywhere in the file, only six repository URLs.

IAB Tech Lab's standards page uses the link text "AAMP 2.3". The pattern AAMP <number appears in none of the eight repositories that same body publishes.

AAMP's wire contract is a pre-release library that neither IAB index lists

Quote, Deal, Negotiation Round, Access Tier, Trust Status, Avails and Media Kit all come out of one repository, iab-agentic-primitives: 48 JSON Schemas and an OpenAPI 3.1.0 document with 13 paths, against a hub repository that holds a README and a licence file. The library's README opens:

 ⚠️ WORK IN PROGRESS — NOT YET RELEASED. This library is under active construction as part of the buyer/seller agent remediation. APIs, schemas, and package layout are unstable and will change without notice. It is not yet an official IAB Tech Lab release and should not be depended on for production use until this notice is removed.

Both shipping agents depend on it by git URL at runtime, pinned to v0.5.0 in seller-agent/pyproject.toml and buyer-agent/pyproject.toml.

It appears in neither of IAB's own indexes: not in the hub README's six repositories, not in the four listed on iabtechlab.com. The size of an AAMP integration is set by this library, not by the hub. Every AAMP term page here repeats the pre-release caveat inline.

What this glossary leaves out

A claim that spans both corpora is a reading of both rather than a statement either party makes: no file in the eight AAMP repositories mentions AdCP under any spelling, so the term-by-term correspondences are mapped separately and the architectural argument is on Agentic Ad Lab.

Four files in the agentic-audiences specification tree are zero bytes, including specs/v1.0/schema/agentinterface.schema.json. Three operations in the AAMP wire contract define one side of the exchange only: AgentDiscovery has a request schema and no response, ChangeRequest and NegotiationRound a response and no request. Where a term would depend on an empty file, the entry states that the specification does not define it.

CPM, CPC and the rest of the commodity vocabulary get no entry. A commodity term appears only inside the entry that owns its non-obvious encoding: money on the AAMP wire is an integer count of micros with float explicitly banned, so that sits on Quote, and the PG / PD / PA deal-type enum sits on Deal.

Corrections and version drift

Where a page here disagrees with the file it cites, the file is correct. A correction needs a file path and a commit to be actionable, and where the defect is upstream an issue on the specification repository is the better fix.

Pinning a commit does not mean the pinned release is current. AdCP cuts patch releases every few weeks, and what matters is whether a patch moved anything defined here. Between 3.1.10 and 3.1.13 nothing moved: the registry is unchanged across the two releases, 64 operations across ten areas in both, and get-products-request.json, product-filters.json and create-media-buy-request.json are identical apart from the version string in $id and $ref.

Non-affiliation

Ad Tech Glossary is part of the Agentic Ad Lab portfolio and independent of everyone it writes about. No affiliation with, sponsorship from or endorsement by AgenticAdvertising.org, IAB Technology Laboratory, or any company contributing to their repositories. AdCP, AAMP, OpenRTB, OpenDirect, AdCOM and the IAB name belong to their owners.

---

# Sponsored Intelligence

Source: https://adtechglossary.com/concepts/sponsored-intelligence/

Sponsored Intelligence (SI) is AdCP's name for advertising on AI surfaces, and it covers two things: a stable media channel bought through get_products, and an experimental four-operation chat protocol for brand-agent sessions.

Sponsored Intelligence (SI) is AdCP's name for advertising on AI assistant surfaces. AdCP's glossary puts it by analogy: "Like VAST defines video ad serving, SI defines how to serve and interact with brand agent endpoints. SI handles the engagement; the Agentic Commerce Protocol (ACP) handles transactions."

The name covers two things: a media channel bought with the ordinary media-buy calls, and a four-operation chat protocol whose 14 schemas are all marked experimental.

In programmatic, a thin bid request describes an opportunity to a bidder that holds no context about the user. Under SI the party holding the user context selects the advertising: the brand publishes an offering and the assistant host pulls it, and sigetoffering returns "offering details, matching products, and an offering token for session continuity" with no user PII in the request.

Brian O'Kelley, Scope3's CEO, published "Sponsored Intelligence and the Trillion Dollar Sentence" on 19 January 2026, and AdCP adopted the phrase in its SI chat protocol document.

One name, two stability levels

|                   | The channel                                                                                                                                      | The chat protocol                                                                                                    |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| Where it lives    | enums/channels.json, 1 of 20 values                                                                                                            | the sponsored-intelligence schema group, 14 files |
| How it is used    | channels: ["sponsoredintelligence"] on a product, then getproducts, createmediabuy, getmediabuydelivery | sigetoffering, siinitiatesession, sisendmessage, siterminatesession                                  |
| Stability marking | no x-status; ordinary 3.x guarantee                                                                                                            | x-status: experimental on all 14                                                                                   |
| Runtime gate      | none                                                                                                                                             | seller MUST declare sponsoredintelligence.core in experimentalfeatures                                         |
| What it carries   | sponsored responses, AI search results, generative display and video                                                                             | brand experience handoffs                                                                                            |

AdCP publishes this split once, in overview.mdx: "SI uses two protocol layers... Most SI products... only involve the buying layer." Most SI inventory is bought with the ordinary media-buy calls and never touches the chat protocol: only one of the four SI product types AdCP lists calls an si operation.

What the experimental stamp permits

An experimental marking permits breaking changes inside a minor release. Inside 3.x an experimental surface can rename or remove fields, change types, drop enum values and rename tasks, on six weeks of notice; a stable surface gets six months and cannot break inside the major line. AdCP requires two markers for one: x-status in the schema, and a runtime declaration by the seller. experimental-status.mdx is blunt about the second:

 A seller that implements any experimental surface MUST list it in experimentalfeatures... there is no "silently experimental" mode.

Buying the channel is ordinary 3.x work, because x-status does not inherit through $ref by explicit rule and neither core/product.json nor the media-buy group carries one. Implementing the chat protocol means pinning a schema version, re-validating on each minor release, and budgeting for a rename nobody on the implementer's side chose.

No SI schema has changed since 3.1.0, so the experimental marking has not yet been exercised. The experimental note appears on 11 documentation files; product-spectrum.mdx, which distinguishes the two layers, does not carry it.

Sponsored context and disclosure

Three schemas landed in 3.1.0 and turned paid context into a typed object. si-sponsored-context names the payingprincipal, the contextuse and a disclosureobligation with label text and timing. si-context-use is a three-value enum, presentationonly, comparisonset, reasoningcontext, and it sets how far into the assistant's own reasoning the paid material may travel.

si-sponsored-context-receipt is the host's recorded answer, and the one link where the schema constrains behaviour. The host answers accepted or rejected, and an acceptance has to echo back the same contextuse it was handed and carry a disclosurecommitment that promises to satisfy the disclosure obligation. There is no room to negotiate downward: "a host that cannot honor the declared use mode rejects the sponsored context instead of down-scoping it."

The receipt is an audit artifact. AdCP names no enforcement body and leaves the obligation to the parties, and si-context-use says as much, calling itself "a boundary declaration, not a claim that AdCP can inspect hidden model reasoning..."

UI components

Six components are MUST-render — text, link, image, productcard, carousel and actionbutton — and apphandoff and integrationactions are MAY. specification.mdx sets the split: six "Standard components", then "Hosts MAY support additional components". Only the six are safe on a core path, because specification.mdx makes a core dependency on the other two a MUST NOT.

Three files in the same release list different component sets.

| File                                          | Count | What it lists                                                                              |
| --------------------------------------------- | ----- | ------------------------------------------------------------------------------------------ |
| sponsored-intelligence/si-ui-element.json   | 8     | text, link, image, productcard, carousel, actionbutton, apphandoff, integrationactions |
| si-capabilities.json, components.standard | 6     | the same list minus apphandoff and integrationactions                                |
| index.json, supporting-schemas description  | 7     | drops integrationactions, calls apphandoff standard                                  |

The registry index is wrong under either reading, and where the index and a schema disagree the schema wins.

Sponsored Intelligence in AAMP

AAMP defines no counterpart. Its repositories treat AI assistants as operator consoles for media professionals rather than as surfaces that carry an ad: seller-agent's documentation offers 46 MCP tools driven "from Claude, ChatGPT, or any MCP-compatible AI assistant".

AAMP's planes are direct booking, bidstream mutation and an embedding exchange. None models a session or a disclosure receipt, so there is nothing to map siinitiatesession onto, and the AdCP-versus-AAMP comparison covers the rest of the divergence.

Common confusions

The generic sense of the phrase owns no artifacts. A Sponsored Intelligence Summit was announced 21 July 2026, and the phrase is widely used for all advertising inside AI with no reference to AdCP; Scope3's own AdCP explainer does not mention Sponsored Intelligence.

Compute Sponsoring v1.0, published by wavebird in February 2026, is a separate proposal for advertising inside generative AI, priced on compute units. It states that its technical specifications and audit mechanisms remain to be introduced.

ACP is a different protocol. OpenAI and Stripe's Agentic Commerce Protocol handles checkout and payment delegation after the engagement, which is the other half of the same transaction rather than a rival.

Inside SI itself, the channel and the chat protocol get conflated. A sponsored link in a generated answer may be the channel without being the chat protocol: the chat protocol applies only when the placement went through the session handshake and carries the sponsored-context declaration.

---

# Trust Status

Source: https://adtechglossary.com/negotiation/trust-status/

Trust status is AAMP's five-value label on a counterparty agent - unknown, registered, approved, preferred or blocked - that caps the maximum access tier that agent may claim. Three of the five are set by a seller operator.

Trust status is the label an AAMP seller agent keeps on every counterparty it deals with, and it caps how much access that counterparty gets. There are five values: unknown, registered, approved, preferred and blocked. The definition sits in spec/jsonschema/protocol/AgentTrustVerification.json: "Registry-verified trust status of an agent. Determines the maximum AccessTier an agent can claim... trust is verified against the AAMP registry ... never self-asserted."

The five values

| Value        | Definition                                 | How an agent gets it                |
| ------------ | ------------------------------------------ | ----------------------------------- |
| unknown    | "Never seen before, not in any registry"   | Default on first contact            |
| registered | "Found in the IAB AAMP registry"           | Automatic verification against AAMP |
| approved   | "Manually approved by the seller operator" | Operator action                     |
| preferred  | "Strategic partner with premium access"    | Operator action                     |
| blocked    | "Explicitly blocked — zero data access"    | Operator action                     |

registered is the one value a machine assigns, and the two seller-agent documents define it differently: docs/api/agent-discovery.md as a lookup in the IAB AAMP registry, docs/api/authentication.md as a fetched agent card that has not been verified against any registry.

The seller agent's reference implementation draws the lifecycle as a line with one exit:

Trust status caps the access tier

TRUSTTOTIERMAP in the seller agent is the mapping that runs:

| Trust status | Maximum access tier | Pricing visibility                |
| ------------ | ------------------- | --------------------------------- |
| unknown    | public            | Published rate card only          |
| registered | seat              | Seat-level pricing                |
| approved   | advertiser        | Full advertiser-level pricing     |
| preferred  | advertiser        | Full pricing plus priority access |
| blocked    | None, rejected      | No access, HTTP 403               |

The effective tier is the lower of the trust ceiling and the tier the buyer's credential carries. docs/api/agent-discovery.md: "The buyer's effective tier is the minimum of their trust-based ceiling and their claimed identity tier." Access Tier covers what each tier unlocks.

The map is not part of the wire contract. RECONCILIATION.md: "the TRUSTTOTIERMAP policy table stays out of the contract", which makes it the seller reference agent's own policy. agency is one of the four AccessTier values and no row of the map produces it, so it is reached only through the credential side of the minimum.

How an agent gets a trust status

The normative protocol defines no operation that writes a trust status. POST /registry/agents/discover in spec/openapi/iab-agentic-api.yaml returns an AgentTrustVerification, and no operation there sets one.

A write path exists only in the seller agent, which puts list, get, discover, PUT .../trust and DELETE under /registry/agents behind an operator API key. A buyer key does not open it. spec/fixtures/protocol/AgentTrustVerification.golden.json carries conformance vectors for approvedbyregistry and unknownunregistered only.

The AAMP registry

The registry that verifies trust status is not publicly readable, and the three repositories name three different hosts: https://tools.iabtechlab.com/agent-registry in seller-agent, https://registry.aamp.iab.com/agent-registry in buyer-agent, and https://registry.iabtechlab.com in iab-agentic-primitives. The normative schema allows for more than one: AgentTrustVerification requires only agenturl and hangs four optional fields off it, agentid, truststatus, verifiedat and registryid, documented as the "Registry that answered, e.g. iabaamp".

Against the live agent registry the five-value enum collapses to two. SANDBOXREGISTRY.md records that "The registry has no self-asserted access-tier / trust-tier enum — trust is the verificationstatus + domainverified + iabmember triplet", and the buyer's adapter for that registry maps verificationstatus == "active" to VERIFIED and everything else to REGISTERED. STANDARDSGAPREPORT.md records that trust status semantics are asserted by the AAMP reference specification rather than against published IAB AAMP material.

Where the enum is defined

The normative definition is iab-agentic-primitives, which states that "The spec is the normative artifact; this package is its reference implementation" and has no released version. Each reference agent then redeclares the values, with no shared type between them.

| File                                                                                        | Values                                                | approved ceiling | blocked           |
| ------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ------------------ | ------------------- |
| iab-agentic-primitives spec/jsonschema/protocol/AgentTrustVerification.json (normative) | unknown, registered, approved, preferred, blocked     | schema is silent   | schema is silent    |
| seller-agent src/adseller/models/agentregistry.py                                     | same five                                             | advertiser       | None, hard reject |
| iab-agentic-primitives src/iabagenticprimitives/registryclient.py (LEGACY)           | same five                                             | agency           | public            |
| buyer-agent src/adbuyer/registry/models.py                                             | unknown, registered, verified, preferred, blocked | no tier map        | no tier map         |

The buyer agent writes verified where the other three write approved, in src/adbuyer/registry/models.py, and docs/api/seller-discovery.md mirrors it. PROTOCOLRECONCILIATION.md (2026-07-28) resolves verified down to approved and records "Buyer's card model and TrustLevel.VERIFIED retired". The buyer agent ships TrustLevel.VERIFIED in its 2026-08-05 commit.

The two ceiling maps differ on what approved unlocks and on whether blocked is a rejection or a floor. The seller's map is the one enforced at request time: computeeffectivetier stamps the ceiling onto every BuyerContext and the pricing engines read it from there, while the library's TRUSTTIERCEILING feeds only its own sandbox and the buyer agent reads no ceiling at all.

AdCP has no trust status

AdCP 3.1.13 defines no trust enum and nothing that grades a counterparty on a scale. The nearest-looking field, status in trusted-match/provider-registration.json, takes active, inactive or draining, which is lifecycle rather than trust.

It proves relationships pairwise instead, through signed declaration files: a publisher declares its sellers in /.well-known/adagents.json, a brand declares itself in /.well-known/brand.json, where agents[].jwksuri anchors the signing key, and a named house's brandrefs[] "MUST reciprocate for mutual-assertion trust. Single-hop only." Discovery files covers the mechanics.

Trust status, access tier and verification status

Trust status is the ceiling a seller keeps on a counterparty agent. Access tier is what that agent is allowed to see and pay on a given request, once the ceiling and its credential have been combined. Verification status is a field of the live registry, beside domainverified and iabmember, and is the input the buyer agent's adapter turns into a trust status.

---

# Trusted Match Protocol (TMP)

Source: https://adtechglossary.com/realtime/trusted-match-protocol/

Trusted Match Protocol is AdCP's serve-time execution layer: two operations, context_match and identity_match, kept structurally apart so page context and user identity never share a request, with the publisher joining the two responses locally.

The Trusted Match Protocol (TMP) is AdCP's serve-time execution layer: two operations, contextmatch and identitymatch, held structurally apart so that page context and user identity never travel in the same request, and neither operation can see what the other sees. Everything else in AdCP runs at planning time. TMP runs in the milliseconds while an impression is being decided.

The two operations

An OpenRTB bid request carries page context and user identity in one payload — user, device and page — handed to every bidder, with no contract governing what ends up in it. TMP splits that payload into two requests, sent to the same providers and answered separately. The publisher legitimately holds both halves, since the user is on their page, so it fires both and joins the responses itself.

|                | Context path                                                                    | Identity path                                                                                                                     |
| -------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Operation      | contextmatch                                                                 | identitymatch                                                                                                                  |
| Inputs         | property, placement, artifact, contextsignals, coarse geo, packageids | identities (1-3 hashed or vendor IDs), consent, country, sealedcredentials, packageids |
| Never receives | any user identity                                                               | any page context                                                                                                                  |
| Returns        | offers[], one per activated package                                           | eligiblepackageids[], servewindowsec                                                                                      |

The publisher intersects the two responses: the packages the context call says are offered, against the packages the identity call says this user is eligible for. It "performs the intersection of context match offers and identity match eligibility locally, after both responses arrive", ranks whatever appears in both lists, and renders the winning offer's creative manifest. servewindowsec caps what happens next: one impression per package, then a re-query of Identity Match before serving that package to that user again.

Who does what

The publisher fires both calls and joins the responses on its own infrastructure. A buyer agent exposes two HTTP/2 endpoints under one base URL, POST /context and POST /identity. Router selection is a deployment decision the publisher makes in advance, and the specification assigns no operator to the router.

What the schemas enforce

The separation is carried by the released request schemas, not only by the prose around them.

| Rule                                                                                                                              | Where it lives                                                                                                   |
| --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| "MUST NOT contain user identity" / "MUST NOT contain page context"                                                                | the two request descriptions                                                                                     |
| additionalProperties: false                                                                                                     | both requests, so a wrong field is rejected and not ignored                                                      |
| no ext, no context                                                                                                            | both requests: "extension data in the context path could inadvertently carry or correlate user identity signals" |
| requestid MUST NOT correlate across the two calls                                                                              | both requests, in both directions                                                                                |
| packageids "MUST NOT vary by user"                                                                                             | context request                                                                                                  |
| packageids "MUST be statistically independent of the current placement", so the list cannot be used to correlate the two calls | identity request: all-active, or fuzzed and "optionally padded with synthetic non-existent IDs"                  |
| country stripped before forwarding; geo "Coarsened ... no postcode, no coordinates"                                           | identity and context requests respectively                                                                       |

Both TMP requests omit ext and context, which every other AdCP operation carries. The package-set rule blocks an inference: a per-user package list would let a buyer correlate the two calls while both requests stayed within their field lists. Field-by-field tables for both operations sit on AdCP Explorer.

The TMP Router

Both requests go to a router. It fans each one out to the providers the publisher configured, merges the answers per path, and returns two responses. Both streams cross a single process: "a single binary with two structurally separate code paths: one for context, one for identity", where "The two paths share no state: no shared memory, no shared database, no communication channel, no shared logs or telemetry."

Without a trusted execution environment, that isolation rests on code audit. Providers cannot check the router's filtering themselves, and the default deployment asks every participant to trust that whoever runs the router runs the published binary unmodified. AdCP's position: "TEE is an upgrade path, not a prerequisite. The protocol works without it."

The router ships as a stateless container image, ghcr.io/adcontextprotocol/tmp-router:latest, so a publisher can self-host one per point of presence; the privacy pages also assume a "router operator" the publisher takes on trust. It runs on a 50ms clock, and if every provider misses, the response comes back empty.

Scope of the guarantee

AdCP scopes its own claim:

 This is not an end-to-end guarantee that buyers can never correlate identity and context: in TMPX deployments, the buyer's impression tracker receives decrypted identity alongside a creative selected using page context.

TMPX is an optional extension that re-links the two halves at impression time. Each value is "an HPKE-encrypted exposure token that flows through creative tracking URLs to the buyer's impression pixel", the mechanism for per-user frequency capping. Neither tmpx nor tmpxproviders is required on the response, so a publisher that omits it gives up per-user exposure counting.

AdCP names two further limits: multiple identities in one request give the buyer cross-identity equivalence it did not have before, and a narrowly targeted package implies the page context.

An experimental surface inside a stable release

All twelve files in dist/schemas/3.1.13/trusted-match/ are stamped "x-status": "experimental", and 3.1.13 is the stable channel.

The flag lets AdCP rename fields, remove them or change their type on six weeks' notice in the release notes, "a deliberate relaxation of the 6-month deprecation notice that applies to stable surfaces". It has been exercised: tmpxmacros sat on identity-match-response.json from 3.1.1 through 3.1.8 and was removed at 3.1.9, inside a patch line.

AdCP's register gives the reason the flag is still on: "Privacy architecture is thinly specified relative to what a regulator deep-dive will demand." Release notes promised a "stable surface targeted for 3.1.0". The reference documentation has drifted with it: docs/reference/glossary.mdx says Identity Match "Returns a boolean eligible flag and optional intentscore per package", and neither identifier appears in any released schema.

AXE, and why TMP replaced it

AXE is the Agentic eXecution Engine. migration-from-axe.mdx has the pair solving "the same problem — impression-time execution for pre-negotiated packages — with different architectures. AXE sends a full request (user + context + device) and returns opaque segment IDs." The deprecation ships in the schemas too: axeincludesegment, axeexcludesegment, requiredaxeintegrations and axeintegrations are all flagged "deprecated": true. AXE was deprecated at 3.0.0.

Serve time in AAMP

AAMP hands the OpenRTB payload itself to in-path containerised agents, which return mutations with a declared intent attached. The join TMP forbids is ARTF's normal case: samples/banner-basic.json puts user.id, yob, gender, DMP segments, device ua, ip, geo and the full page URL in one message. AdCP removed ext from both TMP requests because extension data could correlate identity; ARTF keeps it as a design principle, "including use of 'ext' objects for any nonstandard, extended signaling". Neither specification references the other.

---