AdCP 3.2 replaces the multi-purpose buying calls of 3.1 with seven single-purpose tools, removes one deprecated status field, and tightens the profile for any endpoint that signs requests. It became generally available on 30 September 2026, according to the AdCP 3.2 release overview, and existing 3.1 integrations keep working because get_products, create_media_buy and update_media_buy stay available as compatibility facades throughout 3.x.

TL;DR. The Ad Context Protocol (AdCP), published by AgenticAdvertising.org, shipped 3.2 as release artifact 3.2.1 with the wire pin "3.2". The main changes are a compact commercial lifecycle built around list_products, request_proposals, buy_products and accept_proposal, a required media_buy_status field, error.recovery on every error and a stricter signing profile. Request signing stays optional until 4.0, and campaign governance remains experimental, with breaking changes of its own.

What is AdCP 3.2 and when was it released?

AdCP 3.2 is a minor release of the Ad Context Protocol, the open standard published by AgenticAdvertising.org for how AI agents buy media, build creative and activate audiences. The release overview dates general availability to 30 September 2026 and notes that the number 3.2.0 was never released, so the first stable artifact is 3.2.1. The TypeScript SDK @adcp/sdk@14.0.0 and the Python package adcp==8.0.0 ship alongside it, and a 3.3 beta is already published.

The documentation sums up the change in one line: "3.1 made agents safe to operate. 3.2 makes the deal between them explicit." Between 3.1.0 and 3.2.1 the published surface grew from 64 to 78 manifested tools and from 92 to 120 standard error codes, according to the same overview.

For a primer on the protocol itself, see what the AdCP standard is.

Do existing AdCP 3.1 integrations have to migrate?

No. The 3.1 to 3.2 migration guide states that existing 3.1 implementations remain valid and describes adoption as "an incremental enterprise migration, not a flag day". A buyer pinned to "3.2" that meets a seller advertising only 3.0 and 3.1 is served 3.1 and carries on through the compatibility facades.

Buyers should plan for two exceptions. Signed requests fail once a seller advertises 3.2 on the endpoint being called, unless they are signed with the 3.2 profile, and strict parsers can reject 3.2 response shapes that a seller has not projected back to 3.1.

Alkimi offers a worked example: it runs Concourse, a benchmark that tests buying agents without asking which standard they use, so the same buyer agent could meet a 3.1 seller in one run and a 3.2 seller in the next. The agent that copes is the one that reads the version echo and picks its tools from the seller's declared capabilities, rather than assuming either release.

What replaced get_products and create_media_buy in AdCP 3.2?

For new integrations, 3.2 splits the old multi-mode calls into one tool per business step. The release notes list get_products, create_media_buy and update_media_buy under deprecations with the status "compatibility facades" for new integrations, and with no removal inside 3.x. The compact lifecycle that takes over looks like this:

list_products lists published offers and has no side effects.
request_proposals asks the seller to author non-binding plan snapshots from a brief.
refine_proposals either revises terms as a new immutable snapshot or finalises them and holds inventory until expiry.
decline_proposals records the buyer's feedback and stops the proposal from executing.
buy_products buys a published offer directly.
accept_proposal turns a held snapshot into an accepted media buy, an amendment or a negotiated cancellation.
control_media_buy changes delivery inside the accepted terms.

The overview measures the 3.2 MCP schemas as 71% smaller for proposal planning (request_proposals against get_products), 78% smaller for direct purchase and 87% smaller for proposal acceptance (both against create_media_buy), and 94% smaller for operational control, noting that these are schema sizes rather than request sizes or latency. Sellers declare which compact tools they serve in media_buy.lifecycle_tools, and when that field is absent buyers fall back to the facades.

What are the breaking changes in AdCP 3.2?

The versioning page keeps a short list of exceptions to 3.x compatibility, and the overview names two with the widest impact. The deprecated body-level status field on create_media_buy and update_media_buy success responses is removed, so sellers emit media_buy_status and buyers read it. Signing endpoints on 3.2 must also cover content-digest on every body and encode signature values as RFC 8941 sf-binary.

Several smaller changes still need code. Every 3.2 error carries error.recovery, retry_after becomes an integer, and the migration guide lists request shapes 3.2 now rejects, such as sending both packages and a proposal_id to create_media_buy or a lowercase total_budget.currency code.

Is request signing required in AdCP 3.2?

No. The overview states that request signing stays optional in 3.x and becomes required for spend-committing operations in 4.0, which the versioning page targets for early 2027. What 3.2 changes is the profile: an endpoint that does sign must advertise covers_content_digest: "required" and reject the older unpadded encoding.

The migration guide is explicit that the endpoint, not the request's version pin, selects the signing profile. A seller adding "3.2" to a shared URL therefore needs a plan for signed 3.1 callers first, either by serving 3.2 from a separate endpoint or by confirming that every signing counterparty has moved to the 3.2 profile. For how keys and signatures work in the first place, see how AdCP verifies which agent is asking.

What changed for AdCP governance tasks in 3.2?

Campaign governance (governance.campaign) remains experimental in 3.2, and its revision is breaking. According to the migration guide, 3.2 closes the report_plan_outcome.delivery shape and requires target_agent in check_governance tool and payload mode, so 3.1-shaped governance calls fail 3.2 validation. Governance parties are told to migrate together, and sync_governance accepts Bearer credentials only.

The overview asks implementers to inspect experimental_features and pin an exact release before relying on any experimental surface. For what the governance checks do, including when an agent has to escalate to a person, see how AdCP governance handles human approval.

What else is experimental or deprecated in AdCP 3.2?

Reliable Reporting 1.0 is the largest new experimental surface. It lets a buyer see, for every reporting period a seller owes, whether the report is waiting, healthy, delayed or needs action, and the overview states that sync_reporting_status becomes required Core in the next eligible minor release, no earlier than 24 October 2026. Trusted Match, audience activation, product identity, execution requirements, authenticated principals, the account change feed and measurement are also experimental in 3.2.

Several fields are deprecated for removal in 4.0, according to the release notes. They include the response-wide currency and aggregated_totals on get_media_buy_delivery, bid_price in favour of a new bidding block, and exact plural format_ids. The versioning policy says a feature deprecated in 3.x is not removed before 4.0 at the earliest.

How do you migrate from AdCP 3.1 to 3.2? A checklist

The steps below condense the migration guide's upgrade checklist and its day-one lists for each role.

Upgrade to a 3.2 SDK line (@adcp/sdk@14.0.0 or adcp==8.0.0) with the wire pin still at "3.1", then opt into "3.2" one peer at a time.
Generate code from the signed 3.2.1 protocol tarball, not from the main branch.
Sellers: advertise "3.2" in adcp.supported_versions alongside every release still served, echo the release actually served, and keep the 3.0 and 3.1 handlers and facades.
Buyers: send adcp_version: "3.2" only to peers that advertise it, and replace any beta or release-candidate pin with "3.2".
Media-buy implementations: move create and update success handling to media_buy_status.
Signing implementations: require content-digest coverage, move to RFC 8941 encoding, and decide how signed 3.1 callers keep working before a shared URL advertises 3.2.
Errors: emit error.recovery on every error with an integer retry_after, and apply retry_after only to transient errors.
Lifecycle: gate the compact tools on media_buy.lifecycle_tools and fall back to the facades when the declaration is absent.
Reporting: read currency per media buy or package, and stop producing new aggregated_totals.
Governance (experimental): migrate caller binding, target_agent and outcome reconciliation together with counterparties.
Compliance: grade 3.2 claims against the 3.2.1 compliance bundle and keep a record of the exact package and wire versions.

Where do people stay in charge after the upgrade?

The compact lifecycle draws clearer lines between steps, and each line is a natural point for human sign-off. A finalised proposal holds exact terms until it expires, accept_proposal is a separate act, and the overview notes that the contract ends at acceptance and does not standardise invoicing or disputes. Agents can take on the listing, proposal requests and revisions that people do not enjoy, while a person keeps the judgement and approves the acceptance that commits budget.

One way to stage that hand-over is earned autonomy, where an agent moves from observing to recommending, drafting, human-approved action and finally bounded automatic action as its record builds. Alkimi is neutral on standards: it can work with agents built on AAMP, IAB Tech Lab's Agentic Advertising Management Protocols, or on AdCP, with or without a DSP. Concourse benchmarks any buying agent without asking which standard it uses, the Gym lets buyers and sellers train their own agents and spar against counterparty agents before real money moves, and the Marketplace is neutral, with humans keeping approval rights at the deal level.

Frequently asked questions

When was AdCP 3.2 released?

AdCP 3.2 became generally available on 30 September 2026, published as release artifact 3.2.1 with the wire pin "3.2". The number 3.2.0 was never released.

Is get_products deprecated in AdCP 3.2?

For new integrations, the release notes class get_products, create_media_buy and update_media_buy as compatibility facades, with list_products and request_proposals taking over discovery and proposals. They are not removed in 3.x, and sellers keep serving them for 3.1 buyers.

Does AdCP 3.2 require request signing?

No, signing stays optional throughout 3.x and becomes required for spend-committing operations in 4.0. Endpoints that do sign in 3.2 must cover content-digest and use RFC 8941 encoding.

Will a 3.1 buyer agent break when a seller moves to 3.2?

Usually not, because a seller that keeps its 3.1 release goes on serving 3.1 buyers through the facades. The exceptions are signed requests to an endpoint that now advertises 3.2 and strict parsers that reject new response shapes.

Is AdCP campaign governance stable in 3.2?

No, campaign governance is still an experimental surface, and its 3.2 revision changes request and outcome shapes. Implementers should check experimental_features, pin an exact release and migrate with their governance counterparties.