WTF is adagents.json?

By Agentic Advertising News • Published Feb 11, 2026

If AdCP is the “language” that agents use to buy and sell ads, then adagents.json is the “doorman.”

It’s a small JSON file that lives on a publisher-controlled domain at: https://<publisher-domain>/.well-known/adagents.json. Because the publisher controls the domain, the publisher controls the file. And that means a buyer agent can trust it as the source of truth for: “Which sales agents are actually allowed to sell inventory for this property?”

Why it exists (in one sentence)

adagents.json is how the web gets an agentic equivalent of “authorized sellers”: it helps prevent random third parties from claiming they can sell your inventory.

What’s inside?

In the latest AdCP schema, adagents.json is essentially four things:

• contact: who manages this file (publisher or operator)
• properties: a canonical list of properties (websites/apps/etc.) covered by this domain
• tags: optional metadata to group/describe properties
• authorized_agents: the list of agent endpoints allowed to sell (and what they’re allowed to sell)

The important part is that authorization is explicit and machine-checkable: agents can be authorized by property IDs, by tags, or (in more advanced cases) by referencing properties from other publisher domains.

So what does this look like for agenticadvertisingnews.com?

Below is a real, minimal-but-complete adagents.json you can host for this site. It declares:

• a single website property for agenticadvertisingnews.com
• a couple of tags (so you can grow later without changing the authorization model)
• one authorized sales agent endpoint (your future storefront)
• basic governance-ish identity hints via the contact object

The actual file

Create this file at: /.well-known/adagents.json

{
  "$schema": "https://adcontextprotocol.org/schemas/v1/adagents.json",
  "contact": {
    "name": "Agentic Advertising News",
    "domain": "agenticadvertisingnews.com",
    "email": "ads@agenticadvertisingnews.com"
  },
  "properties": [
    {
      "property_id": "site:agenticadvertisingnews.com",
      "property_type": "website",
      "name": "Agentic Advertising News",
      "publisher_domain": "agenticadvertisingnews.com",
      "identifiers": [
        { "type": "domain", "value": "agenticadvertisingnews.com" }
      ],
      "tags": ["news", "agentic"]
    }
  ],
  "tags": {
    "news": {
      "name": "News",
      "description": "News/editorial surfaces on agenticadvertisingnews.com"
    },
    "agentic": {
      "name": "Agentic Advertising",
      "description": "Coverage focused on agentic buying, AdCP, and automation in advertising"
    }
  },
  "authorized_agents": [
    {
      "url": "https://agenticadvertisingnews.com/adcp",
      "authorized_for": "Official Agentic Advertising News sales agent for agenticadvertisingnews.com inventory.",
      "authorization_type": "property_ids",
      "property_ids": ["site:agenticadvertisingnews.com"]
    }
  ],
  "last_updated": "2026-02-11T00:00:00Z"
}

Two practical notes:

• The authorized_agents[].url should be the HTTPS endpoint for your sales agent / storefront. It can be a “real agent” later — for now, it’s fine to reserve the URL as long as you intend to serve something there.
• The schema allows stricter authorization patterns (like authorizing by tag, or authorizing a sales house that sells multiple properties). This example keeps it simple: one property, explicitly authorized.

See it live

You can see the live adagents.json file for this site here: https://agenticadvertisingnews.com/.well-known/adagents.json

One practical tip if you’re doing this yourself: some deployment systems (including Firebase Hosting and a few static site generators) will skip dot-prefixed folders by default. That means your .well-known/ directory may exist locally but never get published unless you explicitly allow it.

Always double-check after deployment by opening the URL directly in a browser or with curl — if you see your JSON, agents will too.

If you’re unfamiliar with .well-known in general, this is a solid, concise explainer of why it exists and how it’s meant to be used: RFC 8615 — Well-Known URIs .

What changes as AdCP leans into governance?

AdCP 3.x pushes governance primitives (property lists, content standards, suitability calibration) into the protocol layer. But adagents.json remains the base trust anchor: before a buyer agent accepts any claim about “inventory,” it needs to know the seller agent is actually authorized by the publisher domain.

Think of it like this: governance workflows can get sophisticated, but authorization still starts with: “Is this agent allowed to represent this property?”

TL;DR

If you do one thing to make your site “agentic-ready,” host /.well-known/adagents.json. It’s the simplest piece of supply-chain truth you can publish — and it’s foundational for everything else.