AAMP Explorer

AAMP Explorer

AAMP

AAMP, Agentic Advertising Management Protocols, is IAB Tech Lab's stack for buyer and seller software transacting media without a human in the loop: discovery, negotiation, booking and serve-time bidstream mutation, across 8 independently versioned repositories.

AAMP spans three planes — control, real-time and data — and they share no type system.

The hub README lists six repositories. The corpus is 8: those six, the hub itself, and iab-agentic-primitives, which the README omits and which both reference agents hard-pin as their wire contract. That repository's README opens by calling itself a work in progress, not yet released, with schemas that "will change without notice".

AAMP has no single version number

IAB Tech Lab's press release of 30 July 2026 announces AAMP 2.3. That string appears in no repository in the corpus. The nearest artifact is a v2.3.0 tag the buyer and seller agents both cut on 2026-07-22; the seller agent has cut five more releases since, ending at v2.4.1. The hub README states the policy: Each repository uses independent semantic versioning. Four of the 8 repositories carry no git tag at all.

All 8 repositories as they stood on 12 August 2026, ordered by how much specification each one carries, on the ranking test. Untagged means the repository has no git tag and its only version is a commit SHA. buyer-agent's v2.3.0 is 24 commits behind the branch it points into.
Component Version Kind
agentic-rtb-framework v1.0 specification
iab-agentic-primitives v0.5.0 specification
seller-agent v2.4.1 reference implementation
agentic-audiences untagged specification
agentic-direct untagged reference implementation
buyer-agent v2.3.0 reference implementation
AAMP untagged hub
registry-agent-example untagged example

The buyer and seller agents both took commits in August 2026. agentic-direct, listed first in the hub README under core orchestration, has no commit since January 2026. The hub repository was created in February 2026.

The booking exchange, request and response

The golden vectors in the wire contract carry one worked exchange. The buyer posts an AvailsRequest to /products/avails: a product id, a flight start and end, and optionally the volume it wants, the budget it will spend and the targeting it needs. The example asks for 500,000 impressions against a budget of 6,000 on prod-001, targeted to US mobile. The seller answers with an AvailsResponse: availableImpressions 750,000, guaranteedImpressions 500,000, estimatedCpm 12.0, totalCost 9,000. Only availableImpressions is required. A seller with no forecast of its own returns deliveryConfidence null and is still conformant, so a buyer agent cannot rank two sellers on the required fields alone.

That is one of the thirteen paths in the shared contract's OpenAPI, and the thirteen are the whole booking path: list products, check avails, quote, book, raise a change request, exchange negotiation messages, discover an agent, fetch its agent card. The schema files behind those paths define eight request and response pairs.

Control plane, real-time plane, data plane

IAB Tech Lab's standards page divides AAMP into foundations, protocols and trust. These three planes divide it instead by what each repository operates on: planning time, serve time, signal exchange.

Control plane
Planning and transaction time: discovery, avails, quotes, negotiation, deal booking and change requests between buyer and seller agents.
Real-time plane
Serve time: in-path agents mutate an OpenRTB bid request or response.
Data plane
Signal exchange: embeddings with consent, TTL and attestation metadata.

buyer-agent, seller-agent and iab-agentic-primitives, the wire contract both agents import, make up the control plane. The real-time plane is agentic-rtb-framework, ARTF in the corpus: a versioned prose specification with a protobuf contract under it. agentic-audiences, one vendor's embedding-exchange draft, is the data plane on its own.

ARTF addresses a deal by its OpenRTB dealid inside the bid request. No file maps that to the control plane's canonical Deal.json, which hangs eighteen properties off deal_id, and neither repository states whether a serve-time agent resolves the identifier back to the booked deal or only carries it.

Both reference agents consume embeddings by vendoring a copy of the agentic-audiences specification into data/taxonomies/, byte-identical to the live repository including all four of its zero-byte files. The shared wire contract they both import calls itself the single source of truth for every cross-agent primitive and holds no embedding type, so each agent hand-maintains its own ucp.py: 384 lines in the buyer, 379 in the seller.

Two dependency pins and two README references

Only two of the 8 repositories are joined by anything a build resolves: buyer-agent and seller-agent each pin the wire contract. Counting every reference from one repository to another outside the hub's link list, there are four: those two pins, the agents' references to each other, and the agentic-audiences README pointing back at the agents. Three repositories carry no such reference in either direction: agentic-direct, registry-agent-example and agentic-rtb-framework. Of those three, only agentic-rtb-framework ships a specification document; agentic-direct ships an MCP demo and registry-agent-example 22 lines of sample code.

No repository outside agentic-rtb-framework imports or references ARTF. The only external mentions are the hub README link list and a comment in a seller-side Index Exchange client that calls it a coalition.

Two repositories ship a default registry address and they disagree. The seller agent's guide records its own registry integration as stubbed pending a specification that does not exist, and no file in the corpus decides which host is correct. What ships is two defaults: tools.iabtechlab.com/agent-registry in the seller agent, registry.iabtechlab.com in the primitives client library.

The gaps sit in the wire contract and in agentic-audiences

Three of the wire contract's protocol objects are half-defined: a request or a response without its counterpart. The four empty files in agentic-audiences have one commit each and no edit since October 2025, and specs/v1.0/schema/agent_interface.schema.json is where the interface between agentic-audiences and the rest of AAMP would be.

3 of the 8 repositories carry a contract another implementer has to match

An AAMP integration built today rests on two documents: the wire contract's OpenAPI for the message format, and the seller agent's OpenAPI for what a working counterparty exposes. Eleven of the wire contract's thirteen paths appear verbatim among the seller agent's 74. The two that do not are /a2a/jsonrpc, which the seller does not implement, and the negotiation fetch, which it serves from a path of its own. ARTF applies only in the bidstream and nothing joins it to the other two. Neither document is stable: the wire contract is at v0.5.0 under a README that opens WORK IN PROGRESS — NOT YET RELEASED. Discovery code has no specification to target, because the corpus does not say which registry host to call.

No AAMP repository references AdCP. The strings AdCP, Ad Context Protocol and adcontextprotocol.org appear in no file in the corpus, so the comparison of the two stacks is assembled from outside both.

Frequently asked

Is AAMP a specification or a set of reference implementations?
Both. The real-time framework and the shared wire contract are specifications. The buyer and seller agents are working applications whose documentation is the closest thing AAMP has to a control-plane specification. Two repositories define nothing normative: the hub is a README, and the registry example is 22 lines of sample code.
How does AAMP relate to AdCP?
They overlap in scope and neither cites the other. No AAMP repository references AdCP anywhere, so the two stacks can only be compared operation by operation from outside both.

Related