Protocol Integration and Agent Readiness Work

The protocol layer of an agentic integration is the half somebody has already costed: AgenticAdvertising.org, which publishes AdCP, puts a from-scratch build at 14 to 18 weeks and ships a TypeScript SDK that takes most of it off you. The layer underneath it, the one that decides whether your agent sells anything worth selling, has never been priced by anybody, AAO included. Every quote you receive this year blurs the two together, which is how the expensive half gets billed as though it were the cheap one.

So split any integration proposal in half before you read the number on it. Ask which of the two layers the figure covers, ask for the second half itemised, and treat a single blended total as a refusal to answer.

Your engineering lead is pricing the whole build. AdCP has already priced three quarters of it.

The cheap number is a card on the front page of AdCP’s building docs:

Point a coding agent at a skill file, get a storyboard-compliant AdCP agent in 2–8 minutes (protocol layer only — see Operating an agent for the full going-live scope).

AgenticAdvertising.org (AAO), a Delaware nonprofit trade association, numbers the Ad Context Protocol stack L0 to L4: wire and transport, identity and signing, auth and registry, protocol semantics, and your business logic. No SDK goes above L3, and only one language reaches it. The coverage matrix on the SDK stack page, last updated 3 May 2026, marks @adcp/sdk 6.9.0 for TypeScript shipped at L0 through L3, the Python adcp 3.x production line partial at L1, L2 and L3 with the 4.x rewrite still in beta, and adcp-go partial at L0 and not covered at all above it. Against L4 the same page writes one line: “Out of scope for any SDK. The adopter writes this.” It also says Python and TypeScript are “committed to full L0–L4 coverage”, which the L4 line above it rules out.

The same page prices everything above it to the week. Seven lifecycle state machines at a week each, a week for the idempotency cache, one or two each for the async-task store, the error catalog, the comply_test_controller surface and webhook emission, two or three for RFC 9421 signing. Three to four person-months, and the wording matters: that is “of L3 work alone, before any L4 differentiation”. The full from-scratch build is 14 to 18 weeks for one senior engineer, multiplied by two or three at publisher scale for SRE, security review, key infrastructure and on-call.

Read the disclaimer attached to that band before you use it as a ceiling. The estimate “excludes version-adaptation work”, because “every spec rev that adds a tool, an edge, or an error code adds rows to a translation matrix you carry forever”. So 14 to 18 weeks is a floor for a seller, and the only honest published number in the category is a floor.

A buyer is cheaper by construction. The caller reads state machines instead of enforcing them, supplies idempotency keys instead of maintaining the cache, classifies error codes instead of choosing which to emit, and in AdCP’s own words has no comply_test_controller surface to expose “and no conformance bar to certify against on the consumer side”. Handler glue, signing, registry lookup, response parsing: weeks, not months.

I don’t publish an L4 range either, and I’d distrust anyone who does. A band is honest at L0 to L3 because it is the same work at every shop, which is exactly why AdCP could publish one and why you can hold any vendor to it. At L4 the same job title covers a two-file review and a full sell-side build, because L4 is your forecast, your rate card, your creative policy and your calls into GAM, FreeWheel, Kevel or whatever does your decisioning.

Agentic Advertising Management Protocols (AAMP), IAB Tech Lab’s umbrella over eight independently versioned repositories, has no GA SDK in that right-hand column, and the shared wire contract is unreleased by its own statement. Both IAB reference agents pin the wire contract from a git URL rather than a package index. At the commits cited here, seller-agent/pyproject.toml and buyer-agent/pyproject.toml both read iab-agentic-primitives[client] @ git+https://github.com/IABTechLab/iab-agentic-primitives.git@v0.5.0; on main, read on 16 August 2026, both have moved to @v0.5.1. Three of its schema pairs are missing a half: AgentDiscovery has a request and no response, ChangeRequest and NegotiationRound have responses and no requests. Every integrator writes those halves, and nothing forces two of them onto the same shape. AdCP ships one versioned registry; AAMP’s eight repositories version independently of each other, so an AAMP integration has nothing single to pin, and that difference is most of why the two stacks cost different amounts to adopt.

Ask your ad ops lead one question before you scope anything: are forecast and rate card available over an API today? That answer sizes the project more than the protocol choice does. If both are reachable, L4 is wiring. If neither is, the first phase of your agentic project is exposing them, and that phase is not an AdCP project at all. Ask me for a number once that scope is written, and apply the same rule to anyone who offers you one before it is.

You cannot audit a quote against a website

The check takes two fetches. Pull the requirement matrix every scoping conversation cites, then pull the same file out of the repository at a pinned commit. On 16 August 2026 they did not describe the same agent.

The rendered page gives every AdCP agent a one-row Shared table holding get_adcp_capabilities, and lists list_creative_formats as Required for both the sales agent and the creative agent. The repository gives a two-row Shared table, adding sync_agent_notification_configs as Conditional, puts get_adcp_capabilities in the sales agent’s own table, and has removed list_creative_formats from both roles. Canonical format discovery, the pinned file says, “is no longer a shared task”. The registry API reference on the same domain that still mandates list_creative_formats describes it in the same breath as “the deprecated list_creative_formats catalog for 3.1-compatible agents”.

So the live requirement matrix requires an operation the live documentation calls deprecated, and a sales agent’s Required set is eight against the website and seven against the repository. Those are the two numbers a vendor scopes from, and nobody tells you which one the proposal used.

Two of those rows move depending on which artifact you opened. The sales agent’s seven Required is the pinned count, where get_adcp_capabilities sits in the role’s own table; the rendered page reaches eight by adding the shared row on top of a table that counts list_creative_formats instead. The brand agent’s four Conditional is the rendered count; at the pin it is three, because creative_approval has been moved out with an explanation the render never shows, that “its creative-approval-request.json shape is a webhook payload, not an AdCP task”.

Every agent also owes the shared get_adcp_capabilities, which the pinned file lists in the Shared table and again in the sales agent’s and the creative agent’s own tables. Those two rows already count it; add one to every other row, so a signal agent’s real Required set is three operations rather than the two printed above.

Two structural holes are worth knowing before somebody prices around them. An agent doing Trusted Match is graded by nothing here at all, because “TMP uses a different communication model (direct HTTP, not MCP/A2A tasks)” and the matrix has no row for it. And two different tables carry the heading “Brand agent”, one under Brand Protocol with a single Required operation and one under Sponsored Intelligence with three, with nothing in the document saying which brand agent you are.

The buyer side is the cleanest finding on the page. “Orchestrators are not MCP/A2A servers”, so buy-side conformance is five numbered obligations and no implemented operation: authenticate, send required fields, handle async responses and webhook delivery, carry media_buy_id forward, respect creative_deadline. A readiness score that grades a DSP on operation count therefore has nothing to count, and will report a zero that says nothing about the DSP.

Two operations survive the diff and then vanish. sync_agent_notification_configs, Conditional for every agent in the pinned Shared table, and validate_property_delivery, Optional for property governance, are registered nowhere in the 3.1.13 manifest of 64 operations. They exist in the requirement matrix you can only see by reading the repository, and they do not exist in the release you would validate against. The full registered-versus-shipped split is on adcpexplorer.

Can anyone sell you an AAO Verified badge?

AAO Verified has carried Status: Request for Comments and Last Updated: May 11, 2026 since the spring, which is three months of a trust mark being drafted while vendors write it into contracts. It has two qualifiers, (Spec) for wire conformance and (Sandbox) for a production endpoint that tolerates sandbox-flagged traffic, and (Sandbox) replaced an earlier (Live) framing whose supporting issues, including the attestation_verifier scope, “are deferred. They remain relevant if AAO ever returns to a canonical-campaign model, but are not load-bearing under (Sandbox).”

The accounts specification did not get the message. It still says that “Media-buy sales agents advertising AAO Verified (Live) readiness (tracked in #2965) MUST support a named scope identified by scope_name: \"attestation_verifier\"”, and it repeats that binding in three more places. Five files in the same documentation tree still write (Live) as a qualifier you can hold: trust.mdx, accounts/overview.mdx, building/index.mdx, building/by-layer/L4/build-an-agent.mdx and building/operating/seller-integration.mdx. One tells sellers to consider enrolling in it; the accounts file is the one that turns it into a MUST. Build the accounts specification front to back and you ship a named authorisation scope for a badge tier the verification page retired, whose own supporting issues that same page marks deferred. Closing that MUST is a reading job for you and an open issue for them.

The reframe also cut work, which nobody selling readiness will mention. A production-only platform with no test-mode surface earns (Sandbox) by exposing its registered production URL to AAO’s runner with sandbox flagging, “no separate test endpoint needed”. The price of that is a hard isolation requirement: cross-mode leakage “MAY skip the grace period and revoke immediately”, where an ordinary regression gets 48 hours.

Then there is what a badge clause cannot promise. In June 2026 an AAO tracking issue recorded that “LoopMe (Founding Member) cannot earn their AdCP 3.1 / sales-non-guaranteed Verified badge until #5664 and #5665 are resolved and a fix ships in a published adcp-3.1 release (9.0.x)”. Both blockers are P0 bugs in the compliance suite rather than in LoopMe’s code. One scenario ran unconditionally because a documented opt-out “was closed COMPLETED but has no linked PR, empty acceptance-criteria checkboxes, and no changeset”. The other could only be passed by making an outbound call to a buyer-registered governance agent URL, which “carries an SSRF / egress cost in production (calling buyer-supplied URLs)”, so a conformance requirement arrives as a security review item. The same tracking issue leaves a governance question open: “Does Scope3’s PENDING→ACTIVE activation gate read the canonical-line (3.0) heartbeat run, or a specific version’s (3.1) run?” Write badge issuance into a payment milestone and you have moved all of that onto your schedule.

Ask which version the runner grades, too. The reporter of #5665 found that a compliance record came back stamped 3.0.18, “the cloud runner grades against published npm tags”, so the release you pinned, the SDK you installed, the peer you called and the tag the grader happened to publish are four different version axes, and at 3am “which version failed me” has four answers.

Eligibility is the last gate and the one no engineering closes. AAO requires “an active AAO membership with API-access tier”, says a membership lapse “revokes the entire badge regardless of test results”, and revokes “every version of an agent’s badges atomically (the trust mark is agent-level, not version-level)”. The mark states its own limit, “Not certification beyond AAO membership”, and AAO’s AI disclosure page says AAO “is both the issuer and the grader of these credentials” for the separate Academy track. Passing one gets you nothing in the other.

Storyboards are AdCP’s executable conformance suite, YAML scripts a compliance runner replays against a live agent, grading 21 declared specialisms on top of the universal set. I can get you to a passing storyboard run. I can’t sell you the membership, and neither can any other vendor. Worth knowing whose incentives are in that paragraph: AAO sells the membership the badge depends on, and I don’t buy media, plan it or resell it, and take no commission on spend, so the only thing I have to sell you is the reading.

Both bodies have published a list of what they have not checked

AdCP’s is the one you have just read: deferred issues, P0 bugs in its own compliance suite, an operation the requirement matrix mandates and the release does not carry. AAMP publishes its own, and it is a different kind of document. Put the two inventories side by side and cross out every row that costs you nothing. A publisher booking direct is left with the OpenDirect 2.1 booking surface and the supply-chain identity files it already gets audited on. A DSP is left with the transport envelope and none of the booking rows. What survives the crossing-out is the project, and it is a shorter list than either body’s.

AAMP’s inventory is machine-generated, and that is the only reason I trust the numbers in it. STANDARDS_GAP_REPORT.md is rendered by the library’s own conformance runner and guarded by a drift test that fails when the committed file stops matching a fresh render. It tracks 12 standards: 4 self-conformant, 0 partial, 8 unverified pending an external specification. It publishes its own scale, “396 checks, 303 passed, 0 failed, 93 skipped across 147 vectors / 50 targets”, and it names its worst row, “Highest-priority gap: IAB OpenDirect 2.1”, the booking surface that has to reconcile with whatever bills your advertisers.

I’d go further than they do. Two of the eight matter more to a publisher than OpenDirect does, and neither gets a headline. One is sellers.json and ads.txt, the supply-chain identity layer you already operate and already get audited on. The other is the A2A and JSON-RPC 2.0 envelope, which is the transport itself.

Consent is a third case and a different one: GPP and TCF are carried as opaque values with no section validation, no TC-string decode and no vendor-list check, and the report calls that “the FD-10 (flagged decision) opaque placeholder”, so it is a decision somebody took rather than a box nobody ticked. Tell your privacy counsel it is a placeholder, not an oversight, and the conversation goes differently. Two rows of the eight are left over after that: IAB Deals API 1.0 and the AdCOM and OpenRTB supply-chain object, unverified for the same reason as the rest and unlikely to be the row that stops anybody.

Those rows don’t cost the same to close. The trust-mark drift is findable in your accounts implementation in an afternoon, and the finding is which scope you built for nothing. OpenDirect fidelity only surfaces in a build, because it is a field-by-field reconciliation between an agentic order and the system that bills it, and nobody grades that from the outside.

The registry row is different in kind from the other seven. AAMP’s own agent discovery and trust registry specification, third in the report’s own listing, is unverified with the remediation step “Obtain the IAB Tech Lab AAMP (agent discovery and trust registry) specification.” The people who wrote the wire contract couldn’t get the registry spec either. Which hostname that registry answers on is itself unsettled, and the discovery guide resolves it. Until that changes, no work on your side closes that row, and any vendor who tells you otherwise is quoting you for a document they do not have either.

The bill that arrives before any protocol work starts

Every gap so far has been somebody else’s to close. The one that stops your project is yours, and no release closes it. The 3.1.13 release has a slot for almost every commercial decision you are worried about. floor_price is a number on eight of the nine pricing options. exclusivity is a three-value enum on the product, none, category or exclusive. daypart_targets is an array on the targeting object, and rate_card is a string on the account. What no schema anywhere carries is which number, which advertiser, which segment. The wire has the slots; filling them is L4, and filling them is a policy your commercial team has never had to write down. An agent applies the policy it can read, so either somebody writes those decisions down or the defaults in your handler code become your commercial policy.

That is the bill, and a publisher running an AdCP sales agent trial put a figure on it in r/programmatic:

“we spent 3 weeks just trying to get sales and ops to align on what a ‘good deal’ looked like before we could automate anything useful”

Three weeks is what the alignment costs when sales and ops sit in the same building and both want the project. It is a quarter when the two functions report into different P&Ls and the answer moves someone’s commission, and that is the version I see more often. The integration ships either way, on whatever the engineer picked, and starts executing terms nobody signed off.

Anthony Katsur, IAB Tech Lab’s chief executive, told Digiday in January 2026 that “when multiple groups try to solve the same problem independently, you get confusion, wasted engineering effort, and inconsistent implementations that never fully scale. Standards proliferation is a real cost to the industry.” Katsur is describing a cost his own organisation is generating: eight repositories versioning apart from each other, no GA SDK, and a registry specification his own wire-contract authors have filed a remediation step asking to be sent. Neither standards body pays for the split it creates.

What each engagement ends in

An implementation review is a second reader on an integration you have already started. I grade what you’ve built against the required-tasks specification for your role, and against the 3.1.13 schema index for the operations, rather than against whatever main happens to contain that week. It ends in a list: deprecated fields you are still sending, your requirement level per operation, your transport declaration, and the operations you implemented that nobody asked you for.

A readiness audit is the same exercise before code exists. Role in the transaction, transport, requirement level, discovery model, and whether the registry you would federate into will let you in, each answered in writing, with a gap list against a named release and a build-or-wait recommendation carrying its reasoning. There is no maturity score in it. There is also a threshold below which the honest finding is to wait.

The cheapest useful thing a publisher can do is get adagents.json and brand.json right, and it is the thing most often wrong on the first attempt. The file has two mutually exclusive shapes, a URL-reference variant requiring authoritative_location and an inline variant, and picking the wrong one is the most common first error I see. Nothing errors when you choose wrong; your inventory is simply not attributable to the agent you authorised, and a strict validator has grounds to ignore the file. I wrote how the discovery files fit together as the free version of this. The paid version is me reading yours.

Builds are the rest of it. On the sell side that is inventory, pricing, creative review and decisioning, wired to the operations your role actually owes. On the buy side there is no server to stand up, so the work is planning, buying and reporting against someone else’s operations plus the five obligations the specification puts on the caller. I use the AdCP SDKs at L0 to L3 and write L4 against the published schemas, not against a commercial vendor’s abstraction over them, because the schemas are the thing that carries a version number. How a machine buys media traces the wire path one of those builds follows.

Who this is for, and who it is not

Publishers and platforms deciding whether to expose a sales agent. Agencies and DSPs weighing a buyer agent build against holding for one more release, where a written audit costs less than the quarter otherwise spent guessing. Vendors who want a reader from outside both standards processes, which is most of my work.

AAO handed development of the reference sell-side agent to the Prebid community in February 2026, described in the SDK stack docs as an open-source seller-side agent publishers run as their AdCP-facing implementation, “hand-rolled at L0–L3 today”. What that free path doesn’t cover is pointing it at your actual inventory and finding out which boundary breaks.

Not you, if what you want is an implementation partner to write the protocol layer. The SDK already ships it, and any line item covering it is a line item you can strike before you sign.

There is a fair case for waiting, and it arrives inside a report of good news. In June 2026 Łukasz Kapuśniak, running the purrsonality-seller reference implementation, filed what he called “a check-in, not a request”: the 3.1 surface was “largely landed and runnable”, 74 of 75 media buy lifecycle scenarios passing, the residual failures “either already fixed in flight … known runner-side gaps … or out-of-scope-by-design”. He still had to ask the working group “what does the WG actually need from reference implementers before 3.1 can graduate from preview to a target the comply runner treats as badge-eligible?” The people closest to conformance could not tell from outside when the line they were building against would become badge-eligible.

Email hello@agenticadlab.com with your role in the transaction, your current integration state, and which stack. That’s enough for me to say whether there’s an engagement here or whether you get a two-line reply telling you to wait.