> ## Documentation Index
> Fetch the complete documentation index at: https://agenticintentprotocol.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AIP Operators

> How to implement and operate an AIP-compatible participation operator.

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

| Responsibility                 | Required | Description                                                                                       |
| ------------------------------ | -------- | ------------------------------------------------------------------------------------------------- |
| Context ingestion              | Yes      | Handle PlatformRequests from platforms                                                            |
| Participation governance       | Yes      | Evaluate eligibility based on intent and rules                                                    |
| Auction engine                 | Yes      | Implement auction logic (auction, rules, or hybrid)                                               |
| Interaction mode determination | Yes      | Decide recommend vs delegate                                                                      |
| Event pipeline                 | Yes      | Participation, interaction, delegation, and outcome verification                                  |
| Serve token system             | Yes      | Generate and sign immutable tokens                                                                |
| Settlement accounting          | Yes      | Maintain participant balances                                                                     |
| Settlement and payouts         | Yes      | Periodic platform payments                                                                        |
| Platform SDK                   | Optional | Provide an integration SDK or client library for platforms                                        |
| Delegation management          | Yes      | Authorize session initiation, enforce scope, maintain auditability, and verify delegated outcomes |
| Weave SDK                      | Optional | Provide backend inline-weave SDK                                                                  |
| Reporting dashboard            | Optional | For brands and platforms                                                                          |

***

# 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