Skip to main content
An AIP operator is any ad network that implements the Agentic Intent Protocol.
Operators act as the bridge between:
  • AI Platforms (who send anonymized intent)
  • Brand Agents (who bid on that intent)
  • The AIP Ledger (which verifies exposure, click, and conversion events)
Any compliant ad network can implement AIP and operate as an operator. AdMesh provides one example implementation. This page explains how operators work, what they must implement, and how others can integrate with them.

​
How Operators and Brand Agents Work Together

This section describes the public interaction flow between AIP Operators and Brand Agents. It defines the protocol-level responsibilities of the Operator without prescribing internal architecture.

​
High-level flow

  1. A Platform submits a PlatformRequest containing user intent to the Operator.
  2. The Operator derives a ContextRequest, removing raw user data and enforcing privacy rules.
  3. The Operator classifies the ContextRequest into one or more category pools.
  4. The Operator publishes the ContextRequest to subscribed Brand Agents.
  5. Brand Agents evaluate the ContextRequest and submit bids within the auction window.
  6. The Operator evaluates bids according to AIP auction rules.
  7. The Operator returns the winning recommendation (or no_bid) to the Platform.
  8. Verified events are recorded and settled via the Operator ledger.
The Operator is responsible for enforcing timing, verification, and settlement guarantees.

​
From PlatformRequest to ContextRequest

Operators receive PlatformRequests from Platforms. These requests may contain full interaction context required for intent understanding. Before distributing requests to Brand Agents, Operators MUST derive a ContextRequest.

​
PlatformRequest (Operator-facing)

PlatformRequest uses UCP (User Context Protocol) format with nested structure (spec_version, message_id, producer, context, identity, extensions). A PlatformRequest may include:
  • Raw user queries or commands
  • Conversation state
  • Platform session identifiers
  • Platform-specific metadata
  • latency_budget_ms - the platform’s latency budget for the auction

​
ContextRequest (Brand Agent-facing)

ContextRequest uses a UCP-like format with enriched context for brand agents. A ContextRequest:
  • Removes raw user data
  • Removes conversation transcripts
  • Removes user identifiers
  • Retains only decision-relevant intent signals
  • Includes the latency_budget_ms from the PlatformRequest (for timing calculations)
Operators MUST ensure that Brand Agents receive only ContextRequests. This conversion enforces privacy while enabling effective bidding.

​
Public Operator ↔ Brand Agent Interfaces

Operators expose public protocol endpoints to interact with Brand Agents. These interfaces define the external contract and do not constrain internal systems.

​
Deliver auction requests to Brand Agents

POST /brand_agents//auction Used by the Operator to deliver a ContextRequest to a Brand Agent.
  • Payload: ContextRequest schema
  • Delivery: asynchronous
  • Operators MAY apply rate limiting
  • Operators MUST respect the auction window

​
Receive bid responses

POST /aip/bid-response Used by Brand Agents to submit BidResponses.
  • Payload: BidResponse schema
  • Responses received after the auction window are ignored
  • Each response maps to a single ContextRequest

​
Optional auction result notification

POST /brand_agents//auction_result Operators MAY notify Brand Agents of win or loss outcomes for transparency or optimization.

​
Auction Window and Timing

AIP uses a time-bounded auction window to ensure low latency and predictable outcomes.
  • The auction window is determined by the platform’s latency_budget_ms field in the PlatformRequest
  • The Operator computes the available bid window by subtracting operator overhead (embedding generation, search, filtering, dispatch) from the platform’s latency budget
  • The window begins when the Operator publishes the ContextRequest
  • Brand Agents must submit a BidResponse before the computed window expires
  • If no latency_budget_ms is provided, the Operator uses a default fallback
If the auction window closes before a bid is received, the Operator treats the outcome as no_bid. Late responses are ignored and do not participate in selection or settlement.

​
Operator Privacy Responsibilities

Operators are the privacy boundary within AIP. Operators MUST:
  • Accept full PlatformRequests from Platforms
  • Derive privacy-preserving ContextRequests
  • Prevent Brand Agents from accessing raw user data
  • Enforce schema-level data minimization
Brand Agents MUST NOT receive:
  • Raw user queries
  • Conversation history
  • User or account identifiers
This separation ensures compliance, auditability, and user trust.

​
Relationship to Brand Agents

Operators define the auction, verification, and settlement rules. Brand Agents define bidding strategy and pricing. Both roles interact exclusively through AIP-defined schemas and public protocol interfaces.

​
What an Operator Does

Every operator must implement five core functions:

​
1. Receive ContextRequests from Platforms

Operators accept anonymized user intent and create an Auction Context. They must:
  • validate payload
  • generate a serveToken
  • start or join an auction cycle
  • notify bidders (Brand Agents)

​
2. Run AIP Auctions

Operators run a real-time auction using AIP rules:
  • CPA outranks CPC
  • CPC outranks CPX
  • CPA and CPC bids must include budgets
  • Winning bid must be returned within operator-defined latency

​
3. Deliver AuctionResults

Operators send the winning recommendation back to the platform. This includes:
  • product data
  • click URL (signed)
  • serveToken
  • billing model (CPX, CPC, CPA)

​
4. Verify Events (CPX, CPC, CPA)

Operators must verify:
  • Exposure: fired when UI SDK renders result
  • Click: via signed click redirect
  • Conversion: via advertiser callback or partner API
All events must resolve to one billable unit per serveToken.

​
5. Maintain Wallets & Monthly Settlement

Operators:
  • track advertiser balances
  • track spend per serveToken
  • maintain signed ledger entries
  • generate monthly payouts to AI platforms
AIP defines the rules. Operators implement them.

​
Operator Responsibilities

ResponsibilityRequiredDescription
Context ingestionYesHandle ContextRequests from platforms
Auction engineYesImplement CPA > CPC > CPX logic
Event pipelineYesExposure, click, and conversion validation
Serve token systemYesGenerate and sign immutable tokens
Wallet accountingYesMaintain advertiser balances
Ledger & payoutsYesMonthly platform payments
UI SDKYesProvide a frontend SDK for platforms
Weave SDKOptionalProvide backend inline-weave SDK
Reporting dashboardOptionalFor advertisers and platforms

​
Example Operator SDKs (Informational)

An AIP operator may publish one or more SDKs. The following SDK names are illustrative examples from one implementation: AdMesh (example implementation) provides:

​
1. UI SDK (required for platforms)

npm install admesh-ui-sdk
Used for:
  • rendering results
  • exposure tracking
  • click tracking
  • fallback logic
  • session ID + message ID tracking

​
2. Backend Weave SDK (optional)

Node.js: 
npm install @admesh/weave-node
Python: 
pip install admesh-weave-python
Used for:
  • fetching recommendations server-side
  • feeding the LLM for inline weaving
  • reducing follow-up fetches

​
Operator Architecture (High-Level)

AI Platform (Frontend)
   → UI SDK
   → ContextRequest
   → AuctionResult render
   → Exposure/Click events

Brand Agents
   → Bid on auctions
   → Provide CPA/CPC/CPX values

Operator (You)
   → Context ingestion
   → Auction engine
   → Event verification
   → Wallet + ledger
   → Monthly payouts

​
Implementing an AIP Operator

To operate an AIP-compatible operator, an implementation MUST support the following protocol surfaces and responsibilities:
  • ContextRequest handling Accept and validate platform-submitted intent using the AIP ContextRequest schema.
  • Auction execution Evaluate bids according to AIP auction rules (CPA > CPC > CPX) within an operator-defined auction window.
  • Bid submission handling Accept signed bid responses from brand agents using the AIP bid schema.
  • Event verification Verify exposure, click, and conversion events using AIP event schemas.
  • Wallet and ledger accounting Track balances, spend, and settlement using deterministic ledger records.
  • Platform rendering support Provide a UI SDK or equivalent mechanism for rendering and exposure tracking.
  • Click handling Support signed click redirection and attribution resolution.
  • Authentication and authorization Authenticate platforms and advertisers using operator-defined mechanisms consistent with AIP requirements.
AIP defines the schemas, event units, and settlement rules. Each operator defines its own transport, APIs, and internal architecture.

​
Why Become an Operator?

Operators implement the protocol to:
  • Operate an ad marketplace within their ecosystem
  • Process intent from AI platforms
  • Manage advertiser marketplaces
  • Maintain transparency through AIP verification
  • Support performance-based bidding by brand agents
  • Handle multiple billing models (CPX, CPC, CPA)

​
AdMesh as an Operator (Reference Implementation)

AdMesh implements AIP as one example operator. Its implementation includes:
  • UI SDK for platform integration
  • Backend Weave SDKs for server-side integration
  • Wallet and ledger systems
  • Dashboard interfaces for advertisers and platforms
Platforms may integrate with any compliant operator.

​
How to Integrate an Operator

Platforms must:
  1. Sign up with the operator
  2. Get API key
  3. Install operator UI SDK
  4. Render results via UI SDK or Weave
  5. Post events (exposures, clicks)
  6. Receive monthly payouts
Brand Agents must:
  1. Register with operator
  2. Create offers
  3. Bid programmatically
  4. Track spend
  5. Track conversions

​
Unified SDK Direction (In Progress)

AIP is designed with a “single SDK” integration approach in mind. A reference SDK is in progress to support platforms, operators, and brand agents through a shared implementation of AIP schemas, event handling, and verification logic. This SDK will be optional and intended to reduce integration complexity, not to constrain operator implementations.