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

# Agentic Intent Protocol Overview

> Understand AIP message flow, identifiers, PlatformRequest, ContextRequest, PlatformResponse, and how AI platforms connect to operators and brand agents.

# Agentic Intent Protocol (AIP)

AIP defines a common language for how **AI Platforms**, **Operators**, and **Brand Agents** communicate.
It ensures every request, selection, and outcome is traceable, secure, and verifiable.

For IAB-aligned content classification, use the canonical IAB Content Taxonomy 3.1 TSV:
[IAB Content Taxonomy 3.1 TSV](https://github.com/InteractiveAdvertisingBureau/Taxonomies/blob/develop/Content%20Taxonomies/Content%20Taxonomy%203.1.tsv)

## 1. TL;DR

> AIP is the governance and execution layer between AI decisions and real-world actions. It defines how intent is captured, how participation is governed, how agents are selected, and how outcomes are settled.

## 2. Why it matters

Without a shared standard, each platform and commercial entity would need separate integrations.
AIP replaces that fragmentation with one protocol that guarantees:

* Predictable message formats
* Cryptographically signed requests
* End-to-end tracking from participation to outcome
* Clear separation between recommendation and delegation

This creates **trust** and **interoperability** across the commercial participation ecosystem.

For downstream commerce execution after recommendation or delegation, see [Universal Commerce Protocol Integration](/commerce-ucp).

## 3. How it works: three distinct messages

You have **three distinct messages**. Do not blur them.

| Message                 | Direction               | Purpose                                                                                                                                               |
| ----------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A. PlatformRequest**  | Platform → Operator     | "Here is the user context + my declared intent + my constraints." **Platform-asserted**; Operator validates and uses for participation governance.    |
| **B. ContextRequest**   | Operator → Brand Agents | "Here is the eligible participation context you may respond to." **Operator-generated** and **trusted by brand agents**. Eligibility already decided. |
| **C. PlatformResponse** | Operator → Platform     | "Here is the selected agent + interaction mode + metadata."                                                                                           |

```mermaid theme={null}
sequenceDiagram
  participant Platform
  participant Operator
  participant BrandAgent

  Platform->>Operator: A. PlatformRequest (context + intent + constraints)
  Operator->>Operator: Validate; check participation eligibility; derive ContextRequest
  Operator->>BrandAgent: B. ContextRequest (eligible participation context)
  BrandAgent->>Operator: Response (bid or recommendation)
  Operator->>Operator: Run selection; determine interaction mode
  Operator->>Platform: C. PlatformResponse (selected agent + mode + metadata)
  Platform->>Operator: exposure_shown / interaction_started
  Operator->>Operator: delegation_started
  BrandAgent->>Operator: task_completed
```

### 3.1 PlatformRequest (Platform → Operator)

Sent by the AI platform. The canonical request envelope carries:

* `message_id` for canonical per-message auction identity

### 3.2 ContextRequest (Operator → Brand Agents)

Operator-enriched, operator-trusted, and (eventually) operator-signed. Answers: "Given a valid, eligible platform request, here is the participation context you may respond to." Intent in ContextRequest is **operator-generated** and used for **brand response decisions**; it can differ from PlatformRequest intent (which is for governance only).

### 3.3 PlatformResponse (Operator → Platform)

The outcome of the selection process. Contains:

* The selected brand agent
* The interaction mode (recommend or delegate)
* Format-specific content for recommend mode
* A delegation object for delegate mode (see [Delegation Protocol](/delegation))
* A `serve_token` for event tracking

### 3.4 Authoritative flow (lock this)

1. Platform builds **PlatformRequest** (context + explicit intent + runtime + selection parameters).
2. Operator validates signature and request integrity; evaluates **participation eligibility**.
3. If eligible, Operator generates **ContextRequest**.
4. ContextRequest is sent to Brand Agents.
5. Brand Agents return **responses** (bids, recommendations, or delegation offers).
6. Operator runs **selection** and determines **interaction mode**.
7. Operator sends **PlatformResponse** to platform.

Each step has **one owner**. No overlap.

## 4. Transport and Security

All messages use HTTPS or gRPC.
Requests include secure headers:

```
X-AIP-Signature: HMAC(method + path + body + timestamp + nonce)
X-AIP-Version: 1.0
```

## 5. Identifiers

| Identifier   | Purpose                                                                       |
| ------------ | ----------------------------------------------------------------------------- |
| platform\_id | AI Platform                                                                   |
| agent\_id    | Brand Agent                                                                   |
| operator\_id | Operator                                                                      |
| wallet\_id   | Settlement                                                                    |
| session\_id  | User session                                                                  |
| message\_id  | Canonical message-turn identifier used for auction identity                   |
| context\_id  | Operator-generated auction identifier derived from `(session_id, message_id)` |
| response\_id | Operator response                                                             |
| auction\_id  | Auction process                                                               |
| bid\_id      | Brand agent response                                                          |
| serve\_token | Participation → interaction → delegation → outcome                            |

## 6. Example flow

**Recommend mode:**

1. User asks: "Best project management tool?"
2. Platform sends PlatformRequest.
3. Operator evaluates eligibility  -  participation allowed.
4. Operator derives ContextRequest and sends to brand agents.
5. Brand agents respond.
6. Operator runs selection, determines recommend mode.
7. Platform receives PlatformResponse and renders recommendation.
8. Events logged under serve\_token.

**Delegate mode:**

1. User says: "Set up a Trello board for my team."
2. Platform sends PlatformRequest with transactional intent.
3. Operator evaluates eligibility  -  delegation allowed.
4. Operator runs selection  -  Trello agent selected.
5. Platform receives PlatformResponse with delegation object.
6. Platform asks user for consent.
7. User consents and the Platform relays that consent to the Operator.
8. Operator confirms Trello agent availability, initiates the delegated session, and records `delegation_started`.
9. User completes setup. Trello agent fires `task_completed`.
10. Operator verifies and settles.

If the delegated task becomes a real commerce flow, the Brand Agent or Platform can hand off into [Universal Commerce Protocol Integration](/commerce-ucp) while preserving AIP attribution and settlement identifiers.

## 7. Guarantees

* Signed, timestamped messages
* No serve-token collisions
* Independent verification
* Safe version upgrades
* Clear separation of governance, selection, and execution

## Summary

> AIP provides the transport, identifiers, and verification layer for governed commercial participation in AI systems  -  from intent detection through selection, delegation, and outcome-based settlement.