An AIP Operator is any entity that implements the Agentic Intent Protocol. Operators act as the bridge between:

• AI Platforms (who send anonymized intent)
• Brand Agents (who participate via recommendation or delegation)
• The AIP Settlement Layer (which verifies outcomes and settles payments)

Any compliant entity 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

​

High-level flow

1. A Platform submits a PlatformRequest containing user intent to the Operator.
2. The Operator evaluates participation eligibility based on governance rules.
3. The Operator derives a ContextRequest, removing raw user data and enforcing privacy rules.
4. The Operator filters brand agents that match the context and governance constraints.
5. The Operator distributes (broadcasts) the ContextRequest to all matching Brand Agents.
6. Brand Agents evaluate the ContextRequest and submit bids within the auction window.
7. The Operator runs the auction and determines the interaction mode (recommend or delegate).
8. The Operator returns the PlatformResponse (or no_match) to the Platform.
9. Verified events are recorded and settled via the Operator’s settlement system.

The Operator is responsible for enforcing governance, 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 the AIP canonical request format. A PlatformRequest may include:

• Raw user queries or commands
• Conversation state
• Platform session identifiers
• message_id for canonical per-message auction identity
• Platform-specific metadata
• latency_budget_ms - the platform’s latency budget for the auction

​

ContextRequest (brand agent-facing)

ContextRequest uses the AIP canonical context format with enriched fields. A ContextRequest:

• Adds an operator-generated context_id
• Preserves upstream message_id for per-turn traceability
• Removes raw user data
• Removes conversation transcripts
• Removes user identifiers
• Retains only decision-relevant intent signals
• Includes the latency_budget_ms from the PlatformRequest

Operators MUST ensure that Brand Agents receive only ContextRequests.

---

​

Operator role in delegated sessions

In delegated sessions, the Operator remains the governance and audit layer even when live task turns are not fully operator-mediated. In AIP v1.0, the Operator MUST:

• authorize delegated session creation only after explicit platform-confirmed user consent
• enforce the declared handoff scope at session initiation
• ensure the handoff payload excludes raw upstream queries, transcripts, and user identifiers
• maintain session identity and linkage across serve_token, session IDs, and settlement records
• verify delegation_started and task_completed
• track delegated-session liveness from Platform and Brand Agent activity events
• expire delegated sessions when the inactivity timeout elapses

In AIP v1.0, the Operator is not required to inspect every subsequent delegated turn by default. After the operator-mediated start, live task turns may flow directly between the Platform and the Brand Agent while the Operator continues to govern scope, auditability, and settlement. New information provided by the user during the delegated session is session-bound by default. Operators should treat reuse, profiling, training, or future outreach as outside the default delegated-session permission unless separately consented. For delegated sessions, operators should rely on verified session-activity events from both Platforms and Brand Agents to determine whether the session is still active. In v1.0, session_timeout_seconds is the inactivity timeout, not just a wall-clock limit from session start.

---

​

Public Operator ↔ Brand Agent interfaces

Operators expose public protocol endpoints to interact with Brand Agents.

​

Deliver auction requests to brand agents

POST /brand_agents/brand_agent_id/auction Used by the Operator to deliver a ContextRequest to a Brand Agent for auction participation.

• Payload: ContextRequest schema
• Delivery: asynchronous
• Operators MAY apply rate limiting
• Operators MUST respect the auction window

​

Receive responses

POST /aip/bid Used by Brand Agents to submit bid responses.

• Payload: Bid schema
• Responses received after the auction window are ignored
• Each response maps to a single ContextRequest

​

Optional result notification

POST /brand_agents/brand_agent_id/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
• The Operator computes the available response window by subtracting operator overhead
• The auction window begins when the Operator distributes the ContextRequest to matching Brand Agents
• Brand Agents must submit responses before the window expires
• If no latency_budget_ms is provided, the Operator uses a default fallback

If the window closes with no responses, the Operator treats the outcome as no_match.

---

​

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

---

​

What an operator does

Every operator must implement five core functions:

​

1. Receive intent context from platforms

Operators accept anonymized user intent and create an auction context. They must:

• validate payload
• generate a serve_token
• start the auction process
• notify eligible brand agents

​

2. Govern participation eligibility

Before the auction begins, operators evaluate whether commercial participation is appropriate for the given intent:

• Check intent type and governance rules
• Apply operator policy constraints to the declared participation intent
• Enforce participation policies

​

3. Run the auction

Operators run the auction using their chosen mechanism (auction, rules, or hybrid):

• Evaluate brand agent responses
• Apply scoring logic (value, relevance, quality)
• Select the winning agent
• Selection must complete within the timing window

​

4. Determine interaction mode

After the auction, operators decide whether the participation takes the form of:

• Recommend - brand content is integrated into the AI response
• Delegate - session is handed off to the brand agent

The mode is included in the PlatformResponse. When the chosen mode is Delegate, operators must distinguish:

• the scoped operator-mediated handoff that creates the delegated session
• the live delegated task flow that may continue directly between the Platform and Brand Agent afterward

The Operator remains responsible for governance and settlement across both phases.

​

5. Verify outcomes and settle

Operators must verify:

• Exposure shown: platform confirmed the response was surfaced
• Interaction started: user engaged with the recommendation
• Delegation started: operator-mediated delegated session was initiated after platform consent and brand-agent availability confirmation
• Delegation activity: platform or brand-agent signal proves the delegated session is still active
• Delegation expired: operator inactivity timeout or session control ends the delegated session before completion
• Task completed: user completed the target action

All events must resolve to one billable unit per serve_token.

---

​

Operator responsibilities

---

​

Implementing an AIP Operator

To operate an AIP-compatible operator, an implementation MUST support the following:

• PlatformRequest handling - Accept and validate platform-submitted intent
• Participation governance - Evaluate eligibility before the auction
• Selection execution - Evaluate responses within timing constraints
• Interaction mode determination - Decide recommend vs delegate for each auction outcome
• Delegation management - Initiate sessions, scope context, manage consent flow
• Event verification - Verify lifecycle events using AIP event schemas
• Settlement accounting - Track balances, spend, and settlement using deterministic ledger records
• Platform integration support - Support platform integration through the canonical APIs; SDKs or client libraries are optional convenience tooling

AIP defines the schemas, event types, and settlement rules. Each operator defines its own transport, APIs, internal architecture, and optional SDK strategy.

---

​

Why become an operator?

Operators implement the protocol to:

• Govern commercial participation within AI ecosystems
• Process intent from AI platforms
• Manage participation networks
• Maintain transparency through AIP verification
• Support outcome-based settlement
• Enable delegation as a first-class interaction mode

---

​

AdMesh as an operator (reference implementation)

AdMesh implements AIP as one example operator. Its implementation includes:

• Optional platform SDKs for integration
• Backend weave SDKs for server-side integration
• Settlement and ledger systems
• Dashboard interfaces for brands and platforms
• Delegation session management

Platforms may integrate with any compliant operator.

---

​

How to integrate with an operator

Platforms must:

1. Sign up with the operator
2. Get API key
3. Install operator SDK
4. Render results via SDK or weave
5. Handle delegation consent and handoff
6. Post events (participation, interaction, delegation, outcomes)
7. Receive periodic payouts

Brand Agents must:

1. Register with operator
2. Create offers
3. Respond to auction requests
4. Support delegation if applicable
5. Track spend and outcomes