Everything you need to know about AIP — from "what is it?" to "how do I implement it?"
The Agent Intake Protocol (AIP) is an open standard that lets AI agents interact with businesses on behalf of users. Instead of filling out web forms or making phone calls, an agent can discover a business's AIP endpoint, submit structured intake data, and receive a personalized offer — all through a simple JSON API.
Today, AI agents interact with businesses the same way humans do — navigating websites, filling forms, scraping content. There's no standardized way for an agent to say: "I represent a user. Here's their context. What can you offer?" AIP provides that standard channel.
A soft-contract is a structured, non-binding offer from a business in response to an intake submission. Think of it like a personalized quote: it has details, pricing, an expiration date, and terms — but it's not a commitment from either side. The user reviews it, and only if they choose to bind does the relationship begin.
Yes. The protocol is MIT-licensed and free to implement. The AIP Registry is a separate, optional certification service for businesses that want to be discoverable and verified.
AIP was created by Man vs Health to solve a real problem: enabling AI agents to onboard users into health services without scraping, phone trees, or manual form-filling. It's published as an open standard for anyone to adopt.
MCP connects AI models to tools and data sources — it's about giving an LLM the ability to call functions and access context. AIP operates at a higher layer: it's about an agent representing a user in a business intake process. MCP might help an agent use a tool; AIP helps an agent find a service, submit an application, and get an offer back.
Google's A2A protocol enables agents to communicate with each other — peer-to-peer messaging between AI systems. AIP is specifically about the agent-to-business relationship: structured intake, evaluation, and onboarding. A2A could be a transport layer under AIP in some architectures, but they solve different problems.
UCP (Universal Commerce Protocol) and ACP (Agent Commerce Protocol) focus on product commerce — shopping, checkout, payments. AIP focuses on services, not products. The intake process for a healthcare provider, law firm, or SaaS platform is fundamentally different from buying a product. AIP handles the discovery, evaluation, and onboarding; commerce protocols can handle the payment that follows.
Absolutely. AIP is designed as one layer in a stack:
They're complementary, not competing.
Minimal effort. You need:
/.well-known/agent-intake.jsonNo LLM required. No special framework. If you can serve JSON from an HTTP endpoint, you can implement AIP. See the examples for complete implementations in ~100 lines of Node.js.
No. Your intake endpoint is just a regular API. You can use simple business logic, rule-based matching, database lookups, or even return a static offer. The AI is on the agent side — your side just needs to speak JSON.
The AIP Registry at agentintake.io is an optional certification service. It crawls and validates your AIP endpoint, verifies your manifest conforms to the spec, and lists you in a directory that agents can query for discovery. Think of it like an SSL certificate but for your AIP implementation — a trust signal.
Three ways:
yourdomain.com/.well-known/agent-intake.json directly (like robots.txt)No. AIP is privacy-first by design. During the intake phase, agents submit anonymized, categorical data — things like age ranges, zip codes, and preference categories instead of exact values. Personal information (name, email, phone) only flows at the bind stage, after the user has reviewed the offer and explicitly opted in.
Binding is the final, user-initiated step where they accept an offer. Only at this point does the agent share PII (whatever the business declared in bind_requires). The user is always in control — the agent presents the offer, the user decides whether to proceed.
Technically, a manifest can set pii_required: true, but this is discouraged. The spec strongly recommends pii_required: false and redacted_acceptable: true for the intake phase. Agents may skip endpoints that require PII upfront, and the Registry may flag them during certification.
AIP endpoints are standard HTTP APIs, so all normal protections apply — rate limiting, API keys, IP throttling, CAPTCHA for binding, etc. The manifest can also declare requires_auth: true if the endpoint needs authentication. The Registry provides additional trust signals through certification.
Two files:
/.well-known/agent-intake.json) — describes your intakes, their schemas, and privacy policiesThe BMI calculator example is a complete implementation in under 80 lines.
JSON Schema Draft 2020-12. The manifest's input_schema field defines what data the intake endpoint expects, using standard JSON Schema validation. This means agents can validate data before submission and generate UIs dynamically.
Yes. The repo includes a lightweight JavaScript SDK with both client and server helpers. The client handles discovery, submission, and binding. The server provides manifest serving, request validation, and response formatting. See sdk/js/.
Yes. The intakes array in your manifest can contain as many intake definitions as you need. A healthcare provider might offer a metabolic assessment, a sleep evaluation, and a nutrition consultation — each as a separate intake with its own schema, endpoint, and privacy settings.
AIP uses semantic versioning (currently 0.1.0). Spec snapshots live in date-stamped directories (spec/2026-02-27/). Both the manifest and all request/response payloads include an aip_version field for compatibility checking.
This is one of AIP's core strengths. A single manifest can expose multiple intakes, each with its own schema, endpoint, category, and privacy settings — all under one /.well-known/agent-intake.json file.
Consider a health & wellness business that offers four distinct services:
Each of these has different input data, different output offers, and potentially different binding requirements (a medical intake might require more PII at bind than a fitness plan). In AIP, they're all entries in the intakes array:
{
"aip_version": "0.1.0",
"provider": {
"name": "Man vs Health",
"url": "https://manvshealth.com"
},
"intakes": [
{ "id": "medical-consult", "category": "health/medical", ... },
{ "id": "nutrition-plan", "category": "health/nutrition", ... },
{ "id": "fitness-plan", "category": "health/fitness", ... },
{ "id": "jumpstart", "category": "health/coaching", ... }
]
}The agent decides which intake to use based on the user's needs, the intake descriptions, and the input schemas. If someone says "I want to lose weight and fix my blood sugar", the agent might submit to the medical intake. If they say "I need a workout plan", it's the fitness intake. If they're not sure where to start, the jumpstart intake exists exactly for that.
This means a single AIP-enabled business can serve as multiple specialized endpoints without the agent needing to navigate a website, click through a funnel, or guess which form to fill out. The manifest is the menu. The agent picks the right door.
agent-intake.json manifest/.well-known/agent-intake.json on target domainsAIP is open source and we welcome contributions. See CONTRIBUTING.md for guidelines. You can help by implementing AIP for your business, building SDKs in other languages, proposing spec improvements, or sharing feedback via GitHub Issues.
Still have questions?