Skip to main content

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

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.

3. How it works: three distinct messages

You have three distinct messages. Do not blur them.
MessageDirectionPurpose
A. PlatformRequestPlatform → Operator”Here is the user context + my declared intent + my constraints.” Platform-asserted; Operator validates and uses for participation governance.
B. ContextRequestOperator → Brand Agents”Here is the eligible participation context you may respond to.” Operator-generated and trusted by brand agents. Eligibility already decided.
C. PlatformResponseOperator → Platform”Here is the selected agent + interaction mode + metadata.”

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)
  • 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

IdentifierPurpose
platform_idAI Platform
agent_idBrand Agent
operator_idOperator
wallet_idSettlement
session_idUser session
message_idCanonical message-turn identifier used for auction identity
context_idOperator-generated auction identifier derived from (session_id, message_id)
response_idOperator response
auction_idAuction process
bid_idBrand agent response
serve_tokenParticipation → 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 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.