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 not substitutes. They are built at different layers of the advertising stack, with different design centers, and the practical question facing most platforms in 2026 is not which one to adopt but how to run both without duplicating work.

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 smaller than the 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.

The core difference is the layer, not the feature list

AAMP extends the impression layer into agentic form, and AdCP defines the campaign layer natively. Almost every apparent overlap between the two dissolves once you hold that distinction steady.

The naming is a tell. AAMP sits under the body that produced OpenRTB, VAST, AdCOM, OpenDirect, ads.txt, and Open Measurement, and ARTF's charter language scopes it to agent services operating within a host platform. AAMP 2.3's audience work carries embeddings inside the OpenRTB bidstream with a Prebid module on the seller side. Those are impression-layer primitives, extended thoughtfully into a world where agents rather than bidders make the calls.

AdCP's grain is the campaign: brief interpretation, product discovery, negotiation, governance, creative management, reporting, and reconciliation, conducted as a bidirectional conversation across a lifecycle measured in days rather than a callback measured in milliseconds. A single create_media_buy can produce thousands of impression-layer events that an AAMP-compliant bidder handles perfectly well. They are not substitutes at the primitive level, and treating them as competing options produces the wrong architecture.

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 and not an argument that one layer wins.

AdCP 3.1 vs. AAMP 2.3 vs. hybrid: the matrix

The third column is the one that matters for most operators. It describes what a platform running both frameworks actually does, rather than which framework it would pick if forced to choose.

Mapping AAMP's six components to AdCP surfaces

Five of the six AAMP repositories have a recognizable AdCP counterpart, and the sixth has one only in part. The mapping below is the practical guide for anyone deciding what to build once and what to build twice.

Where the layer distinction shows up hardest

The two frameworks diverge most 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.

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. CTV is not genuinely impression-level, 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. An RTB bid request carries no view of the pod it lands in or the show around it, which is also why frequency duplication remains the perennial CTV complaint. 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 a hybrid AdCP and AAMP stack looks like

A hybrid stack uses AdCP for everything that happens before and after the auction, and AAMP components for everything that happens inside the platform where the auction runs. In sequence, that looks like six steps.

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 handles agent services inside the platform boundary; TMP handles the decisions that require state the platform does not hold.
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. A protocol with strong governance and weak participation solves a narrower problem than one with wide buy-in, and the major buy-side and sell-side platforms have not been uniform in their support for either framework. That is an argument for building against both interfaces rather than betting on one, which is exactly what the third column of the matrix above describes.

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