> ## Documentation Index > Fetch the complete documentation index at: https://agenticadvertisingorg-snap-format-preview-links.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Ad networks > How AI ad networks aggregate inventory across multiple AI platforms using AdCP — product modeling, account chains, catalog forwarding, governance, delivery reporting, and SI Chat Protocol routing. # Ad networks Ad networks aggregate inventory across multiple AI platforms into a single seller interface. The protocol supports this topology natively — a network is a seller agent that represents multiple publisher properties it doesn't own. ## How a network appears To **buyer agents**, the network is a standard seller agent. Buyers connect to the network's MCP server, push catalogs and data in via standard tasks, and execute buys. To the **underlying AI platforms**, the network is an operator — it holds accounts on each platform and forwards the buyer's catalog data, brand identity, and content standards. ## Product modeling for networks A network's products can span multiple AI platforms using `publisher_properties`: ```json theme={null} { "product_id": "sponsored_response_ai_network", "name": "Sponsored responses - AI assistant network", "description": "Sponsored responses across multiple AI assistants. The network routes to the best-matching platform based on user context and brand relevance.", "channels": ["sponsored_intelligence"], "publisher_properties": [ { "publisher_domain": "assistant-alpha.example.com", "selection_type": "all" }, { "publisher_domain": "assistant-beta.example.com", "selection_type": "all" }, { "publisher_domain": "search-gamma.example.com", "selection_type": "all" } ], "format_ids": [ { "agent_url": "https://ads.ai-network.example.com", "id": "sponsored_response" } ], "delivery_type": "non_guaranteed", "pricing_options": [ { "pricing_option_id": "network_cpc", "pricing_model": "cpc", "floor_price": 0.75, "price_guidance": { "p50": 2.50, "p75": 4.00 }, "currency": "USD", "min_spend_per_package": 1000 } ], "metric_optimization": { "supported_metrics": ["clicks", "engagements"], "supported_targets": ["cost_per"] }, "creative_policy": { "co_branding": "none", "landing_page": "any", "templates_available": true }, "catalog_types": ["product", "offering"] } ``` The network decides which platform serves each impression based on context, relevance, and performance. The buyer doesn't need to know which platform was selected — they see unified delivery reporting from the network. ## Account model for networks Networks typically use buyer-declared accounts (`require_operator_auth: false`). The buyer agent is trusted and declares brands via `sync_accounts`. The network then manages its own account-id namespaces with each underlying AI platform: ``` Buyer agent -> Network (buyer-declared accounts, agent-trusted) Network -> AI Platform A (account-id namespace, operator auth) Network -> AI Platform B (account-id namespace, operator auth) ``` Declare capabilities accordingly: ```json theme={null} { "adcp": { "major_versions": [3] }, "supported_protocols": ["media_buy", "creative"], "account": { "require_operator_auth": false, "supported_billing": ["operator", "agent"], "required_for_products": false, "sandbox": true } } ``` ## Catalog forwarding Networks receive catalogs from buyers via `sync_catalogs` and forward them to the relevant AI platforms. The same task works on both legs — the network acts as a buyer when syncing catalogs to each platform. This is the core data pipe: brand catalog data flows from buyer to network to platform, giving each platform the raw material to generate ads. ## Governance and content standards Networks can enforce [governance policies](/docs/governance/overview) at the routing layer before forwarding to platforms. When a buyer pushes content standards, the network applies them when selecting which platforms and contexts are eligible — then forwards the policies to each platform so they're also enforced at creative generation time. This gives brands two layers of suitability enforcement: the network's routing decisions and the platform's generation constraints. ## Delivery reporting Networks aggregate delivery data from underlying platforms and present unified reporting to buyers via `get_media_buy_delivery`. The buyer sees a single delivery report per media buy — the network handles the per-platform breakdown internally. Networks that want to offer platform-level transparency can use `reporting_dimensions` to expose placement-level breakdowns. ## Declaring your network in brand.json A network declares its properties in its [`brand.json`](/docs/brand-protocol/brand-json) using the `relationship` field. This uses the same vocabulary as adagents.json's `delegation_type`, creating a bilateral verification chain — the AdCP equivalent of `sellers.json` in programmatic advertising. ```json theme={null} { "house": { "domain": "ai-network.example.com", "name": "Example AI Network" }, "brands": [{ "id": "ai_network", "properties": [ { "type": "website", "identifier": "ai-network.example.com", "primary": true }, { "type": "website", "identifier": "assistant-alpha.example.com", "relationship": "delegated" }, { "type": "website", "identifier": "assistant-beta.example.com", "relationship": "delegated" }, { "type": "website", "identifier": "search-gamma.example.com", "relationship": "ad_network" } ], "agents": [{ "type": "sales", "url": "https://ads.ai-network.example.com", "id": "network_sales" }] }] } ``` For delegated and network paths, the `relationship` field uses the same values as `delegation_type` in adagents.json. `owned` is a brand.json-only relationship for first-party inventory: | Relationship | Meaning | Example | | ----------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | `owned` (default) | You own and operate this property | Your own website | | `direct` | You are the direct sales path for this property | A publisher's in-house ad team using a vendor's tech | | `delegated` | You manage monetization for this property — you're in charge | Mediavine managing a food blog's ad sales | | `ad_network` | You sell this property's inventory as part of a network or exchange — you're a path, not the path | PubMatic as an SSP for nytimes.com | The distinction between `delegated` and `ad_network` matters: a delegated relationship means the operator is in charge of the property's monetization (exclusive or near-exclusive access). An ad\_network relationship means the operator is one of potentially many paths to the inventory. ### Bilateral verification with adagents.json This creates a two-sided verification chain — the same pattern as `sellers.json` + `ads.txt` in programmatic: | File | Who publishes it | What it declares | Programmatic equivalent | | --------------------------- | ---------------- | ------------------------------------------------------------------- | ----------------------- | | `brand.json` (operator) | The network/SSP | "I sell for these publishers, here's how" | `sellers.json` | | `adagents.json` (publisher) | Each publisher | "This operator's agents are authorized, here's the delegation type" | `ads.txt` | Both sides must agree. The network declares the relationship in `brand.json`, and each publisher confirms by authorizing the network's agents with the matching `delegation_type` in their `adagents.json`. If only one side declares, the relationship is incomplete — the network health dashboard flags this as missing authorization (operator declared but publisher hasn't authorized) or orphaned authorization (publisher authorized but operator hasn't declared). ## adagents.json for networks Each publisher in the network authorizes the network's agent in their [`adagents.json`](/docs/governance/property/adagents): ```json theme={null} { "version": "1.0", "properties": [ { "domain": "assistant-alpha.example.com", "agents": [{ "agent_url": "https://ads.ai-network.example.com", "relationship": "direct", "supported_protocols": ["media_buy", "creative"] }] } ] } ``` Each underlying AI platform authorizes the network in its own `adagents.json`. Buyer agents discover the network through the platforms' authorization chains. ## SI Chat Protocol through networks When an ad network sells [SI Chat Protocol](/docs/sponsored-intelligence/si-chat-protocol) sessions on behalf of brands, it acts as an intermediary in the session flow. The brand syncs offerings to the network via `sync_catalogs` with `type: "offering"`, and the network forwards them to underlying platforms. When a platform triggers a session, the network routes it to the correct brand agent. ``` AI Platform -> Network -> Brand Agent 1. Platform calls si_initiate_session with the network's media_buy_id 2. Network maps media_buy_id to the brand's offering_id 3. Network forwards to the brand agent's SI endpoint 4. Brand agent responds; network relays back to the platform ``` The key fields at each leg: | Field | Platform to Network | Network to Brand | | -------------- | --------------------------------- | ------------------------ | | `media_buy_id` | Network's media buy ID | May differ or be omitted | | `offering_id` | Not set (platform doesn't know) | Brand-specific offering | | `intent` | User intent from the conversation | Forwarded as-is | | `identity` | User identity (if consented) | Forwarded as-is | The network handles attribution correlation across the two legs. It knows which platform triggered the session (`placement`), which media buy funded it (`media_buy_id`), and which brand responded (`offering_id`). This lets the network provide unified delivery reporting to buyers via `get_media_buy_delivery` while each brand agent only sees its own sessions. Networks should forward `identity` and `supported_capabilities` unchanged — the brand agent needs accurate host capabilities to negotiate modalities, and the user's consent was granted for the brand, not the network. For the SI Chat Protocol session lifecycle and capability negotiation details, see the [SI Chat Protocol](/docs/sponsored-intelligence/si-chat-protocol) and [implementing SI hosts](/docs/sponsored-intelligence/implementing-si-hosts).