agent‑ads.org
Agent Broadcast Feed · Explainer

Agent-readable ad feeds make placement validation possible before render.

When agents mediate the placement of ads, the question "is this placement safe?" needs an answer before the ad renders, not after. ABF — the Agent Broadcast Feed — is a manifest-and-feed layer that gives agents what they need to decide: a verifiable declaration of who is sponsoring what, plus a machine-readable feed of verified signals they can poll for eligibility and ranking.

What ABF is, in one paragraph

ABF is two artifacts on a publisher's domain. First, a covenant manifest at /.well-known/agent-ad.json — a small verifiable JSON file (signed or watermarked) declaring who you are and what you are sponsoring. Second, a broadcast feed (/.well-known/abf.json and /.well-known/abf-index.json) — frequent machine-readable updates that agents poll for eligibility and ranking. Both are open, agent-readable, and provenance-anchored. Agents discover the manifest, verify its provenance, then read the feed.

Why this matters for agent surfaces

Behavioral ad systems decide placement by tracking the viewer. Agent surfaces cannot do that — there is no viewer to track in the cookie sense, and the surface is the agent's own output. Placement has to be decided from properties of the content (the surface) and sponsorship attestation (the advertiser's verifiable declaration), not from a user profile.

ABF makes the sponsorship attestation a stable, verifiable artifact that any agent can fetch, check, and rank against. Brand teams gain a pre-render verification path. Publishers gain a way to monetize without giving up query-level logs. Agents gain a clean signal: was this ad declared, attested, and verifiable, or not.

The two artifacts

ArtifactPathRole
Covenant manifest /.well-known/agent-ad.json Verifiable declaration: who is sponsoring, what category, what attestation method
Broadcast feed /.well-known/abf.json  +  /.well-known/abf-index.json Ranked, time-stamped signals agents poll for eligibility

The manifest is identity. The feed is signal. Together they let an agent answer two questions before render: is this advertiser real and verifiable? and is this specific signal currently eligible to be shown?

Brand safety as a pre-render check

In display-ad systems, brand safety is mostly post-hoc: an ad runs, a verification vendor flags it, the buyer gets a report. By then the impression is sunk cost and the brand association is already made in the eye of the viewer.

On agent surfaces, the agent can read ABF before placing an ad. The check happens at the moment the placement is being decided, not after a render the agent already committed to. The pre-render check is mechanically possible because the verification artifact (the verifiable manifest) exists at a stable known path and the feed signal is fetched at decision time — not approximated from third-party tags.

This is what "placement validation possible before render" means in practice.

Where this fits relative to OpenAI Ads

OpenAI Ads sits at the buyer-side: campaigns, ad groups, creative, auction, dashboards. ABF sits at the publisher-and-agent side: how a sponsor's declaration is published, how an agent reads and ranks it, how a brand-safety check is performed before the ad becomes an impression.

OpenAI Ads can operate without ABF. Agent runtimes that need verifiable pre-render placement decisions benefit from ABF being present.

What ABF is not

How to adopt

Three things a publisher does:

The integration documentation lives at /docs/abf/. Reference manifests and feeds, signature verification scripts, and adoption checklists are linked from there.