Agentic Advertising Standards: The Version You Can Put in a Contract

Six acronyms turn up in agentic buying conversations. Two cover advertising, AdCP and AAMP; the other four settle transactions a layer below it, and they are ACP, UCP, AP2 and x402. Only one of the two advertising standards publishes something you can put in a schedule. AdCP’s rule fits in a line: send adcp_version: "3.1" on the wire, never a patch component, and hold the counterparty to a support window AdCP has written down.

AAMP publishes no rule. Its shared wire contract carries six git tags, two of them lightweight, and every one up to v0.5.0 reports version 0.1.0 to whatever installs it. Outside its bidstream framework there is nothing normative in it to conform to, so “we support AAMP” today means “we match somebody’s Python”. There is nothing to point a contract at.

Back AdCP for anything on the campaign path, and treat everything below as the version evidence for that call. When a vendor quotes you 3.0 GA off the docs site, the schema registry is serving 3.1.14 and the wire contract only cares about "3.1" — that is a correction, not a re-scoping. On the AAMP side, write the vendor’s name into the integration plan instead of the standard’s, because the vendor is what you are integrating with. And keep the other four acronyms out of that budget line entirely.

The clause AdCP has already agreed to

AdCP, the Ad Context Protocol, publishes a versions page with a column headed “Wire pin”. 3.1 is Active, pin "3.1". 3.0 is Maintained, pin "3.0", defined there as “Supported previous minor for existing production integrations. Receives compatibility and security patches.” Underneath the table sits the instruction most readers never reach: “Wire values are release-precision only… Do not send patch components like "3.0.19" or full semver pre-release values like "3.1.0-rc.15".”

docs/reference/versioning.mdx then publishes a release cadence, which is the part a CFO defending a budget needs and the part nobody quotes. Each line below can be lifted into an agreement as it stands.

Clause line	The published commitment behind it
adcp_version: "3.1" travels on the wire; patches are not negotiated	“Wire values are release-precision only”
Anything built against 3.0 keeps working through the 3.x cycle	“implementations built against 3.0 will continue to function against any 3.x release”; versions.mdx adds that “3.1 remains additive over 3.0”
At least 12 months of security patches after the next major ships	Support for previous major after successor GA: minimum 12 months, backported for the full window
At least 6 months of notice before a field is removed	Deprecation notice before removal: minimum 6 months. Experimental surfaces run a separate 6-week window
No breaking release before 2027	Next major (4.0) targeted early 2027; majors a minimum of 18 months apart

That table did not appear on its own. bokelley opened issue 2312 on 18 April 2026 asking for a published cadence so implementers could plan. AAMP has nothing of this shape at any version, in any repository.

Who is promising the window?

AgenticAdvertising.org is the half of this that needs an introduction. CHARTER.md describes a Delaware trade association with 501(c)(6) status still pending, four voting classes with equal board representation (brands, agencies, publishers, technology providers), and a first AGM dated 6 May 2026. CONTRIBUTORS.md names an interim board of four, two of them from Scope3, and says outright that “Scope3 seeded AAO with foundational IP, funding, and the initial property-catalog knowledge graph”. That is a single-vendor protocol with a trade association forming around it, disclosed by the vendor, and I would rather price a published imbalance than guess at an unpublished one. AdCP vs AAMP prices the concentration.

Mediaocean, The Washington Post, Magnite, PubMatic and Yahoo appear on the external contributor list, which is participation rather than adoption; who actually runs an endpoint in production is a separate question with a separate answer, and the deployments ledger is where it gets kept.

AdCP standardises a buyer agent buying media from a sales agent, and the two operations you meet first are get_products, which asks a seller what inventory it has (natural-language brief or structured filters, your choice), and create_media_buy, which turns whatever comes back into a campaign.

Where AdCP’s effort went shows in the operation counts across its ten areas. Twenty-two of its 64 operations are governance, twice the size of the media buy area they sit next to: AdCP’s authors think the hard part of an agentic buy is proving what the agent was allowed to do.

AAMP comes from IAB Tech Lab, which wrote OpenRTB, AdCOM, OpenDirect and the Global Privacy Platform. That provenance normally settles a standards question on its own, which is what makes the current state of AAMP surprising: it is a name over eight separate GitHub repositories, each tagging on its own schedule, sharing no common type system and no common release.

Those eight repositories are the AAMP evidence base for everything below, and it is worth saying what they are before any claim rests on them. Each was cloned and read at the commit named in the artifact table near the end of this page, then re-checked on 16 August 2026: git describe, tag objects and file reads against the clones, then raw.githubusercontent.com and the GitHub API for tags, releases and repository names. That set is what “the corpus” means here, and it is public GitHub only. A member-facing IAB Tech Lab deliverable circulated through the Tech Lab’s own portal would not appear in it, so read every negative claim below as “not in those eight repositories on that date” rather than “does not exist”.

Four of these six acronyms settle transactions

The four named at the top of this page sit one layer down, where the money moves rather than the media.

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

The ACP and UCP rows are AdCP’s own glossary describing its neighbours; the AP2 and x402 rows come from Crossmint’s protocol comparison and the Applied Technology Index 2026 analysis, because neither has a primary specification behind it here.

The two layers meet at one documented handoff: in Sponsored Intelligence the host initiates ACP checkout when the termination reason is handoff_transaction, and the FAQ compresses the boundary to “AdCP owns the path up to the handoff; the commerce protocol owns the transaction.” No AdCP operation settles anything.

The payment references in the AAMP corpus are inherited rather than agentic: the OpenRTB handled-payment flag hp in the wire contract’s SupplyChain, Deal and DealBookingResponse schemas, and a “Payment ID chain (TAG Payment ID Protocol)” field on agentic-direct’s OpenDirect surface. Across the eight repositories at the commits cited here, no AAMP operation settles.

One collision in that table is real rather than sloppy. AdCP’s glossary uses “UCP” for Google’s Universal Commerce Protocol; the AAMP repository agentic-audiences was formerly LiveRamp’s User Context Protocol and has not finished changing its name. Its surviving JSON Schema still carries an $id pointing at raw.githubusercontent.com/LiveRamp/user-context-protocol, and its catalog-info.yaml still declares the project slug LiveRamp/user-context-protocol. A document saying “UCP” may therefore mean a commerce protocol or an advertising data plane, and nothing on the page will tell you which unless you ask who wrote it.

Thirteen patch releases in fifty-four days

The discipline on AdCP’s side does not mean its numbers sit still. Eleven patch tags landed on the 3.1 line in the fifty days between v3.1.0 on 18 June 2026 and v3.1.11 on 7 August, and the line did not stop there: 3.1.12 and 3.1.13 followed by 11 August. Thirteen patches in fifty-four days, roughly one every four days, and 3.1.13 is the release the pinned registry file quoted below carries. 3.1.14 followed on 15 August, four days after the window closes, which is the point rather than an exception to it. Sign a document naming one of them and it is stale before the ink dries. Every release from 3.1.4 onward is filed in CHANGELOG.md under “Patch Changes”. That patch classification is the project’s own, applied to its own changes.

Once, it slipped. Release 3.1.3 added get_products.filters.publisher_domain, a stable schema field, inside a patch. Five days later 3.1.4 shipped as “the corrective successor to withdrawn 3.1.3”, removing “the patch-ineligible get_products.filters.publisher_domain field”, and the changelog notes that “Exact 3.1.3 artifacts remain available as an immutable withdrawn release record”. Somebody caught it, which is the system working. It also means the stable surface was loose enough for a patch to widen it 25 days after 3.1.0 shipped, and nothing has changed that. Release-by-release detail sits on the maturity assessment.

The rule that fired is worth reading, because it makes the contrast with AAMP a policy contrast rather than a maturity one: “The latest published tag must always reflect the same required-field set as source HEAD. A PR that changes any required array, changes a discriminator const, or tightens a validation constraint must be accompanied by a new tag cut before the change becomes the active implementation target for external consumers.”

Which patch is live has one address rather than one answer, and dist/schemas/latest.json is the address:

{
  "latest": "3.1.13",
  "latest_stable": "3.1.13",
  "channel": "stable",
  "path": "/schemas/3.1.13/",
  "index": "/schemas/3.1.13/index.json"
}

That file is five lines and none of them is ambiguous. It is also a moving target by design: read the same file at a commit from 6 August and it says 3.1.10; fetch it at https://adcontextprotocol.org/schemas/latest.json and it says whatever shipped this week, which on 16 August 2026 was 3.1.14. The URL is the durable artifact. The number inside it never was.

Four other surfaces in that same repository answer the same question differently: docs/reference/versions.mdx says 3.1.12, package.json and static/schemas/source/index.json both say 3.1.1, and docs/building/concepts/industry-landscape.mdx prints “Current version | 3.0 (GA, April 2026)”. static/schemas/source/index.json carries 1.0.0 as its own version and 3.1.1 in a separate adcp_version field. The spread does not break a client, and AdCP’s own rules say why. Negotiation runs at release precision, and versioning.mdx puts the build string outside the contract entirely, calling adcp.build_version “optional advisory metadata for incident triage — not part of the wire contract”. The two branch artifacts are the ones that catch people out, because they are also the first files a reader opens. What the two stacks do not standardise keeps the full inventory of surfaces inside the repository that disagree with each other.

Every circulating AdCP number has an address

None of that reaches the trade press. Four AdCP numbers circulate in published sources, and two of them have an address on AdCP’s own documentation host.

docs/building/concepts/industry-landscape.mdx prints “Current version | 3.0 (GA, April 2026)” and is served publicly, where a search engine is most likely to hand it to a buyer. It still said so when I fetched it on 16 August 2026. pkras filed issue 5032 on 26 May 2026 asking for the equivalent banner to be replaced with 3.1; the issue is closed and the surface did not move.

The 3.1.2 in circulation has a cleaner explanation than a writer’s error. Request docs.adcontextprotocol.org/docs/reference/versions and it redirects to /dist/docs/3.1.2/reference/versions: the published documentation site is a build of the 3.1.2 docs. Take a version off that site and you get 3.1.2 from the path and 3.1.0 from the table, neither of them what the schema registry is serving. Measured 16 August 2026.

The other two, “3.0 RC” and a bare 3.1, circulate through protocol directories: advertisingprotocols.com has been quoted for the first, adgentek.ai runs a full “AdCP 3.1 vs IAB AAMP 2.3” comparison for the second. Neither string is on either landing page as served on 16 August 2026, so treat both as sources a reader cannot check.

“AAMP 2.3” is a genuine IAB Tech Lab release announcement dated 30 July 2026, so nobody invented it. What it lacks is a public artifact: none of the eight repositories described above carries a 2.3 at the AAMP level on 16 August 2026, and the closest string in any tag list is buyer-agent v2.3.0. If 2.3 exists as a member deliverable off GitHub, nothing in those repositories points at it, which is the same problem for anyone drafting against it. A release number tracks a programme of work while the tags track engineering, nobody has declared either authoritative, and so every trade article has a defensible source for a different number.

When a version gets quoted at you, ask which file it came out of. A clause in a signed agreement naming “AdCP 3.0 GA” pins a line the schema registry moved off months ago, and nobody finds out until the first deprecation.

On the AAMP side, a tag is not a pin

An external implementer, jaanijuk, filed issue 2 against iab-agentic-primitives on 31 July 2026: “Release integrity: tagged builds report stale version metadata (0.1.0); recent tags are lightweight”. Every line of it reproduces at the pinned clone. pyproject.toml reads version = "0.1.0" at all five tags while main reads 0.5.0, and src/iab_agentic_primitives/__init__.py hardcodes __version__ = "0.1.0" on main too. His summary is the line to quote at a vendor: “Two version strings maintained separately, only one of them bumped.”

The second half of that issue decides what your clause says. Tags v0.1.0 through v0.3.0 are annotated objects; v0.4.0 and v0.5.0 are lightweight, pointing straight at a commit with no tagger, no date and no signature, and lightweight tags are the kind that can be re-pointed without leaving a trace. Both reference agents pin exactly iab-agentic-primitives.git@v0.5.0 from a git URL in pyproject.toml. The pin every AAMP implementation rests on is a mutable label on a library that tells its installer it is version 0.1.0.

He adds, in the same issue, that he reported tag drift against seller-agent in July, a pinned tag resolving to three different commits inside five days, and that the team moved to immutable point releases in response. Nothing corroborates it in the issues and releases of those eight repositories as read on 16 August, and a re-pointed lightweight tag leaves nothing behind to find either way, so take it as reported rather than measured. The instruction does not depend on the report: a lightweight tag is re-pointable whether or not anyone has re-pointed one, so on the AAMP side the clause names a 40-character commit sha rather than a tag.

Which sha needs care. The commit cited throughout this page, 2fc7029fb9eca801bc94586aec398906aa6af6c0, is one commit past the tag — git describe returns v0.5.0-1-g2fc7029 — while both reference agents pin @v0.5.0 itself. Name 2fc7029 and your counterparty is on a wire contract neither reference agent installs; name the commit v0.5.0 dereferences to and you match them exactly. Either way the pin is on a library whose own README says it is not yet released and whose package still reports 0.1.0, so what it buys is a byte-identical counterparty and nothing else: no support window, no compatibility promise, and a re-cut every time the library moves. It moved after the clone this page reads: v0.5.1 on 10 August 2026, a sixth tag and the repository’s only published release, which neither reference agent has taken.

Four of the eight repositories under the label have never been tagged: the hub, agentic-direct, agentic-audiences and registry-agent-example. The four that have agree on nothing: the spread runs from v0.5.0 to v2.4.1, and no two sit on the same version line. The hub README concedes it in one line: “Each repository uses independent semantic versioning.” Waiting does not help, because there is no artifact to defer to.

The wire contract library does ship one thing worth stating precisely. A conformance runner replays 46 golden vectors under spec/fixtures/ through seven check families and emits the STANDARDS_GAP_REPORT.md both agent repositories consume in CI: 12 standards tracked, 4 self-conformant, 0 partial, 8 unverified. That is a harness testing the library against its own checked-in artifacts, not a suite a counterparty’s endpoint can be failed against.

Its headline gap is the one a publisher would care about most. Field-level fidelity against IAB OpenDirect 2.1 is “the most consequential unverified claim”, and the remediation step is to obtain the published OpenDirect 2.1 field specification. IAB Tech Lab’s contract library cannot yet verify that it wraps IAB’s own standard correctly.

Nine artifacts, and what a contract can name in each

Artifact	Newest tag observed	Version it declares about itself	What a contract can name
AdCP	v3.1.11, cut 7 August 2026	latest.json says 3.1.13 stable	the wire value "3.1" plus the published support window. 64 operations, 761 JSON Schema files
ARTF	v1.0, lightweight, over a commit dated 14 July 2026	“Version 1.0, Released November 12, 2025”	a specification, CC BY 3.0; the Go implementation is AGPL-3.0
seller-agent	v2.4.1	OpenAPI info.version 1.0.0	a commit sha. OpenAPI 3.1.0, 74 paths, 91 schemas
buyer-agent	v2.3.0	OpenAPI info.version 1.0.0	a commit sha. OpenAPI 3.1.0, 13 paths, 8 schemas
iab-agentic-primitives	v0.5.0, lightweight	0.1.0 from both surfaces	a commit sha only. 48 JSON Schemas; README says not yet released
agentic-audiences	none	“Draft v0.1”, inside a specs/v1.0/ directory	a commit sha. One JSON Schema, four zero-byte files under specs/
agentic-direct	none	none	a commit sha. MCP and A2A wrapper over OpenDirect 2.1
registry-agent-example	none	none	a commit sha. A single 22-line agent.ts
AAMP (the hub)	none	none	nothing. It is a README listing six of the others

Eight of those nine rows are AAMP: two runnable reference agents, which you stand up as services rather than import as SDKs, the shared library that says it is not yet released, a wrapper, two specifications, a 22-line example and a README. Tags are as observed at the commits cited here, and read again through the GitHub releases API on 16 August 2026 three of those rows had already moved: AdCP published 3.1.14 on 15 August, iab-agentic-primitives published v0.5.1 on 10 August and buyer-agent published v2.4.1 the same day.

Column three is where an integrator loses an afternoon. Both AAMP repositories that ship an OpenAPI document, seller-agent and buyer-agent, stamp info.version 1.0.0 in it while tagging v2.4.1 and v2.3.0 above it. The third API surface, agentic-direct’s OpenDirect wrapper, has no tag at all for its document to contradict. Generate a client from the OpenAPI file, pin the git tag, and you carry two different version numbers for the same component, both read correctly. The per-repository matrix is at AAMP Explorer.

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

It is also the one that goes to your general counsel before it goes to an engineer. One README carries both halves eight lines apart: “The Go reference implementation in this repository is Copyright (c) 2025 Index Exchange Inc. and is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0)”, then “The IAB Tech Lab ARTF Specification is licensed under a Creative Commons Attribution 3.0 License.” Vendor that Go code into a hosted exchange and section 13 puts every counterparty hitting your endpoint in scope for the source. If your exchange is proprietary the choice is binary: reimplement from the CC BY 3.0 specification, or open the service. Finding that out after the integration is written is the expensive version.

The reimplementation half is narrower than it sounds. The CC BY specification types Mutation.intent as a bare string and its worked payloads carry four camelCase literals: activateSegments, activateDeals, adjustDeals, expireDeals. The AGPL-licensed proto in the same repository types that field as a closed enum of eight SCREAMING_SNAKE values, of which two correspond by name to anything in the CC BY document. The vocabulary an implementer has to emit lives in the half you cannot copy. AdCP vs AAMP carries the procurement exposure.

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

The tell that would resolve this into one stack

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

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

Neither stack invented its transport

The two stacks already share plumbing, which is the thing most often mistaken for a merger. AdCP’s glossary defines the protocol as “domain-specific tasks and schemas that work over MCP and A2A as transports”, with Trusted Match outside both on a direct HTTP/2 API per docs/trusted-match/router-architecture.mdx. AAMP runs over MCP, A2A JSON-RPC 2.0 and REST, with gRPC for ARTF, and its three planes have three separate lineages: a control plane assembled from OpenDirect 2.1’s Account, Order, Line, Product, Creative, Assignment and ChangeRequest, a serve-time plane from OpenRTB 2.6 and AdCOM with sellers.json behind it, and a data plane inherited whole from LiveRamp.

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

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