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 defines one shared way for platforms, brand agents, and operators to govern commercial participation and settle outcomes.
Core roles
AIP involves three main actors:
| Role | Description |
|---|
| Platform | Any AI surface that detects user intent and requests commercial participation through an AIP Operator. |
| Brand Agent | A commercial entity’s agent that participates via recommendation or delegation when selected. |
| Operator | Any entity that implements AIP - governs participation eligibility, runs selection, and verifies outcomes. AdMesh is the reference operator. |
Each AIP request moves through these three roles in a predictable flow.
Core primitive: Participation
Participation is the act of a commercial entity being allowed to influence or execute a user’s decision within an AI system.
AIP defines two types of participation:
| Type | What happens | When used |
|---|
| Recommend | Brand contributes to the AI response. No session transfer. | Research, consideration, comparison |
| Delegate | AI hands off the session to a brand agent. User completes a task. | Decision, action, transaction |
This distinction is what separates AIP from traditional advertising. The protocol governs both influence and execution.
Decision lifecycle
Below is the lifecycle of an AIP decision, from intent to settlement:
- User expresses intent inside an AI conversation.
- Platform sends anonymized context to the Operator using a PlatformRequest.
- Operator evaluates participation eligibility.
- If eligible, Operator runs selection (auction or rules).
- Operator determines the interaction mode (recommend or delegate).
- Selected brand agent participates - either contributing to the response or receiving a session handoff.
- User interacts, completes a task, or does nothing.
- Operator verifies the outcome and settles payment.
intent → eligibility → selection → (recommend OR delegate) → outcome → settlement
Decision lifecycle events
AIP tracks four stages of a decision lifecycle.
Only the highest-value event in a lifecycle is billable per serve_token.
| Stage | Event | Meaning |
|---|
| Exposure shown | exposure_shown (CPX) | A commercial response was surfaced to the user |
| Interaction started | interaction_started (CPE or CPC) | User engaged with the recommendation |
| Delegation started | delegation_started | Session handoff was initiated (delegate mode only) |
| Task completed | task_completed (CPA) | User completed a signup, purchase, or other outcome |
A lower event upgrades to a higher one if it occurs.
No event is billed twice.
| Metric | Meaning |
|---|
CPX | Cost per Exposure |
CPE | Cost per Engagement |
CPC | Cost per Click |
CPA | Cost per Action |
Verification and settlement
Every AIP event uses a serve_token that links all downstream actions.
The serve token is generated once per selection outcome and cannot be reused.
This guarantees:
- one verified charge per lifecycle
- no double billing
- consistent upgrade rules (task_completed over interaction_started over exposure_shown)
- deterministic settlement through connected wallets
Settlements use signed ledger records that both platforms and brands can audit.
Transparency and compliance
AIP is designed to be simple and verifiable:
- no personal identifiers required
- every event is signed
- works with any operator that supports the schema
- full audit trail is available to all parties
- the protocol is transport-agnostic and can coexist with other systems