AdCP 3.1 vs. IAB Tech Lab AAMP 2.3: A Complete Comparison

AdCP 3.1 and IAB Tech Lab's AAMP 2.3 are frameworks with different design philosophies competing across much of the same ground. This post originally argued that they sit at different layers of the stack and therefore do not compete. IAB Tech Lab rejected that framing directly in August 2026, and the correction holds up. What follows is the revised comparison, including the parts we got wrong.

IAB Tech Lab released AAMP 2.3 on July 30, 2026. It is a hardening release: enterprise deployment, privacy diligence, pricing integrity, and the finalization of the audience layer. AdCP 3.1 is a minor, fully additive release over 3.0, published at 3.1.2, that closes the operational gaps that surfaced once agents started running real buys against real publishers. Both landed inside the same quarter, and the overlap between them is larger than either body's naming suggests.

A disclosure before the analysis. Adgentek LLC is a Founding Member of the Ad Context Protocol through AgenticAdvertising.org, and is also a member of the IAB and IAB Tech Lab. Our position is that agentic advertising needs working standards regardless of which body stewards them, and that the interesting engineering question is interoperability, not allegiance. This comparison is written on that basis.

What shipped in IAB Tech Lab AAMP 2.3

AAMP 2.3 hardened the transaction types AAMP 2.0 defined rather than adding new ones, concentrating on the three objections that stood between a working demo and a compliance sign-off: how an agent deploys inside enterprise infrastructure, how it proves a negotiated price is real, and how audience targeting becomes verifiable on both sides of a trade.

The deployment work is the largest piece. The Buyer and Seller Agents now carry a full Amazon Bedrock AgentCore Runtime deployment surface supporting both REST and MCP operating modes, S3-backed inventory adapters, CloudFormation provisioning templates, and close to 5,000 passing unit tests. Databricks support landed alongside it. Streamable HTTP was restored as the primary MCP transport with legacy Server-Sent Events retained and negotiated automatically, removing a manual configuration step that previously required advance coordination between counterparties. Bespoke credential paths on the Seller Agent's Streaming Hub and Buyer Cloud connections were replaced with OAuth, and pluggable storage backends including SQLite, Redis, and a combined Postgres and Redis configuration now allow agents to scale horizontally instead of staying pinned to a single node. Model support widened to OpenAI, Google Gemini, and other OpenAI-compatible services including NVIDIA NIM, Ollama, and Hugging Face, with execution-layer integrations added for Google Ad Manager Reporting and Meta Ads.

The pricing work addresses what IAB Tech Lab calls CPM hallucination: earlier agent versions could generate a plausible-looking cost per thousand when real pricing data was missing from a negotiation, and a fabricated number is indistinguishable on the wire from a grounded one. AAMP 2.3 adds a field recording pricing provenance throughout a negotiation, so an organization can trace where each price originated at every step of a deal and set guardrails that prevent an agent from inventing a floor.

The governance work adds a vendor approval gate on the Buyer Agent, wired to the IAB Diligence Platform and SafeGuard Privacy. When enabled, unapproved vendors are filtered out before the agent processes them, and the same verification runs again immediately before a transaction finalizes. The check is off by default and stays invisible when no verification key is present, which keeps the enforcement layer available to regulated advertisers without imposing overhead on organizations that do not need it.

The audience work brought Agentic Audiences to v1.0 and transaction readiness. The Agentic Audience Extension now allows audience vector embeddings to travel inside the OpenRTB bidstream, with a supporting Prebid module making the field operational on the seller side. Mixpeek contributed a Content Taxonomy Parser supporting semantic IAB Content Taxonomy v3 classification, contextual inventory discovery, and brand safety scoring, building on the taxonomy mapping tool the company donated in February 2026.

IAB Tech Lab has confirmed AAMP 3.0 is underway with no announced date, and has been explicit that 2.3 is a maturity release on existing foundations.

The six AAMP repositories, explained

AAMP is an umbrella initiative rather than a single specification, and it resolves into six independently versioned repositories under IAB Tech Lab governance. Cross-repository alignment happens through governance coordination, with the AAMP Hub referencing stable releases. Understanding the six is the only way to make a fair comparison, because they do not all operate at the same altitude.

1. Agentic Direct (core orchestration)

Agentic Direct provides the core communication framework and orchestration layer for agent interaction. It is the connective tissue that lets the other components talk, and it carries the agentic integration of the OpenDirect specification and the Deals API built on principles established in ARTF. In architectural terms this is the layer that decides how a message gets from one agent to another and in what shape, not what the message is about.

2. Buyer Agent

The Buyer Agent is the reference implementation of demand-side agent logic and decision workflows. The SDK spans media planning, deal creation, discovery, negotiation, and campaign automation through a multi-agent framework and a centralized Deals Library, and it integrates with the Agent Registry for automatic seller agent discovery. This is where most of AAMP 2.3's governance work landed: the vendor approval gate, the pricing provenance field, the expanded LLM provider pool, and the Google Ad Manager Reporting and Meta Ads execution integrations all attach here.

3. Seller Agent

The Seller Agent is the reference implementation of supply-side coordination and marketplace interaction. It adopts OpenDirect and AdCOM to manage inventory, media kits, pricing, and negotiations through a configurable engine and a state machine, with connections across ad servers and supply-side platforms. AAMP 2.3 gave it OAuth in place of custom credential handling and the pluggable storage backends that permit horizontal scaling.

4. Registry Agent

The Registry Agent repository demonstrates agent discovery, registration, and coordination patterns, and is the reference companion to IAB Tech Lab's Agent Registry, which reached ten active entries in March 2026. The registry exists because in an environment where buyer agents negotiate autonomously with seller agents, verifying a counterparty's legitimacy without an independent record is structurally hard. AAMP 2.3's vendor approval gate extends that same logic from registry-level discovery down into the transaction itself.

5. Agentic Real Time Framework (ARTF)

ARTF is described as a foundation for implementing agent services that operate within a host platform and that the orchestrating platform can call directly to accomplish a shared goal. IAB Tech Lab has characterized it as the execution pillar of AAMP. That charter language matters for any comparison: ARTF is scoped to agent services running inside a platform boundary, which is the same altitude at which OpenRTB, VAST, ads.txt, and Open Measurement have always operated.

6. Agentic Audiences

Agentic Audiences began as LiveRamp's User Context Protocol, donated to IAB Tech Lab in November 2025, and is now the schema that standardizes audience signals for agent use. AAMP 2.3 brought it to v1.0 and made it transaction-ready for both programmatic and agentic paths, with audience vector embeddings carried inside the OpenRTB bidstream and a Prebid module implementing the seller side.

Layered above the repositories, the AAMP architecture places both the Buyer and Seller Agent SDKs into a three-level hierarchy: Level 1 orchestration through a portfolio manager, Level 2 channel specialists, and Level 3 functional agents, all governed by taxonomy guardrails. The framework's three declared pillars are Agentic Foundations, Agentic Protocols, and Trust and Transparency.

What AdCP 3.1 covers

AdCP is organized as an identity layer, four transaction domains, a cross-cutting governance layer, and a real-time execution protocol, all of which operate on campaign-lifecycle objects rather than impressions. The protocol is transport-agnostic in practice, running over MCP tool calling or A2A, and it works with or without an OpenRTB integration underneath.

Identity: Brand, Registry, and Accounts

Three domains establish who the parties are before any transaction occurs. The Brand Protocol defines buy-side identity through brand.json hosted at a well-known path, declaring corporate hierarchy, sub-brands, properties, and authorized operators. The Registry provides a public REST API for entity resolution and agent discovery, resolving a brand domain or returning which agents are authorized to sell a publisher's inventory. Accounts establishes the commercial relationship: billing terms, operator authorization, and usage reporting, through list_accounts, sync_accounts, get_account_financials, report_usage, and sync_governance.

AdCP 3.1 made brand.json distributed. A sub-brand can now publish its own canonical document on its own domain while the corporate house declares ownership through a portfolio pointer, resolving trust by mutual assertion. That is the same reciprocal-publication pattern IAB established with ads.txt and sellers.json, applied to brand identity. Two new tasks, verify_brand_claim and verify_brand_claims, let any partner ask a brand agent authoritatively whether a trademark, creative claim, or asset right belongs to it.

Media Buy

Media Buy covers discovery through get_products, campaign creation through create_media_buy, modification through update_media_buy, and reporting through get_media_buy_delivery. Discovery is brief-driven: a buyer writes a natural language campaign brief, and publishers return structured media products with pricing options, targeting, and delivery forecasts. A refine mode lets agents iterate on proposals, with finalize-exclusivity rules and atomicity guarantees on the finalize action.

AdCP 3.1 added several surfaces here that matter operationally. Dependency-impact reporting flips a buy's health to impaired and populates impairments[] when a creative gets pulled, an audience is suspended, a catalog item is withdrawn, or an event source goes quiet, with a parallel webhook fire and a compliance invariant grading the contract end to end. Action discovery through allowed_actions[] on products and available_actions[] on buys lets a buyer pre-flight which mutations are legal instead of failing mid-flight. Delivery reporting gained reach_window semantics, average in-view viewed_seconds, and windowed pull recovery so a buyer who missed a webhook can reconstruct identical data by polling. Billing gained row-level is_final and finalized_at markers, which is the difference between a number a finance team can reconcile against and a number that might still move.

Creative

The Creative Protocol handles format discovery through list_creative_formats, generation through build_creative, library synchronization through sync_creatives, catalog feeds through sync_catalogs, and preview rendering through preview_creative. Creative agents resolve brand identity from the Brand Protocol so generated assets stay on-brand without a separate handoff. Format coverage spans display, video, audio, CTV, DOOH, broadcast, carousel, and social-native, with typed catalog schemas for vertical feeds like hotel, flight, vehicle, and real estate.

AdCP 3.1 introduced a canonical format vocabulary: twelve format_kind values covering image, HTML5, display tag, hosted and VAST video, hosted and DAAST audio, image carousel, responsive creative, sponsored placement, agent placement, and custom, three of which are marked experimental. Publisher-authoritative catalogs are readable through adagents.json, and a projection reference mechanism lets sellers dual-emit against v1 named formats during migration. AI provenance metadata declaring tool involvement and regulatory disclosure obligations travels on the manifest and gets independently verified at each enforcement point.

Signals

Signals is AdCP's audience and targeting-data domain, and it is where the comparison with Agentic Audiences gets sharpest, because Signals is a discovery and licensing protocol rather than a transport schema. Signals cover audience segments, contextual categories, geographic regions, temporal patterns, and multi-dimensional combinations.

Every signal carries a value_type that determines how a buyer constructs targeting. Binary signals resolve to match or no match, which is the common case. Categorical signals carry an allowed_values set, so a vehicle-ownership signal can distinguish luxury EV from luxury non-EV from economy. Numeric signals carry a range with a unit, so a purchase-propensity score can be targeted above a threshold. That typing is load-bearing: a buyer agent constructing an expression against an untyped segment has to guess at semantics, and guessing is how budget gets spent against the wrong population.

Identity resolves through signal_ref.scope, which takes one of three values. A data_provider scope pairs a provider domain with a signal ID and is independently verifiable against that domain's adagents.json signals list. A signal_source scope pairs a source URL with a signal ID and is trust-based. A product scope is local to the selected product or package. Data providers control resale through the authorized_agents array in adagents.json, authorizing either specific signal IDs for fine-grained control or whole tags for catalogs that grow.

Two tasks carry the domain. get_signals takes a natural language specification and returns matching signals with pricing, size estimates, and value-type metadata, which is everything an agent needs to make a targeting decision without a human in the loop. activate_signal pushes segment membership to a named destination platform and seat, after which usage reporting, billing, and campaign metrics are handled by that platform directly. AdCP 3.1 added discovery_mode: "wholesale", symmetric with the equivalent buying mode on get_products, so a storefront or marketplace can enumerate a signals agent's full priced catalog with pagination instead of probing it with synthetic queries.

Sponsored Intelligence

Sponsored Intelligence defines conversational brand experiences inside AI assistants, which is the domain with no counterpart on the impression-layer side because the surface has no impression event in the traditional sense. Four tasks carry the session lifecycle: si_get_offering for anonymous pre-session lookups, si_initiate_session to start a consented session with user intent and host capabilities, si_send_message to relay turns, and si_terminate_session with five termination reasons including transaction handoff. The product spectrum spans sponsored responses, AI search results, generative display, and full brand experiences under the SI Chat Protocol. This is the layer that conversational advertising actually runs on, and it is why the protocol matters to anyone trying to advertise in AI chatbots.

Governance

Governance operates across every transaction domain rather than sitting beside them. Campaign governance runs a three-party trust model in which orchestrator, governance agent, and seller each validate, so no single agent makes a unilateral buying decision. The flow is sync_plans to push plans with budget limits and compliance policies, check_governance as a mandatory gate before any spend-committing action, report_plan_outcome to update budget tracking and compliance records, and get_plan_audit_logs for the full decision trail with internal and scoped shareable views.

Around that sit content standards for privacy-preserving brand suitability evaluation, including a calibrate_content dialogue that aligns buyer and seller on standards before execution; property governance through adagents.json and inclusion or exclusion property lists; collection governance for program-level brand safety across shows and series; creative governance for security scanning, provenance verification, and accessibility; and a shared Policy Registry of machine-readable compliance policies referenced by ID and version. The Embedded Human Judgment framework defines how humans stay accountable when agents allocate capital, with any mutation able to go async for human review.

Trusted Match Protocol

TMP is AdCP's real-time execution layer and the point where the protocol reaches impression-time decisioning without becoming an auction protocol. It defines two structurally separated operations. Context Match sends page content and available packages with no user identity. Identity Match sends an opaque user token and package IDs with no page context. The publisher joins the two responses locally, and packages that matched context and passed eligibility activate while everything else is suppressed. The buyer never sees both halves at once.

That separation is the mechanism behind cross-publisher frequency capping, which is enforced through the Identity Match path where the buyer maintains a shared exposure store across publishers. It is also the only AdCP domain where privacy is enforced structurally rather than contractually: the schemas prohibit crossover, and the separation is independently verifiable. AdCP 3.1 added serve_window_sec to responses so the router caches an eligibility decision for a bounded period, made seller_agent_url required on requests, and made package_ids optional so a router can ask whether a user is eligible at all without enumerating packages. TMP replaces the earlier Agentic eXecution Engine, which is now deprecated.

Where the layer framing breaks down

On August 19, 2026, IAB Tech Lab COO Shailley Singh published a point-by-point response to the comparisons circulating between the two frameworks, this post among them in its original form. Seven claims were assessed and five were marked incorrect or overstated. The correction is worth taking seriously rather than defending against, so what follows is a revised position rather than a rebuttal.

The central assertion is that AAMP is not an impression-layer protocol. The Agentic Protocols pillar is a management layer by IAB Tech Lab's own description, covering buyer and seller discovery, audience and product discovery, campaign requirements, pricing negotiation, order and deal management, signal exchange, and pre-execution setup. The Buyer Agent accepts a campaign brief, allocates budget across channels, researches multiple sellers, negotiates, obtains human approval, books deals, and produces an audit trail, with linear television scatter buying, DMA targeting, cost-per-point pricing, dayparts, and order state machines in the current release. That is campaign lifecycle functionality by any reasonable reading.

Three specific corrections apply to what this post originally argued. The claim that one AdCP media buy decomposes into thousands of AAMP impression events was an inference rather than a standardized relationship, and no normative interoperability contract between the two frameworks establishes it. The pairing of ARTF with Trusted Match was weak, because ARTF is a low-latency host-executed agent service framework supporting many use cases while Trusted Match is one targeting plane. And the assertion that AAMP primitives assume auction dynamics is an overgeneralization, since the Buyer and Seller Agents support direct transactions, programmatic guaranteed, private marketplaces, and bookings that never touch an auction.

Thirteen business functions were identified as addressed by both frameworks: buyer and seller agents, natural language briefs, inventory and product discovery, seller discovery, media planning, pricing and negotiation, deal or order creation, human approval before spend, audience discovery and activation, agent identity and registry, MCP and A2A communication, campaign lifecycle and reporting, and real-time or serve-time decisioning. Object names and abstractions differ. The business functions do not.

Shared MCP support is also rejected as evidence of complementarity, on the grounds that MCP is a communication substrate and does not reconcile the two frameworks' advertising semantics. That is correct, and it is the part most comparisons get wrong, this one included.

What still separates them

Two things survive the correction.

ARTF has no AdCP counterpart. It defines agent services packaged as containers and deployed inside a host platform, so bidstream processing can be delegated at auction latency without a network callout. AdCP has nothing that runs inside a platform boundary at that grain, because it was not built to. That is a gap in one direction and the correction does not close it. It is an asymmetry rather than a complementarity, which is a weaker claim than the one this post used to make.

The design philosophies diverge on ancestry. AAMP reuses OpenRTB, OpenDirect, AdCOM, and the IAB taxonomies, and its stated priority is continuity with infrastructure the ecosystem already runs. AdCP defines agent-native tasks first and treats existing systems as integration targets, with asynchronous task states so human approval is structural rather than bolted on. Both approaches are defensible. They produce different objects for the same business function, which is precisely why the overlap is expensive.

Overlap is the cost, not the comfort

The layer story was popular because it let everyone avoid a decision. If AdCP owned planning and AAMP owned execution, a publisher implemented both and treated the standards question as somebody else's problem.

Thirteen overlapping functions removes that option. A publisher exposing inventory to both frameworks maintains two descriptions of the same supply, with two pricing surfaces, two negotiation state machines, and two audit trails that have to reconcile. A buyer building against both writes the discovery and negotiation path twice against different object models. Neither framework has anything close to universal coverage, which means the duplication is not temporary and there is no obvious date at which it resolves.

That is the real question for operators in 2026, and it is a harder one than the framing this post originally offered.

This is also why Adgentek's public position is transport-agnostic. Agents use whatever rail the transaction requires: agent-to-agent, RTB, MCP, AdCP, or direct. The AI surfaces we monetize happen to have no impression auction at all, which is why the campaign layer carries more weight in our stack, but that is a property of the channel rather than a claim about which framework wins.

AdCP 3.1 vs. AAMP 2.3: the matrix

The third column describes what a platform running both frameworks actually faces. It is a work estimate rather than a division of labour: where the two frameworks address the same function, running both means maintaining two representations of it.

Mapping AAMP's six components to AdCP surfaces

Five of the six AAMP repositories have a recognizable AdCP counterpart. ARTF does not, and the mapping below says so rather than forcing one. This is the practical guide for anyone deciding what to build once and what to build twice.

Where the frameworks diverge most

The overlap is widest in planning and negotiation. It narrows sharply in channels where the impression is not the unit of trade, which turns out to be most of the media landscape by dollar volume, and this is where the two frameworks' different ancestries produce genuinely different coverage.

Broadcast television and radio. There is no impression-level auction. Spots are scheduled and cleared under insertion orders with cell-grain reporting, currency is demographic delivery from Nielsen, comScore, or Numeris, and preemption and make-goods are workflow rather than exceptions. AdCP's Media Buy domain models this natively, with broadcast radio spots identified by traffic and clearance IDs, ISCI on the creative, no VAST and no tracker, and an agency estimate number tying the order to the media plan. Active proposals cover network and station targeting, by-demo delivery, spot-level as-run logs, and preemption workflows.

CTV. The impression is rarely the unit that matters in CTV, which is the source of most of its problems. The real unit is the pod and the show. VMAP defines break structure at stream and show level, and pod constraints including duration, slot count, and competitive separation are what actually govern what can fill. OpenRTB 2.6 addressed this directly in April 2022, adding poddur, podid, podseq, slotinpod, maxseq, and mincpmpersec so a bid request can describe the pod it lands in. The gap since has been adoption rather than specification. Index Exchange, which helped author the pod work, wrote in July 2025 that most DSPs still receive streaming supply as separate impression requests even when those requests originate in a single pod, and buy-side rollout only began in earnest in 2026. Frequency duplication persists because the fields exist and the bidders have not been reading them. AdCP's grain is the deal: collections carry IMDb, Gracenote, and EIDR identifiers so a show matches across sellers, break-based inventory configuration models the pod, exclusivity and cancellation policy are negotiated fields, measurement terms set the billing vendor and IVT threshold, and measurement windows plus finality flags handle the C3 and C7 close. A household cap across three sellers is campaign-layer state by construction.

Audio. Audio is three transaction models, and AdCP v3 split them accordingly into radio, streaming audio, and podcast. Broadcast radio clears as spot schedules. Podcast is a collection of installments with lifecycle states, where host-read sponsorship has no impression event at all and delivery matures for weeks. Streaming audio is the only one the impression layer covers end to end.

DOOH. A play is a slot in a screen loop with no user, no cookie, and no device request. Audience is modeled by a measurement vendor and multiplied onto plays, and pricing is frequently flat rate per screen per period rather than CPM. AdCP models the actual unit of trade, with flat-rate parameters typed for DOOH, geo proximity expressed as travel-time isochrones, radius, or GeoJSON, daypart targets, and creative approval as a venue lifecycle rather than a callback.

Closed and intelligent platforms. Large closed inventory sources actively avoid RTB, because programmatic would commoditize the differentiation they are protecting. AdCP is built for that case: sellers keep pricing, packaging, and closed-loop measurement intact while exposing a standardized interface. An impression-layer framework has a harder path here because its primitives assume auction dynamics these platforms do not run.

What running both actually involves

Running both is still what most platforms will do. It is a cost rather than an elegant division of labour, and the sequence below is what a dual implementation actually involves. Read it as a work estimate rather than as evidence that the two frameworks were designed to fit together.

1. Identity resolution. Resolve the brand through brand.json and the seller through adagents.json. Cross-check the counterparty against the Agent Registry and, where required, the IAB Diligence Platform gate.
2. Discovery and planning. Dispatch a natural language brief through get_products to every certified seller in parallel, refine the returned proposals, and pull signal candidates through get_signals with pricing and typed value semantics attached.
3. Governance. Push the plan with sync_plans, run check_governance before any spend commit, and carry the returned governance context into execution so the seller can re-validate independently.
4. Execution. Commit through create_media_buy. The seller fulfills using whatever internal mechanism fits, which may be an AAMP-compliant bidder against OpenRTB, an OpenDirect insertion order, a private marketplace deal, or TMP-mediated activation where cross-publisher state is needed.
5. Activation at impression time. Segments licensed through activate_signal travel into the bidstream through the Agentic Audience Extension with the Prebid module handling the seller side. ARTF and TMP are not counterparts. ARTF is a container deployment model for logic running inside a host platform, and TMP is a targeting plane spanning publishers. If you need both behaviours, you build both.
6. Close. Pull delivery through get_media_buy_delivery, watch is_final and finalized_at for reconciliation, and feed outcomes back through provide_performance_feedback and report_plan_outcome.

This is roughly how Adgentek's stack is organized. The Agentic Ad Server is the sell-side decisioning engine for AI surfaces, with AdsMCP as one integration path alongside an SDK and a REST API. Spark is the conversational format that renders inside the surface, which maps to AdCP's Sponsored Intelligence domain because there is no impression auction to bid into. On the buy side, ORCA is our AdCP 3.1-compliant agentic media buying platform for agencies, sitting above the transaction layer and dispatching agents to certified sell-side infrastructure rather than acting as a demand-side platform.

What to do about it now

The practical near-term move for most platforms is to stop treating this as a selection problem and start version-pinning both. AdCP 3.1 is additive over 3.0, so a conformant 3.0 agent keeps working while you adopt the new surfaces incrementally, and release-precision version negotiation means you can pin a release and stop fighting drift. AAMP 2.3 is likewise a hardening release, so the upgrade path from 2.0 is about deployment posture and governance configuration rather than a new transaction vocabulary.

The open question neither release resolves is adoption breadth. Neither framework has a named counterparty publicly transacting production media buys against it, and IAB Tech Lab's own leadership has said that meaningful scale arrives in 2027 or 2028 with false starts along the way. A protocol with strong governance and weak participation solves a narrower problem than one with wide buy-in. That argues for building against both interfaces rather than betting on one, while being clear-eyed that doing so is duplicated work rather than a free hedge.

If you are a publisher or an AI platform evaluating how to expose inventory to agent buyers, or a buy-side team working out which interface to build against, we are happy to walk through the specifics of your stack.

Ready to get started?

Contact Us

hello@adgentek.ai