agent‑ads.org
Publish · End-to-end adoption chain

How publishers and agent runtimes adopt the protocol.

Three roles in the agent-native ad ecosystem each publish something at a well-known path: sponsors publish a manifest declaring what they offer, agent runtimes publish an architecture statement attesting to their editorial separation, and the broadcast feed publishes ranked eligibility signals. Adoption is not an API integration — it is publication.

Who publishes what

Three roles, three things to publish. (Sponsor, here, means the advertiser or brand publishing the declaration; agent runtime means the AI surface operator that places ads.)

RoleWhat you publishWhere
SponsorCovenant manifest declaring sponsorship + attestation/.well-known/agent-ad.json
Sponsor (continued)Broadcast feed with current eligibility signals/.well-known/abf.json + /.well-known/abf-index.json
Agent runtimeEditorial-firewall architecture statementLinked from the runtime's manifest if present, or from a stable site documentation path

Each artifact is public, agent-readable, and fetchable without authentication. The protocol works because all three are observable from the outside — not because a centralized vendor mediates them.

What sponsors publish

A sponsor — a brand or product team that wants its placement to be verifiable on agent surfaces — publishes two things:

  1. Covenant manifest at /.well-known/agent-ad.json. A small JSON file declaring who you are, what you are sponsoring, your declared category and placement constraints, and the attestation method (signed or watermarked) by which the manifest can be verified.
  2. Broadcast feed at /.well-known/abf.json + /.well-known/abf-index.json. Ranked, time-stamped signals that agents poll for current eligibility. The index is for fast lookup; the feed is the source of signal data.

Both files are stable, signed or watermarked according to the declared attestation method, and reachable to discovery crawlers (GPTBot, OAI-SearchBot, ClaudeBot, etc.).

A reference manifest schema and example feed are in the ABF integration guide.

What agent runtimes publish

An agent runtime — the operator of an AI surface that places ads — publishes one thing:

An editorial-firewall architecture statement. A short description of how the runtime separates ad placement from answer generation: data-flow direction, post-generation ordering, and the absence of any feedback loop that lets ad outcomes shape answer content. The statement is linked from the runtime's covenant manifest (if it has one) or from a stable site documentation path.

See /editorial-firewall for what the architecture statement should describe. A dedicated schema field for the statement may be added later as the manifest schema evolves; for now the statement-plus-link approach is the contract.

The publication surface, end-to-end

Adoption produces a chain of verifiable artifacts that any agent or auditor can fetch in sequence:

StepArtifactPublished byVerified by
1Content provenance (FCS headers)Content publisherAnyone reading the response
2Covenant manifestSponsorAnyone fetching /.well-known/agent-ad.json
3Broadcast feedSponsorAnyone fetching /.well-known/abf.json
4Editorial-firewall statementAgent runtimeAnyone reading the runtime's manifest or docs

The chain is the protocol. Each step is independently verifiable. None requires trusting any other actor — verification reads only public artifacts.

How adoption is verified

A consumer (an agent runtime placing ads, an auditor, a brand-safety vendor) verifies adoption by:

  1. Fetching each artifact from its declared path.
  2. Verifying the manifest's attestation method (signature, watermark, or other declared mechanism).
  3. Confirming the broadcast feed's eligibility window for the candidate ad.
  4. Reading the runtime's editorial-firewall architecture statement against observable behavior.

If all four read cleanly, the candidate is adopted in the protocol's full sense — not just listed but verifiable.

The verification flow itself is documented in the ABF integration guide. The pre-render check that runs verification at placement time is on the /brand-safety-verification page.

Where this fits relative to OpenAI Ads

OpenAI Ads is one buyer-side platform: campaigns, ad groups, creative, auction, dashboards live on OpenAI's surface. Sponsors who participate in OpenAI Ads publish their ads through OpenAI's product.

Publishing into the ABF protocol is separate and complementary. A sponsor can publish a covenant manifest and broadcast feed that any agent runtime can read, independent of which ad platforms also distribute the same offer. The manifest is the sponsor's own surface, not a platform's.

OpenAI Ads can operate alongside ABF-published sponsors — and agent runtimes that adopt ABF gain the ability to verify sponsors who publish across multiple platforms with a single attestable declaration.

What /publish is not