AAMP Status: What IAB Tech Lab Has Published, and What Pinning It Gets You

AAMP is a label over eight IAB Tech Lab repositories. One of them, the Agentic Real Time Framework (ARTF), carries a numbered, dated, released specification, and it governs bid mutation rather than buying. The other seven are the wire contract, the two reference agents that import it, a draft specification, an OpenDirect wrapper, a 22-line sample and a link page.

Both reference agents pin the wire contract by a tag that carries no tagger and no date, and the package that tag installs reports a version four tags behind the one it names.

Outside ARTF there is no published document to conform to and no conformance suite anywhere in the eight repositories, so “conforms to AAMP” is not an enforceable contract term. One artifact in the set does check something, and it checks inward: iab-agentic-primitives/CONFORMANCE.md, 161 lines committed on 2026-07-13, documents a runnable checker with exit codes, nine check kinds, golden fixtures and a machine-readable gap_report.json, and both agent repositories run it in CI. What it verifies is the library against its own spec artifacts, not any published standard. Its registry of external standards is explicit about the difference:

“We model a field named after the standard” is not “we verified conformance against the published standard” […] the following remain UNVERIFIED […]: OpenDirect 2.1, IAB Deals API v1.0, AAMP, A2A/JSON-RPC (published-spec fidelity), AdCOM/OpenRTB supply chain, sellers.json/ads.txt, GPP, and TCF.

AAMP is on the unverified list inside AAMP’s own wire contract. A repository and a git tag named in the agreement make a minor release a change event under that agreement rather than a field that moved without notice.

What the AAMP label covers

AAMP covers agent-to-agent media buying: a buyer’s agent and a seller’s agent discovering inventory, agreeing a price, placing the order and reporting the delivery, over a shared vocabulary of objects called Product, Deal, Quote, Negotiation and Order. The transaction has two parties and no human intermediary. Those objects are what a machine buy moves back and forth.

The eight repositories, read at eight commits

Two passes ran on 16 August 2026. Locally: git describe, git cat-file -t and git for-each-ref over clones of all eight repositories, plus file reads at the commits in the table. Remotely: raw.githubusercontent.com at named refs, and the GitHub API for tags, releases and repository names. The clones stop between 2026-01-27 and 2026-08-05, so every claim about something newer than that carries its own observation date in the sentence.

Repository	git describe	Commit date	What it is	Primary artifact
agentic-rtb-framework (ARTF)	v1.0-1-g7f48161	2026-07-21	Specification, with Go and Rust reference implementations	Agentic_Real_Time_Framework_Version_1_0_FINAL.md, plus protobuf
seller-agent	v2.4.1	2026-08-05	Reference implementation	OpenAPI 3.1.0, 74 paths, 91 component schemas
buyer-agent	v2.3.0-24-g0c3a154	2026-08-05	Reference implementation	OpenAPI 3.1.0, 13 paths, 8 component schemas
iab-agentic-primitives	v0.5.0-1-g2fc7029	2026-07-28	The wire contract, absent from the hub README	48 JSON Schemas, 22 of them top-level; OpenAPI, 13 operations
agentic-audiences	106ebd6, no tags	2026-07-27	Draft specification, a Prebid module example, a scoring service	specs/v1.0/embedding-exchange.md, headed “Draft v0.1”
agentic-direct	915bda9, no tags	2026-01-27	A2A and MCP wrapper over OpenDirect 2.1	opendirect.json: 40 schemas, 33 tools, 13 resources
AAMP (hub)	3b20e67, no tags	2026-04-16	Link page	README only
registry-agent-example	1ff8dda, no tags	2026-02-24	The registry sample	one 22-line agent.ts

Three of those eight are past their newest tag, which is why the column holds a git describe string rather than a version. Four have never carried a tag at all.

Two of the eight repositories carry the working surface: iab-agentic-primitives, the wire contract both reference agents import, and then seller-agent or buyer-agent depending on which side of the transaction an implementer sits. ARTF applies to exchange operators, and carries a licence obligation. The hub, the 22-line sample, the OpenDirect wrapper and the draft embedding specification hold no implementable contract.

The hub README names six children; it does not name iab-agentic-primitives, and counting the hub itself brings the set to eight. ARTF has also been renamed. The GitHub API returned IABTechLab/agentic-real-time-framework as its full name on 16 August 2026, and the old agentic-rtb-framework path redirects.

The label itself does not resolve to one thing either. The AAMP acronym is expanded four different ways across the hub, both reference agents and the primitives library, and no document in the eight repositories picks between them. AAMP Explorer keeps the file-and-line account.

Two units are live on the agent repositories, and both circulate. seller-agent publishes 74 paths carrying 87 path-and-method operations; buyer-agent publishes 13 paths carrying 14. The unit this site uses for AAMP is the path.

agentic-direct’s first external issue, filed 2026-06-02 by nattaylor and still open, reports that clicking Search Products returns Tool execution failed: Tool not found: undefined, and proposes renaming the button “Search Products Mock”. That repository was last pushed on 2026-01-27.

In agentic-audiences, four files under specs/ are zero bytes: roadmap.md, both v1.0/examples/ payloads, and v1.0/schema/agent_interface.schema.json, which is the file that would say how a buyer or seller agent exchanges the embeddings the rest of the specification describes. That empty schema is the reason the draft cannot be built against, whatever its prose promises.

What @v0.5.0 installs

Both buyer-agent/pyproject.toml and seller-agent/pyproject.toml carry one dependency string, character for character:

iab-agentic-primitives[client] @ git+https://github.com/IABTechLab/iab-agentic-primitives.git@v0.5.0

Both repositories still carry that string at tag v2.4.1, read from raw.githubusercontent.com on 16 August 2026. That tag is newer than either clone, and on buyer-agent it is newer than the v2.3.0-24-g0c3a154 the table above pins.

Install it and the distribution reports 0.1.0. pyproject.toml says version = "0.1.0" at every tag from v0.1.0 to v0.5.0, and at v0.5.0 the module hardcodes __version__ = "0.1.0" as well, so the two surfaces an environment record reads agree on a number that stopped being true four tags ago. An external implementer filing as jaanijuk published the reproduction in iab-agentic-primitives issue 2 on 2026-07-31, with pip show and the module attribute side by side, and a table of the version string at each of the five tags.

The fix landed. Commit ee9ea3c1, dated 2026-08-10 and titled “Single-source the package version from installed metadata (#2)”, sets the project version to 0.5.1 and derives __version__ from distribution metadata; it was cut as v0.5.1 and published as the repository’s only GitHub Release. Neither reference agent has shipped a release that takes it: seller-agent and buyer-agent both tag v2.4.1 as their newest release, and both of those still pin v0.5.0, read on 16 August 2026.

The wire contract’s own README opens with a release-status banner:

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 reference agents therefore depend on a 0.5.0 pre-release whose README states it is not an official IAB Tech Lab release.

Nothing in the eight repositories promises that a minor release will leave a field in place, so an integration tracks an exact tag rather than a branch. Measured against these repositories, the tag is not the durable half of that instruction.

A lightweight tag carries no tagger, no date and no signature

Tag objects, read with git cat-file -t at the local clones on 16 August 2026, and against the remote for the tags cut since. iab-agentic-primitives annotates v0.1.0, v0.2.0 and v0.3.0, then stops: v0.4.0 and v0.5.0 are bare commit refs, and v0.5.0 is the exact tag both reference agents pin. ARTF’s v1.0 is bare too. seller-agent leaves seven of its twelve bare, v2.1.0 and then every tag from v2.2.0 to v2.3.2, and buyer-agent three of its six, v2.1.0, v2.2.0 and v2.3.0. Both agents annotate again at the top, at v2.3.3 and above on seller-agent and at v2.4.1 on buyer-agent, so the agent tag an implementer would pin today does carry a tagger and a date. The tag it would pin on the wire contract does not, and the v0.5.1 cut on 10 August 2026 is the first annotated tag there since v0.3.0.

Dates go first. ARTF’s v1.0 points at commit 8e4e07ac, whose commit date is 2026-07-14. The tag itself has no date, because a lightweight tag has nowhere to put one, so “the v1.0 tag was cut on 14 July” is not derivable from the repository, and neither is a cut date for seller-agent v2.3.1 or buyer-agent v2.3.0. What those tags date is the commit underneath.

Where a tag does carry a date, the date can be a long way from the code. seller-agent’s v2.0 is annotated, tagger date 2026-07-08, pointing at commit 0f544a54 dated 2026-04-17. Twelve weeks separate the two, and nothing in the repository says which of them an agreement should name.

jaanijuk reports, in the same issue, having filed tag drift against seller-agent in July, a pinned tag resolving to three different commits inside five days, and says the team moved to immutable tagged point releases in response. That report is quotable and it is not reproducible from these clones: there is no reflog, no FETCH_HEAD, and the GitHub API exposes no tag history.

Which leaves one identifier that survives a re-point: git rev-parse v0.5.0^{commit} returns 5fdbe5731c84d00e1529c78d4ec77c1f7169dcd7. That string is what an agreement can name, what a build can assert, and what a counterparty can be held to. pip show cannot tell you which commit you are running.

Three interface documents name a version their repository does not use

iab-agentic-primitives stamps info.version: 0.1.0 on spec/openapi/iab-agentic-api.yaml at v0.5.0, and still stamps 0.1.0 at v0.5.1. The August fix reached the package metadata and not this file. seller-agent/docs/api/openapi.json stamps info.version: 1.0.0 at tag v2.4.1. buyer-agent/docs/api/openapi.json stamps 1.0.0 at tag v2.4.1. Every generated interface document in the set names a version its own repository does not use, which means an integration that version-checks the OpenAPI document instead of the commit learns nothing.

The hub’s release model, held against GitHub

What a version number means across these repositories is answered in one place, in prose. The hub README states four bullets:

• Each repository uses independent semantic versioning.
• Releases are published via GitHub tags and release notes.
• Cross-repository alignment occurs via governance coordination.
• The AAMP Hub references stable releases for ecosystem clarity.

Tags counted against GitHub Releases through the API on 16 August 2026: seller-agent 12 tags and 11 Releases, buyer-agent 6 and 6, ARTF 1 and 1, iab-agentic-primitives 6 tags and one Release. AAMP, agentic-audiences, agentic-direct and registry-agent-example have neither.

The second bullet fails hardest on the repository the other two import. Five of the wire contract’s six tags carry no release notes, so for five of them there is no published statement of what changed.

The hub itself was last committed on 2026-04-16, before the release cycle its fourth bullet promises to reference. AAMP Explorer keeps the per-repository version matrix.

ARTF is the published specification, and its machine-readable half does not build

Agentic_Real_Time_Framework_Version_1_0_FINAL.md opens on four lines: “A specification for using agent-driven containers in OpenRTB and Digital Advertising”, then “Version 1.0”, then “Released November 12, 2025”, then the IAB Technology Laboratory copyright. Glossary, table of contents, agent manifest section, API design section. It is tagged v1.0 in git and published at iabtechlab.com/standards/artf. It is a numbered document with a protobuf schema and five worked payloads behind it, implementable from the published text without reading anyone’s Python.

“Agent-driven containers in OpenRTB” means an agent changes a bid request or a bid response while it is in flight, and the change rides inside the bid object stamped with the intent behind it, so the system on the other end reads what was done instead of inferring it from the numbers. Both sides may do it, and the enum carries sell-side and buy-side entries in one list. The protobuf package com.iabtechlab.bidstream.mutation.v1 defines RTBRequest, RTBResponse and Mutation, and the five worked RTBRequest payloads in samples/ cover banner, bid shading, multi-impression, native and video deals.

Building the protobuf half is a different exercise. An engineer at Equativ, filing as jchambon-equativ, opened issue 11 on 2026-05-28. Line 6 of proto/agenticrtbframework.proto imports com/iabtechlab/openrtb/v2.6/openrtb.proto; the file sits at proto/com/iabtechlab/openrtb/v2/openrtb.proto. Line 1 declares edition = "2023"; the committed generated Go records protoc v3.21.12 in its header, a 2022 release that predates editions. And the OpenRTB proto declares optional bool coppa = 1, while samples/multi-impression.json and samples/native-ad.json write "coppa": 0 where samples/video-deals.json writes false. Two of the five worked payloads therefore fail protojson, which is the “expecting boolean; instead got 1” that Equativ reported. All of it is still true at the commit in the table above, dated 2026-07-21, nearly eight weeks after the issue was filed.

Two competing “intent” vocabularies coexist inside the one specification: the protobuf enum says what a single edit is for, the container’s Agent Manifest declares broad capability categories, and no published mapping joins the two, so an orchestrator matching one against the other is guessing. There is a sharper instance of the same defect, and it has a named victim.

The specification prose names five camelCase intents; three of them, expireDeals, adjustDeals and adjustBid, have no member in the Intent enum, which runs ACTIVATE_SEGMENTS, ACTIVATE_DEALS, SUPPRESS_DEALS, ADJUST_DEAL_FLOOR, ADJUST_DEAL_MARGIN, BID_SHADE, ADD_METRICS and ADD_CIDS, plus an unspecified zero value. On 2026-03-06 the CTO of Supply Finder, filing as AntoineJac, opened issue 10 asking how the framework stops a container mutating deals it does not own, and framed the whole question around “expireDeals or adjustDeals”. Neither exists on the wire. That issue and Equativ’s were both still open on 16 August 2026.

Licensing splits the repository in two. The Go reference implementation is AGPL v3 under a 2025 Index Exchange copyright, and section 13 of that licence, Remote Network Interaction, extends the offer of source code to everyone who interacts with a modified version over a network, which is what running it as a service is. The specification text is CC BY 3.0, and the three repositories an implementer actually imports, iab-agentic-primitives, seller-agent and buyer-agent, each ship an Apache 2.0 LICENSE, so the copyleft obligation is ARTF’s alone. A proprietary exchange has two routes to ARTF: reimplement from the CC BY 3.0 specification text, or open the service. The procurement reading of that choice is on AdCP versus AAMP.

What the 30 July announcement put in the repositories

IAB Tech Lab announced AAMP 2.3 on 30 July 2026, promising enterprise-ready deployment, integrated privacy diligence, stronger pricing integrity and broader platform support. The release was picked up by MediaPost, ExchangeWire, TV Tech and thedesk.net, the last describing these as “finalized standards designed for production use”. Adgentek, a founding member of AdCP, calls 2.3 “a hardening release”.

Searched on 16 August 2026 across all 1,303 files in the eight repositories at the commits above, the literal string “AAMP 2.3” returns zero matches, and it matches no tag, release or version field either, so an agreement naming it has nothing in the repositories to point at.

What did land is traceable. Integrated privacy diligence is diligence_status on ConsentContext, a four-value enum, unknown, pending, passed, failed, defaulting to unknown and documented as “SGP = SafeGuard Privacy / IAB Diligence Platform”. ConsentContext has eight properties and requires none of them, and its own description states that “Strings are carried opaque: no decoding/vendor-list validation is claimed”. It travels with Deal, Quote and Order. A counterparty asserting privacy diligence over AAMP is asserting a default-unknown string that nothing on the wire checks.

The named contributions land as vendor client code in one reference implementation. “Mixpeek” appears in 14 files, every one of them inside buyer-agent. “SafeGuard” appears in 22, split across buyer-agent, the primitives schemas and seller-agent. HyperMindZ’s announced Deals Sync MCP Server appears in zero files across all eight repositories, which does not tell you whether it is unreleased or simply held somewhere else.

The sharpest instance is the audience repository. The 30 July release says “Agentic Audiences v1.0 ready for transactions”. specs/v1.0/embedding-exchange.md line 1 reads “Agentic Audiences Contextual Embedding Exchange Specification (Draft v0.1)” and line 3 reads “Status: Draft”. specs/v1.0/ is a directory name; the repository carries no git tags. Its README describes the work as “LiveRamp’s initial proposal”.

The control plane has no document, only running code

A term written into an agreement can move on a minor release with no deprecation cycle and no obligation to announce it, because the definition lives in a reference implementation rather than in a ratified document. Access tier, trust status, negotiation round, media kit, quote and avails all trace to Python and generated OpenAPI in seller-agent, which moved from v2.3.1 to v2.4.1 inside a fortnight. Negotiation is the widest case, 74 OpenAPI paths and the Python behind them, with no prose definition anywhere.

The buyer/seller control plane has no document to implement, only running code. Two implementers can also read the same repository and reach different conclusions, with nothing to arbitrate between them: no conformance document exists in the eight repositories. The wire contract’s checker does not close that, since what it verifies is one library against its own spec artifacts.

So which repository and which ref to build against becomes a question someone has to ask in public. jaanijuk asked it in buyer-agent issue 114 on 2026-07-25, standing the two public agents side by side for an IAB Australia pilot cohort: “What’s the supported end-to-end demo path on current tags?” The same issue reports run-demo.sh at tag v2.0 resolving to a directory absent from any public checkout, and campaign_demo.py gone by v2.3.0.

The registry client is a stub, so trust is carried locally

Trust has to be carried locally, because AAMPRegistryClient is a stub until the registry API is published. seller-agent/docs/guides/agent-management.md states the registry position, under an H2 titled “Current Limitations”:

The IAB Tech Lab AAMP (Agent-to-Agent Marketplace Protocol) registry integration is stubbed pending the public API specification. Currently, agent trust is managed locally by the operator. The AAMPRegistryClient will be updated once the AAMP spec is finalized.

Agent discovery files cover what a publisher can assert on its own domain in the meantime, and what neither stack standardises covers the rest.

What an agreement can name today

Name the repository and the 40-character sha, not the tag. A tag is a name someone else can move: jaanijuk’s July report has one resolving to three commits in five days, and the immutable point-release policy the team adopted afterwards is a promise rather than something git enforces. The sha is also the only identifier in this set that an auditor can hold against what was actually installed a year later.

For the wire contract that is one line of your pyproject.toml:

iab-agentic-primitives[client] @ git+https://github.com/IABTechLab/iab-agentic-primitives.git@5fdbe5731c84d00e1529c78d4ec77c1f7169dcd7

That sha is v0.5.0, the commit both reference agents resolve to, and it is the one to pin if you are integrating against either of them. v0.5.1 (ee9ea3c1c612b1be6ae00b75e0ab1b81435f62cc) carries the version-metadata fix but has not shipped inside a tagged agent release, so no public agent has been run against it. The fix only matters to a build that reads version strings, and pinning by sha means yours need not. Any other repository in the set gives up its sha the same way: git rev-parse <tag>^{commit}.

Then verify by sha at install time rather than by reading a version string back out of the artifact. pip records the commit it resolved for a git dependency in the installed distribution’s direct_url.json, so a CI step comparing that value against the sha in your agreement fails the build the day a tag moves underneath you, and a counterparty can be asked to assert the same shas as an acceptance condition. A version string cannot do that job: three of this set’s interface documents and, until 10 August 2026, the wire contract’s own package metadata answer it wrongly.

A normative IAB Tech Lab document for the buyer/seller control plane, of the kind published for ARTF, is what would make “supports AAMP” a claim a counterparty can test.

One standards venue is named in the eight repositories, in ARTF: “This document is developed by the IAB Tech Lab Container Project Task Force which is a subgroup of the Programmatic Supply Chain Working Group.” The other seven name none, and a version number for them would surface first in a git tag, in the hub README or on the AAMP standards page, last updated 23 April 2026. No repository in the set publishes a roadmap or a meeting calendar: agentic-audiences/specs/roadmap.md is zero bytes, and that repository’s README says to “Join or start a working group under /community”, a directory whose only file is also zero bytes.