AIP: The Agent Intake Protocol

A Lightweight Open Standard for Agent-Mediated Service Onboarding

Version 0.1.0 · February 27, 2026
Published by the Agent Intake Protocol Contributors · MIT License

1. Abstract

The Agent Intake Protocol (AIP) is an open, lightweight protocol that enables AI agents — acting as delegates on behalf of human users — to discover, interact with, and initiate relationships with business service endpoints. AIP defines a five-stage lifecycle: Discover, Submit, Offer, Review, and Bind.

At its core, AIP introduces the concept of a soft-contract: a structured, non-binding offer returned by a business in response to an agent's intake submission. The agent carries this offer back to the user, who evaluates it, compares it against competing offers, and decides whether to bind — converting the soft-contract into an active relationship.

AIP is designed to complement existing protocols in the AI agent ecosystem, including MCP (tool/data integration), A2A (agent-to-agent communication), UCP (product commerce), and ACP (agentic checkout). It fills the unaddressed gap of agent-mediated service relationships — the process by which an agent helps a user find, evaluate, and onboard with a service provider.

The protocol is intentionally simple. A business can implement AIP by publishing a single JSON manifest and handling one API endpoint. No LLM, no agent runtime, no complex infrastructure. This low barrier to entry is a deliberate design choice aimed at accelerating adoption across the entire economy — from solo practitioners to enterprise SaaS platforms.

2. The Problem: Agents Without a Front Door

Every business has an intake process. A healthcare provider has patient intake forms. A SaaS company has onboarding wizards. A service marketplace has job posting flows. An insurance company has quote request forms. These processes were designed for humans: graphical interfaces, multi-step wizards, phone calls, and email chains.

AI agents today can browse the web, but when they attempt to engage with businesses on behalf of users, they face a fundamental problem: there is no standardized, machine-readable interface for initiating a service relationship.

What Agents Do Today

When a user asks their AI agent to "find me a health coach for insulin resistance" or "get quotes from local plumbers," the agent has limited options:

• Web search and summarization — The agent searches the web, reads marketing pages, and summarizes what it finds. The user gets information, but no structured offer or actionable next step.
• Browser automation — The agent attempts to fill out web forms programmatically. This is fragile, breaks frequently, and is often blocked by anti-bot protections. The business treats the interaction as suspicious.
• Referral to the user — The agent gives up and says "You'll need to visit their website and fill out the form." The user is back to the manual process the agent was supposed to streamline.

None of these approaches result in a structured, reliable, privacy-respecting interaction between the agent and the business. The fundamental problem is that businesses have no front door for AI agents.

The Cost of the Gap

This gap has real costs for every party involved:

• For users: Agents can't fully act on their behalf. The promise of AI delegation falls short at the moment it matters most — when the user wants to actually engage with a service.
• For businesses: They miss leads from the fastest-growing interaction channel in computing history. As AI agents become the primary interface through which consumers discover and engage with services, businesses without an agent-facing interface will be invisible.
• For agent developers: They can integrate tools (via MCP) and communicate with other agents (via A2A), but they cannot reliably initiate a service relationship on behalf of a user. This limits the value they can deliver.

Every business will eventually need an agent-facing intake endpoint, just as every business eventually needed a website, and then a mobile-friendly website, and then an API. AIP is the standard that makes this transition structured and interoperable.

3. Existing Protocols and the Gap They Leave

The AI agent ecosystem has seen remarkable protocol development since 2024. Several major protocols have been published by industry leaders, each addressing a specific layer of agent interaction. However, none of them address the intake and service relationship layer.

MCP: Tools, Not Relationships

The Model Context Protocol (MCP), originally published by Anthropic in November 2024 and now under the Linux Foundation's AI & Agent Framework (AAIF), is the foundational protocol for connecting AI models to external tools and data sources. MCP defines a standardized interface through which agents can discover and invoke tools — reading files, querying databases, calling APIs.

MCP is infrastructure. It tells an agent how to connect to a system. It does not address what an agent should submit to initiate a relationship with a business, or how a business should respond with a structured offer. An MCP server might expose a "get_product_info" tool, but there is no concept of intake, offer, or binding.

Relationship to AIP: AIP is complementary to MCP. An agent could use MCP to connect to tools, and use AIP to initiate service relationships. In fact, an MCP server could include AIP endpoints as tools, allowing agents to discover and interact with AIP manifests through their existing MCP infrastructure.

A2A: Peers, Not Delegates

Agent2Agent (A2A), published by Google in April 2025 and now under the Linux Foundation, enables agent-to-agent communication. Agents publish "Agent Cards" at /.well-known/agent-card.json that describe their capabilities, and other agents can discover and interact with them through standardized messaging.

A2A is peer-to-peer. It assumes both sides of the interaction are autonomous agents. This is valuable for multi-agent collaboration, but it doesn't address the fundamentally asymmetric interaction of agent-on-behalf-of-human to business-endpoint. In AIP, the agent is a delegate, not a peer. The business endpoint is not an agent — it's a service provider with an intake process.

Relationship to AIP: A2A and AIP serve different interaction patterns. A2A enables agent-to-agent coordination (e.g., a travel agent talking to a booking agent). AIP enables agent-to-business intake (e.g., an agent submitting a health assessment on behalf of a user). A sophisticated agent might use A2A to coordinate with other agents about which AIP endpoints to query.

UCP/ACP: Products, Not Services

The Universal Commerce Protocol (UCP), announced by Google with Shopify and over 20 partners in January 2026, standardizes the product commerce journey — discovery, checkout, and payment. Businesses publish product catalogs at /.well-known/ucp, and agents can browse, compare, and purchase products.

The Agentic Commerce Protocol (ACP), published by OpenAI with Stripe in September 2025, enables AI agents to complete purchases, first implemented in ChatGPT's Instant Checkout feature.

Both protocols are product-centric and transaction-centric. They assume the interaction is a purchase: the agent selects a product, pays for it, and the transaction is complete. This model works for e-commerce, but it doesn't apply to services where:

• The "product" is personalized based on intake data (not selected from a catalog)
• The business needs to evaluate the user's situation before making an offer
• No money changes hands at the offer stage
• The user wants to compare multiple service offers before committing
• The "purchase" is the beginning of a relationship, not the end of a transaction

Relationship to AIP: UCP/ACP handle what happens after a user has decided to buy. AIP handles what happens before — the discovery, evaluation, and comparison phase. For services that eventually involve payment, AIP's bind stage could hand off to UCP/ACP for the actual transaction. AIP is the relationship initiation layer; UCP/ACP is the transaction layer.

The Gap

AIP fills the gap between tool-level integration (MCP) and transaction-level commerce (UCP/ACP). It is the relationship initiation layer of the agent protocol stack.

4. Introducing AIP

The Agent Intake Protocol is designed around five core concepts that together define a complete, privacy-respecting lifecycle for agent-mediated service intake.

Core Concepts

Discovery

Businesses publish an AIP manifest at the well-known path /.well-known/agent-intake.json, following the convention established by A2A (agent-card.json) and UCP, and standardized by RFC 8615. The manifest describes the provider, lists available intakes with their input schemas, and declares privacy and certification information.

This approach provides zero-configuration discovery. An agent that knows a domain can immediately check for AIP support, just as a browser checks for /.well-known/security.txt or a federation server checks for /.well-known/webfinger.

Submit

The agent constructs a structured payload conforming to the intake's declared input_schema and POSTs it to the intake endpoint. The submission includes the agent's identifier, the user's consent scope, and a session ID for correlation.

Critically, intake submissions use anonymized, redacted, or range-based data. A health assessment might accept an age range ("40-49") rather than a birth date. A service request might accept a zip code rather than a street address. This privacy-by-default design means the business receives enough context to generate a meaningful offer, without receiving any personally identifiable information.

Offer (The Soft-Contract)

The soft-contract is AIP's central primitive. When a business receives an intake submission, it returns a structured, non-binding offer. This offer includes:

• A human-readable summary the agent can present to the user
• Structured details (pricing, plans, recommendations, matched providers, calculated results)
• An expiration date
• A bind endpoint and list of required fields for binding (if applicable)

The soft-contract is explicitly non-binding. Neither party is committed. The user can review multiple offers from multiple providers, take time to decide, and ultimately accept or let the offer expire. This mirrors the real-world dynamics of service evaluation, where a quote or proposal is not a contract until both parties agree.

Review

The review stage is agent-side and user-facing. The agent takes the offer (or multiple offers from multiple providers) and presents them to the user. The agent may summarize, compare, recommend, or simply display the offers. The protocol does not prescribe how the agent presents offers — this is where the agent's intelligence and UX add value.

Bind

If the user decides to accept an offer, they authorize the agent to bind. The agent POSTs to the offer's bind_endpoint with the required PII (email, name, etc.). This is the only stage where personally identifiable information is shared, and it happens only with the user's explicit authorization.

Not all intakes support binding. A BMI calculator, for example, returns a computed result and that's the end of the interaction (binding_available: false). The protocol supports both binding and non-binding use cases.

The Soft-Contract Primitive

The soft-contract is the defining concept of AIP. It draws inspiration from several real-world patterns:

• Insurance quotes — You provide information about your coverage needs, and the insurer returns a quote. The quote is not a policy. You can compare quotes and choose.
• Service estimates — A contractor visits your home, evaluates the work, and gives you an estimate. The estimate is not a contract. You can get multiple estimates.
• SaaS trial offers — You describe your team's needs, and the platform recommends a plan with a free trial. You haven't committed yet.
• Medical intake — You fill out a health questionnaire, and the provider recommends a care path. You haven't booked an appointment yet.

All of these are examples of soft-contracts: structured responses to intake data that propose a path forward without requiring immediate commitment. AIP standardizes this pattern for AI agents.

Privacy by Default

AIP's privacy model is simple and strict:

• At intake: No PII. The manifest's input_schema defines what data is needed, and it should use ranges, categories, and anonymized values. The privacy block declares data retention and PII policies.
• At binding: Minimum necessary PII. The offer's bind_requires array explicitly lists what personal data is needed (typically email and name). The user must authorize sharing.
• Between intake and binding: The user reviews the offer with full knowledge of what PII will be shared if they choose to bind.

This two-phase approach means users can "shop around" with complete privacy, only revealing their identity when they've made a decision.

5. Protocol Specification

The full technical specification, including JSON Schemas for all message types, is available on the Specification page. This section provides a summary.

Message Types

Transport

AIP uses standard HTTP/HTTPS. Discovery is a GET request. All other interactions are POST requests with JSON payloads. There are no WebSocket connections, no streaming requirements, and no special headers beyond standard Content-Type: application/json.

Versioning

AIP uses dual versioning: semantic versioning (0.1.0) for the protocol version, and date-based snapshots (2026-02-27) for schema directories. Every message includes an aip_version field. Backwards-incompatible changes increment the minor version and create a new date directory.

6. Use Cases

AIP is intentionally domain-agnostic. Any business with an intake process can implement it. The following categories illustrate the breadth of application.

B2C: Consumer Services

Health & Wellness

A metabolic health platform like Man vs Health can publish an AIP manifest that accepts age range, health concerns, glucose levels, and activity data. The business returns a personalized coaching plan recommendation with pricing. The user's agent can query multiple health platforms, compare plans, and present the best options.

This replaces the current flow where a user would need to visit each health platform's website, fill out separate intake forms, wait for emails, and manually compare options.

Financial Services

An insurance company can publish an intake that accepts age range, coverage type, and asset estimates. The response is a structured quote with premium, deductible, and coverage details. Agents can query multiple insurers simultaneously and present a comparison table to the user.

Education

An online learning platform can accept skill level, goals, and schedule preferences, returning a recommended curriculum with pricing and time commitment estimates.

B2B: Business Services

SaaS Onboarding

A project management tool like TaskFlow can publish an intake that accepts team size, use case, current tools, and integration needs. The response includes a recommended plan with a pre-configured trial workspace, complete with templates and integrations relevant to the team's use case.

This transforms SaaS evaluation from a multi-day process (sign up for trials, configure each one, compare) into a single agent-mediated flow where the user gets pre-configured trials from multiple vendors, ready to compare.

Vendor Evaluation

A cloud hosting provider can accept estimated usage, compliance requirements, and technology stack preferences, returning a tailored proposal with pricing tiers and SLA guarantees.

Matching: Service Marketplaces

A service marketplace like WhoDo can publish an intake that accepts service type, location, urgency, and budget range. The response includes a list of matched providers with ratings, reviews, experience, and estimated pricing. The user reviews the matches and binds to connect with their preferred provider.

This is particularly powerful because AIP naturally supports the marketplace model: the business (marketplace) acts as an intermediary, returning multiple options in a single offer. The agent can also query competing marketplaces and aggregate results.

Calculators & Tools

Not all intakes require binding. A BMI calculator, mortgage calculator, or ROI estimator can implement AIP with binding_available: false. The agent submits input data, receives a computed result, and presents it to the user. No account creation, no follow-up, no PII.

This use case demonstrates AIP's flexibility. The protocol isn't just for service relationships — it's for any structured agent-to-business interaction that benefits from a standardized interface.

7. Implementation Guide

For Businesses: Adding AIP to Your Site

Implementing AIP is deliberately simple. Here's what you need:

1. Create your manifest — Define your intakes with input schemas in agent-intake.json.
2. Serve it at the well-known path — Configure your web server to serve the manifest at /.well-known/agent-intake.json. Most web servers and frameworks support static file serving at this path.
3. Implement your intake endpoint — Handle POST requests, validate the input data against your schema, generate an offer, and return a structured response.
4. (Optional) Implement binding — If your service supports it, handle bind requests to convert offers into active relationships.

The entire implementation can be done in a single file with vanilla Node.js, Python, or any other language. No frameworks, no dependencies, no LLM required.

Checklist

• Manifest served at /.well-known/agent-intake.json with correct Content-Type: application/json
• CORS headers set (Access-Control-Allow-Origin: *) for cross-origin agent access
• Input schema uses anonymized/range-based fields (no PII at intake)
• Offer includes a human-readable summary and structured details
• Offer includes an expiration date
• If binding is supported, bind_endpoint and bind_requires are specified
• Error responses use the standard error format with code and message

For Agent Developers: Consuming AIP Endpoints

Agents interact with AIP endpoints through standard HTTP. The flow is:

1. Discovery: GET https://{domain}/.well-known/agent-intake.json to retrieve the manifest.
2. Schema inspection: Read the input_schema for each intake to understand what data is expected.
3. Data collection: Gather the required data from the user (or from context), using the schema's enums and descriptions as guidance.
4. Submission: POST to the intake endpoint with structured data.
5. Presentation: Present the offer's summary and details to the user in an appropriate format.
6. Comparison: If querying multiple providers, aggregate and compare offers.
7. Binding: If the user accepts, collect the required PII (with explicit consent) and POST to the bind endpoint.

The JavaScript SDK (@aip/sdk) provides helpers for all of these steps, but the protocol is simple enough that raw HTTP calls are perfectly viable.

8. Trust & Certification

Publishing an AIP manifest is free and open. Any business can do it. But how does an agent know that a given AIP endpoint is legitimate, well-maintained, and trustworthy?

The AIP Registry

The AIP Registry at agentintake.io is a certification service that validates and certifies AIP-compliant endpoints. It provides:

• Validation — Automated crawling and testing of AIP manifests and endpoints against the protocol schemas.
• Certification — Issued certificates with unique IDs, expiration dates, and public verification pages.
• Directory — A searchable registry of certified AIP endpoints for agent discovery.
• Trust signals — Embeddable badges and certificate references that agents can check.

Certification Process

1. Business registers at agentintake.io
2. Enters their domain URL
3. Registry fetches and validates /.well-known/agent-intake.json
4. Registry sends test submissions to each intake endpoint
5. Registry validates responses against the offer schema
6. If all checks pass, the business pays the certification fee ($99/year)
7. Registry issues a certificate valid for one year
8. Certificate is publicly verifiable and embeddable

Certification is optional. The protocol itself is free and open. But certification provides a trust signal that helps agents prioritize verified endpoints over unverified ones.

Trust Hierarchy

Agents can use a layered trust model when evaluating AIP endpoints:

1. Certified + Registry: Highest trust. Endpoint has been validated, is listed in the registry, and has a current certificate.
2. Uncertified but valid: Medium trust. Manifest conforms to schema, endpoints respond correctly, but no certification.
3. Unknown: Low trust. Agent should validate the manifest itself and may present a warning to the user.

9. Comparison Matrix

10. Why the Internet is Better With AIP

The internet was built on open protocols. HTTP, SMTP, DNS — each one created an interoperable layer that enabled an explosion of innovation. The same pattern is playing out in the AI agent ecosystem:

• MCP standardized how agents connect to tools — and thousands of tool integrations followed.
• A2A standardized how agents talk to each other — enabling multi-agent architectures.
• UCP/ACP are standardizing how agents buy products — opening agent-mediated commerce.

AIP standardizes how agents initiate service relationships. Without this layer, every business would need to build bespoke agent integrations. With AIP, any business can be agent-accessible by publishing a single JSON file and implementing one endpoint.

The Network Effect

Protocols become valuable as adoption grows. Today, an agent that discovers an AIP manifest at one business's domain can use the same code to interact with any other AIP-compliant business. Each new business that implements AIP increases the value of every agent that supports it, and vice versa.

This network effect is what transforms a protocol from a specification into infrastructure. We've seen it with HTTP, with REST APIs, with OAuth, with JSON Schema. AIP is designed to follow the same trajectory.

The Democratization of Agent Access

Without a standard protocol, only large businesses with engineering teams will build custom agent integrations. AIP levels the playing field. A solo health coach can implement AIP in an afternoon. A local plumber can publish an intake manifest. A small SaaS startup can offer agent-mediated onboarding. The standard is simple enough that it's accessible to everyone.

A More Efficient Economy

Today, intake processes are full of friction. Users fill out forms, wait for callbacks, attend sales meetings, and navigate complex onboarding flows. Much of this friction exists because intake processes were designed for humans navigating GUIs.

With AIP, an agent can query five health platforms, three insurance companies, and two SaaS tools in parallel — all in seconds. The user reviews structured offers, compares them side by side, and makes an informed decision. The entire intake-to-commitment process that currently takes days or weeks can happen in minutes.

This isn't just convenience. It's an efficiency gain for the entire economy. Businesses get qualified leads faster. Users find the right services faster. Agents deliver real value. Everyone wins.

11. Conclusion & Call to Action

The Agent Intake Protocol fills a critical gap in the AI agent ecosystem. As agents become the primary interface through which users discover and engage with services, businesses need a standardized, privacy-respecting, machine-readable intake channel. AIP provides exactly that.

The protocol is:

• Open — MIT-licensed, community-governed, free to implement.
• Simple — One JSON manifest, one endpoint. No LLM, no framework, no complex infrastructure.
• Privacy-respecting — No PII at intake. User controls when and what personal data is shared.
• Complementary — Works alongside MCP, A2A, UCP, and ACP. Fills the gap they leave.
• Practical — Solve a real problem today. Not a theoretical framework — a working protocol with reference implementations.

How to Get Involved

• Implement AIP — Add /.well-known/agent-intake.json to your business. See the examples for reference implementations.
• Get certified — Register at agentintake.io to validate your implementation and join the public registry.
• Build agent support — If you're building an AI agent, add AIP discovery to your service evaluation flows.
• Contribute to the spec — The protocol is in its first version. We welcome feedback, proposals, and contributions on GitHub.
• Spread the word — Share this white paper. Tell your colleagues. Every new implementation strengthens the network.

Every business will need an agent-facing front door. AIP is the key.

12. References

1. Model Context Protocol (MCP). Anthropic, November 2024. modelcontextprotocol.io
2. Agent2Agent Protocol (A2A). Google, April 2025. a2a-protocol.org
3. Universal Commerce Protocol (UCP). Google, Shopify, et al. January 2026.
4. Agentic Commerce Protocol (ACP). OpenAI, Stripe. September 2025. agenticcommerce.dev
5. AGNTCY. Cisco, Linux Foundation. July 2025.
6. RFC 8615 — Well-Known Uniform Resource Identifiers. IETF. rfc-editor.org
7. JSON Schema. json-schema.org