adagents.json Is the New ads.txt - And the Industry Isn't Ready

In 2017, the IAB Tech Lab introduced ads.txt to solve a simple problem: publishers had no way to publicly declare which SSPs were authorized to sell their inventory. Domain spoofing was rampant. DSPs couldn't tell real inventory from fake.

ads.txt fixed it with a text file. One file, one URL, one question answered: who can sell my inventory?

Now the industry faces the same problem again - but on the demand side, and with AI agents.

AI buying agents are already transacting programmatic media. Magnite embedded a seller agent into SpringServe in December 2025. The Trade Desk's Kokai automates bid decisions at scale. PubMatic launched agentic optimization capabilities. The question isn't whether agents will transact media. They already do.

The question is: how does the supply chain verify them?

The Problem adagents.json Solves

Today's verification infrastructure is entirely supply-side.

Standard | What It Verifies | Direction

ads.txt | Which SSPs can sell my inventory | Publisher → SSP

sellers.json | Who are the entities in this supply chain | SSP → Buyers

schain | What path did the bid request take | Supply-side trace

None of these answer a new, critical question: Is this AI agent authorized to represent the publisher it claims to act for?

When a seller agent appears in a transaction claiming to represent CNN's CTV inventory, the buyer agent currently has no standardized way to verify that claim. The agent might be authorized. It might not. Without a verification file, there's no way to know.

adagents.json is the answer.

How adagents.json Works

The concept follows the same domain-ownership model as ads.txt. Publishers host a JSON file at a known URL on their domain:

text
https://publisher.com/.well-known/adagents.json

The file declares which AI agents are authorized to sell the publisher's inventory. Here's the structure:

json
{
  "contact": {
    "name": "Ad Ops Team",
    "email": "adops@publisher.com",
    "seller_id": "pub-123456",
    "tag_id": "f08c47fec0942fa0"
  },
  "properties": [
    {
      "property_id": "web-main",
      "property_type": "website",
      "name": "Publisher Main Site",
      "identifiers": { "domain": "publisher.com" }
    }
  ],
  "authorized_agents": [
    {
      "url": "https://agent.ssp.com/sell",
      "authorized_for": "All programmatic display and video",
      "property_ids": ["web-main"]
    }
  ]
}

Three key sections:

Contact links the file to the entity managing it, including their sellers.json seller_id - connecting the agentic authorization to existing verification infrastructure.

Properties declares the publisher's inventory - websites, CTV apps, mobile apps - with unique identifiers like domains or app store IDs.

Authorized Agents lists which agent endpoints can sell which properties. If a property list is provided, the agent can only sell those specific properties. If omitted, the agent can sell everything.

The Bidirectional Verification Model

Here's where adagents.json is actually stronger than ads.txt.

ads.txt is one-directional. The publisher declares authorized sellers, and DSPs check against it. But there's no requirement for sellers to confirm back.

adagents.json uses bidirectional verification:

1. Publisher side: The publisher's adagents.json declares which agents are authorized
2. Agent side: Each seller agent implements a list_authorized_properties endpoint that returns which publishers it represents
3. Buyer verification: Buyer agents cross-check both sides before executing a purchase

If the publisher's adagents.json says Agent X is authorized, AND Agent X says it represents that publisher, the authorization chain is verified from both directions. If either side doesn't confirm, the buyer agent knows something is wrong.

This is the trust model ads.txt should have had from the start. The programmatic industry learned from 20 years of supply chain fraud that one-directional declarations aren't enough. adagents.json bakes bidirectional provenance into the protocol from day one.

Two Standards, One Problem

The agentic advertising space currently has two frameworks approaching this problem:

IAB Tech Lab: AAMP

The Agentic Advertising Management Protocols (AAMP) is IAB Tech Lab's comprehensive initiative. It has three layers:

• ARTF (Agentic RTB Framework): The execution control plane that defines how agents participate in real-time bidding. Claims 80% latency reduction compared to conventional RTB.
• Agent Registry: Launching March 1, 2026 - a trust layer where companies register their agents for transparency and accountability.
• Management Layer: Defines how buyer and seller agents negotiate and transact, with open-source SDKs planned for 2026.

IAB Tech Lab CEO Anthony Katsur stated: "Execution infrastructure is meaningless without shared standards. And the ecosystem needs a neutral party providing agent transparency."

AdCP: The Community Standard

The Ad Context Protocol (AdCP) is a community-driven open standard backed by Equativ, Scope3, PubMatic, Yahoo, Samba TV, LG Ads, and others. This is where adagents.json originates.

AdCP operates at the campaign level rather than the impression level. Instead of millisecond auctions, it enables agents to negotiate budgets and outcomes over weeks or months through structured conversations built on MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols.

The first production release shipped in October 2025. Magnite's December seller agent test was an AdCP transaction.

Both standards address agent authorization. Both recognize that the supply chain needs a new trust layer. Whether they converge, coexist, or one wins is an open question - but the direction is clear.

Why the ads.txt Pattern Will Repeat

Here's what we see from monitoring 362K+ publisher domains: the exact failure patterns from ads.txt adoption are already visible in early agentic infrastructure.

The adoption gap. After ads.txt launched in 2017, adoption took 2-3 years to reach critical mass. During that window, publishers who had clean files gained an advantage. The same window is opening now with adagents.json.

The accuracy problem. Today, 24% of ads.txt entries fail sellers.json verification. That's not because publishers don't care. It's because maintaining machine-readable authorization files is an operational challenge that most teams underestimate. adagents.json adds another file to maintain - with more complex schema requirements (JSON, not flat text) and bidirectional verification requirements.

The silent failure mode. When ads.txt has errors, DSPs silently skip your inventory. No notification. Revenue just drifts down. The same will happen with agent authorization. If your adagents.json is missing, misconfigured, or stale, buyer agents will route around your supply. You won't know why.

The SSP dependency. ads.txt verification depends on SSPs maintaining accurate sellers.json files. Agent verification will depend on SSPs deploying and maintaining seller agents that correctly declare their publisher relationships. The SSPs that move first gain a verification advantage. The ones that lag create verification gaps for their publishers.

What This Means for Publishers Right Now

The standards aren't finalized. The Agent Registry launches March 1. The SDKs are being built. But the pattern is clear enough to act on.

Your ads.txt needs to be clean today. adagents.json's contact section references your sellers.json seller_id. If your existing verification chain is broken, the agentic layer inherits those failures. Fix the foundation before building on top of it.

Monitor which of your SSPs are deploying seller agents. Magnite has one. PubMatic is building capabilities. Your SSP partners' readiness for agentic transactions directly affects whether buyer agents can reach your inventory through verified paths.

Understand that this is additive, not replacement. adagents.json doesn't replace ads.txt. It adds a new authorization layer for a new class of transactions. You'll maintain both. The verification stack grows: ads.txt + sellers.json + schain + adagents.json + agent registry.

Start reading the specs. The AdCP documentation and IAB Tech Lab's AAMP roadmap are both public. The technical details matter - this isn't a marketing initiative. It's infrastructure.

Check your current verification health to see where your ads.txt and sellers.json stand today. A clean supply chain is the foundation that agentic verification builds on.

Frequently Asked Questions

Do I need to create an adagents.json file right now?

Not yet. The standards are in early adoption, and most buyer agents aren't enforcing adagents.json checks. But the SSPs building seller agents (Magnite, PubMatic) are already working with the format. When your SSP asks you to authorize their agent, you'll need the file.

Does adagents.json replace ads.txt?

No. ads.txt authorizes SSPs to sell your inventory through traditional programmatic channels. adagents.json authorizes AI agents to represent your inventory in agentic transactions. They serve different transaction types and will coexist.

Which standard should I follow - AAMP or AdCP?

Both are active and evolving. AdCP has the adagents.json format and early production implementations. AAMP has the IAB Tech Lab institutional backing and the Agent Registry. For publishers, the practical advice is the same either way: keep your supply chain clean, monitor which SSPs are deploying agents, and be ready to publish authorization files when asked.

How is this different from sellers.json?

sellers.json is maintained by SSPs to declare their seller relationships. adagents.json is maintained by publishers to declare their agent authorizations. Different file, different owner, different question answered. But they reference each other - adagents.json includes the seller_id from sellers.json to link the two systems.

Will BeamFlow monitor adagents.json?

Our crawler infrastructure already monitors 362K+ domains for ads.txt and 2,000+ SSPs for sellers.json. As adagents.json adoption grows and standards stabilize, monitoring agent authorization files is a natural extension of what we do.