AIP Specification

Version 0.1.0 · Snapshot 2026-02-27 · Status: Draft

Overview

The Agent Intake Protocol (AIP) defines a standard interface for AI agents to discover, submit intake data to, and receive structured offers from business service endpoints. This document is the authoritative technical specification.

Terminology

Protocol Lifecycle

Stage 1: Discover

The agent sends an HTTP GET request to the provider's well-known path:

GET https://{domain}/.well-known/agent-intake.json
Accept: application/json

The provider MUST respond with a valid manifest (see Manifest Schema) and Content-Type: application/json.

Requirements:

• The path MUST be /.well-known/agent-intake.json per RFC 8615.
• The response MUST be valid JSON conforming to the manifest schema.
• CORS headers SHOULD be set to allow cross-origin agent access.
• HTTPS is REQUIRED for production endpoints. HTTP is acceptable for local development only.

Stage 2: Submit

The agent constructs an intake request and POSTs it to the intake endpoint specified in the manifest:

POST {intake.endpoint}
Content-Type: application/json

{
  "aip_version": "0.1.0",
  "agent": {
    "id": "agent-instance-id",
    "platform": "anthropic",
    "consent_scope": ["intake", "offer"]
  },
  "intake_data": {
    // Fields conforming to intake.input_schema
  },
  "session_id": "uuid-v4"
}

Requirements:

• The intake_data object MUST conform to the input_schema declared in the manifest.
• The session_id MUST be a UUID v4, generated by the agent.
• The consent_scope array MUST include at least "intake".
• The agent SHOULD NOT include PII in intake_data unless the manifest's privacy.pii_required is true.

Stage 3: Offer

The provider processes the intake and returns a soft-contract offer:

{
  "aip_version": "0.1.0",
  "session_id": "uuid-v4",
  "status": "offer",
  "offer": {
    "id": "offer-uuid",
    "summary": "Human-readable summary for the user.",
    "details": { /* structured offer data */ },
    "expires": "2026-03-06T00:00:00Z",
    "bind_endpoint": "https://provider.com/api/aip/bind",
    "bind_requires": ["email", "full_name"]
  }
}

Response status codes:

• 200 — Successful response (status may be offer, declined, or pending).
• 400 — Invalid request (malformed JSON, schema mismatch).
• 429 — Rate limited.
• 500 — Server error.

Response statuses:

Stage 4: Review

The review stage is handled entirely by the agent. The protocol does not define message formats for this stage. The agent presents the offer(s) to the user and facilitates decision-making.

Stage 5: Bind

If the user accepts an offer, the agent sends a bind request:

POST {offer.bind_endpoint}
Content-Type: application/json

{
  "offer_id": "offer-uuid",
  "session_id": "uuid-v4",
  "bind_data": {
    "email": "user@example.com",
    "full_name": "Jane Doe"
  },
  "agent": {
    "id": "agent-instance-id",
    "consent_scope": ["intake", "offer", "bind"]
  }
}

Requirements:

• The bind_data MUST include all fields listed in the offer's bind_requires array.
• The consent_scope MUST include "bind".
• The agent MUST have received explicit user authorization before sending PII.
• The offer_id and session_id MUST match the original offer.

JSON Schemas

All schemas use JSON Schema Draft 2020-12. The canonical schema files are in the spec/2026-02-27/ directory.

Manifest Schema: agent-intake.json

The manifest is served at /.well-known/agent-intake.json and describes the provider and available intakes.

Top-level fields

Provider object

Intake object

Full example

{
  "aip_version": "0.1.0",
  "provider": {
    "name": "Man vs Health",
    "url": "https://manvshealth.com",
    "description": "Men's metabolic health optimization"
  },
  "intakes": [
    {
      "id": "metabolic-assessment",
      "name": "Metabolic Health Assessment",
      "description": "Submit metabolic markers for a personalized plan.",
      "endpoint": "https://manvshealth.com/api/aip/metabolic-assessment",
      "method": "POST",
      "category": "health/assessment",
      "input_schema": {
        "type": "object",
        "required": ["age_range", "sex", "primary_concern"],
        "properties": {
          "age_range": {
            "type": "string",
            "enum": ["30-39", "40-49", "50-59", "60+"]
          },
          "sex": {
            "type": "string",
            "enum": ["male", "female"]
          },
          "primary_concern": {
            "type": "string",
            "enum": ["weight", "energy", "insulin_resistance", "general"]
          },
          "fasting_glucose_range": {
            "type": "string",
            "enum": ["normal", "elevated", "high", "unknown"]
          },
          "activity_level": {
            "type": "string",
            "enum": ["sedentary", "light", "moderate", "active"]
          }
        }
      },
      "offer_type": "personalized_recommendation",
      "binding_available": true,
      "requires_auth": false,
      "privacy": {
        "data_retention": "none",
        "pii_required": false,
        "redacted_acceptable": true
      }
    }
  ],
  "certification": {
    "registry": "https://agentintake.io/registry",
    "certified": true,
    "cert_id": "aip-cert-2026-00142",
    "expires": "2027-02-27"
  }
}

Intake Request Schema

Agent object

Offer Response Schema

Offer object

Bind Request Schema

Common bind_data fields

Error Codes

{
  "aip_version": "0.1.0",
  "session_id": "uuid-v4",
  "status": "error",
  "error": {
    "code": "SCHEMA_MISMATCH",
    "message": "Missing required field: age_range"
  }
}

Transport Requirements

• Protocol: HTTPS required in production. HTTP allowed for localhost development.
• Content-Type: All requests and responses MUST use application/json.
• CORS: Providers SHOULD set Access-Control-Allow-Origin: * and handle OPTIONS preflight requests.
• Encoding: UTF-8.
• Request size: Providers SHOULD accept request bodies up to 64 KB.
• Response time: Providers SHOULD respond within 10 seconds. For longer processing, use status: "pending".

Standard Categories

Categories follow the pattern {domain}/{type}:

Providers MAY use custom categories following the same {domain}/{type} pattern.

Versioning

• Semantic versioning: The aip_version field uses semver (e.g., 0.1.0).
• Date snapshots: Schema files are organized by date (e.g., spec/2026-02-27/).
• Breaking changes increment the minor version and create a new date directory.
• Agents SHOULD check the aip_version in manifests and responses to ensure compatibility.
• Providers SHOULD include aip_version in all responses.

Security Considerations

• HTTPS: All production endpoints MUST use HTTPS.
• Input validation: Providers MUST validate intake_data against their declared input_schema.
• Rate limiting: Providers SHOULD implement rate limiting and declare limits in the manifest.
• PII handling: PII received during binding MUST be handled in accordance with applicable privacy regulations.
• Offer expiration: Providers SHOULD enforce offer expiration to prevent stale bindings.
• Agent verification: The current spec does not mandate agent authentication. Future versions may integrate with identity protocols like AGNTCY.