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 usingpublisher_properties:
Account model for networks
Networks typically use implicit accounts (require_operator_auth: false). The buyer agent is trusted and declares brands via sync_accounts. The network then manages its own accounts with each underlying AI platform:
Catalog forwarding
Networks receive catalogs from buyers viasync_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 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 viaget_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.
adagents.json for networks
A network’sadagents.json lists the publisher properties it represents, even though it doesn’t own them:
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 sessions on behalf of brands, it acts as an intermediary in the session flow. The brand syncs offerings to the network viasync_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.
| 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 |
context | User intent from the conversation | Forwarded as-is |
identity | User identity (if consented) | Forwarded as-is |
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 and implementing SI hosts.