AAMP 3.0 arrived on 22 September with OpenProposal, a new specification that gives buyer and seller agents a shared, machine-readable language for the one stretch of media buying that has always been manual — the journey from a brief to a buy commitment. Two things about it are true at the same time. It is the most carefully engineered standards document this category has produced. And it carries a records model — a real one, with signatures and timestamps — that does not, anywhere in its 29,624 characters, name a person.
The draft is open for public comment until 22 October 2026. That deadline is why this is worth writing now, and why it is worth reading to the end: this is the one window in which the operating layer an agency actually needs could still be asked for by name.
The standards layer did the hard part
Start with what shipped, because it is a lot. IAB Tech Lab’s own release calls OpenProposal a new specification that defines how sellers can represent advertising products and respond to buyer briefs in a standardized, agent-readable format. The problem it addresses is stated plainly: the process between an RFP and a buy commitment has historically been handled largely through human and manual workflows.
That is a fair description of the gap, and the mechanics are serious. The specification contains eleven headers across four categories, is transaction-type agnostic (direct IOs, Programmatic Guaranteed, preferred deals, open auction) and channel agnostic (open web, CTV, mobile, audio, OOH, linear TV, walled gardens). It bolts onto the standards the industry already runs — AdCOM, OpenDirect, the Deals API — rather than asking anyone to rebuild.
The design claim is the part worth quoting, from the repository README: Composition is constraint satisfaction, not negotiation. Of 71 fields, only 3 require a round trip with the counterparty. Every field carries exactly one mutability marker — immutable, seller-set, selectable, settable, supplied, requestable or derived — and, in the spec’s own words, the marker is what tells a buying agent whether it can act unilaterally.
The release is candid about the safety engineering too. The agent SDKs, it says, further harden deterministic guardrails governing pricing, ad packages, orders and media buy details, increase trust in agent identities, and strengthen idempotency across transactions. Idempotency gets its own plain-English gloss, and it is a good one:
“In practical terms, idempotency means an instruction can be sent twice without happening twice; so when an agent retries a request it didn’t get an answer to, the result is confirmation of the original order rather than a duplicate.”
PMG’s head of CTV strategy, Mike Treon, names the genuinely new part better than the spec does: What’s new in AAMP 3.0 is that the reasoning travels with the proposal. A seller can tell us not just what a package costs, but why they believe it fits the brief … That context is what our planning models need, and now it arrives in a form they can actually read. A machine-readable rationale, standardised. Credit where it is due: nobody else in this market ships that.
It has a records model. Look at what the record covers.
Here is the part that matters if you run regulated spend, and it is easy to miss because it is buried in a field table. The draft does not just describe an object; it describes an object with a history. Two fields do the work:
- assent — an object, marked derived: Buyer and seller assent records and timestamps for the binding version. Signature scheme is WS1. A signature-backed record of who agreed, and when.
- negotiation_history[] — an array, marked derived, ordered, append-only, with each entry carrying version, actor: buyer | seller, action: proposed | countered | accepted | declined | withdrawn, fields_changed[], at. A change log that records which fields moved and on which side.
That is more governance machinery than most vendors in this market have ever published, and it is in a draft standard. But read the two fields again and notice the unit of the record. The assent is assent to the binding version of the deal. The actor in the change log is buyer | seller — a party to the transaction, not a named human. The spec is meticulous about who changed a term in a negotiation, and it is silent on who approved an operation on an account.
A character-exact scan of the draft
Absence claims are cheap, so let us be exact. We pulled the normative draft (spec/openproposal-3.0.md, tagged v3.0-draft-1) and scanned the full text — 29,624 characters — lowercased, on the stem:
| Term | Occurrences in the AAMP 3.0 draft | What the hits actually mean |
|---|---|---|
| approver | 0 | No concept of a named human authorising anything. The spec’s four approv hits are a buyer-supplied asset’s approval_status and a creative approval field defined as review SLA and revision policy. |
| human | 0 | Every mutability marker describes what a party may do. The word for the person behind the party never appears. |
| audit | 0 | There is a negotiation history, but no audit concept — no object framed as evidence a third party could read. |
| jurisdiction | 0 | The spec is channel agnostic and transaction-type agnostic. It is not, anywhere, jurisdiction-aware. |
| retention / export | 0 / 0 | Nothing sets a lifetime for any record, and nothing defines an export. The record lives as long as the object does. |
| client | 2 | Both are enum values: an authentication scheme, oauth2_client_credentials, and a serving mode, client_side. Neither is a client account. |
One honest note on method, because a count is only worth something if it is read. The word “decision” appears once — inside an example audience identifier, smb-decision-makers@3. It is a targeting string, not a decision record. We are not counting it as evidence of anything.
Seven open questions, and none of them is “who approved it?”
This is the finding that makes the comment window worth your time. The working group publishes the seven questions it is genuinely undecided about, each with a tracking issue:
- Does per-field mutability belong in 3.0?
- Do seller catalogs belong in 3.0, or should the object stay inline?
- Cross-channel guarantee comparability is unsolved — how do you compare a completion rate to a viewable rate?
- The format registry has no entries for audio, CTV or DOOH.
- Is a min_line_items field needed to require a bundle purchase?
- Should payment terms and invoicing party be catalog references?
- Does the environments enumeration hold up against real inventory?
Every one of those is a good question, and every one is about the shape of the object. Not one is about the person who approved a change, the client whose account it touched, the jurisdiction it ran under, or how long the record survives. That is not a criticism of the seven — it is a description of the frame the working group is working inside. The standard is being asked to model a transaction, and it is answering that question well.
Which is precisely why the deadline matters. Comment closes 22 October 2026, and you do not need to be an IAB Tech Lab member to file one — a GitHub account is enough. If the operating layer matters to your clients, this is the moment it can be put on the record, in the record’s own repository.
A party is not a person
Step back and the shape of the gap is simple. AAMP 3.0 standardises the agent (identity, credentials, eligibility), the deal (71 fields of it), and the assent (a signed record of both parties agreeing). That is the transaction layer, done properly.
The operating layer — the one a financial-services agency lives inside — answers a different question. When the FCA asks in November about a February creative, or a compliance officer asks which client engagement a budget change belonged to, nobody is asking which side of the deal moved a term. They are asking five things: who approved it as a named person, when, for which client, under which jurisdiction, and where the record lives that is not the platform’s to delete. A protocol whose actor is buyer | seller is answering the first question at the level of an organisation, and the last four not at all.
None of that makes AAMP 3.0 wrong. A media-buying protocol modelling a media-buying transaction is a protocol doing its job. The mistake would be to read standardizing agent authentication and authorization protocols — WPP Media’s own description of the release — and conclude that governance is handled. Authorisation at the protocol layer means the agent was allowed to transact. It does not mean a person was accountable for the change.
Where Ott sits, and what we won’t claim
Ott’s Activity Log is the operating-layer counterpart to exactly this gap. It records the operation rather than the assent: the actor, the value before and after, the timestamp, and the linked object — stored independently of the ad platform that accepted the change, so the record survives a restriction that wipes the platform’s own history. It is deliberately not a transaction protocol. It is the thing you reach for when a regulator asks about one decision months later.
Two honest limits, before anyone else raises them.
- Our coverage is narrower. Activity Log covers Meta today, with Google Ads on the roadmap. AAMP 3.0 is channel agnostic across seven channels and four transaction types. If you need the standard, the standard is better than our coverage, and we are not going to pretend otherwise.
- We publish no retention number. That is the same gap we hold other vendors to, and it is not closed by us owning a different product. What we will say is where ours differs in kind: our record is written to a store that is not the ad platform’s, and you reach it outside the platform rather than through a screen inside it.
On cost, the same discipline: Ott is priced by brands and seats rather than by ad accounts, data sources or Telegram joins. We are structurally uninterested in metering how often you look at your own evidence.
If you are going to comment, ask for this
The draft is a real invitation, and the seven questions above are where the working group says it is undecided. Here is what a regulated agency would add, in language the spec can absorb:
- Ask whether the negotiation history can name a person, not only a party. actor: buyer | seller is the right default for a machine-to-machine negotiation. It is not enough for an operation that a regulator will ask about by name.
- Ask for a jurisdiction or market field on the line item. The spec is proudly channel agnostic and transaction-type agnostic. Financial promotions are neither.
- Ask what happens to the record after execution. The lifecycle runs Publish, Discover, Compare, Qualify, Negotiate, Bind & Execute, Report — and then hands reporting to other standards. Name the operator who needs the record to outlive the deal.
- Ask for a retention floor. Nothing in the draft sets a lifetime for any object. A signature-backed assent record with no published lifetime is a claim waiting to expire.
- Send implementation feedback, not just a comment. The repo has a template for exactly this, and a working group that reads it. The most useful thing a regulated agency can contribute is the shape of the question it gets asked in an audit.
The half the standard is not built to hold
This is not a post about a standards body failing. AAMP 3.0 is the clearest evidence yet that the category has grown up: the vocabulary is standardised, the identity model is standardised, the transaction is standardised, and the whole thing is being argued in public with a written disposition for every comment. That is what a real standard looks like.
But a standard and a record are different objects, and the difference is the one an agency gets audited on. AAMP 3.0 will tell you, precisely and provably, that a buyer and a seller agreed to a binding set of terms. It will not tell your client, eight months later, who on your team approved the change, for which engagement, under which regime. That answer lives one layer down, in the operations record — and the window to say so is open until 22 October.