Why OSP

The Problem

Consider what happens today when an AI agent needs to find a logistics provider for a temperature-controlled pharmaceutical shipment from Basel to Rotterdam.

The agent crawls the provider’s website. It parses marketing copy, navigation menus, cookie banners, and JavaScript-rendered content to figure out what the company does. If it’s lucky, there’s a product page that mentions temperature-controlled transport. But does the provider cover the Basel-Rotterdam route? What’s the temperature precision? Is it GDP-certified? What’s the indicative price range? What’s the on-time rate?

None of this is structured. The agent guesses, or gives up and asks a human to make a phone call.

Now imagine the provider publishes an osp.md file. The agent reads 300 tokens and knows: temperature-controlled, +2°C to +25°C, GDP-certified, Europe-wide coverage, CHF 1,200-4,500 per shipment, 94% on-time rate based on 4,200 shipments. Match or no match — in under a second.

That’s the difference OSP makes.

The Gap in the Current Ecosystem

The building blocks for an agent-driven economy are emerging, but there’s a missing piece:

llms.txt makes website content machine-readable. An agent can understand what a company is and what it says. But llms.txt doesn’t tell an agent what the company can do for you — there’s no structure for capabilities, pricing, SLAs, or availability.

MCP (Model Context Protocol) standardizes how agents call tools. It’s become the de facto standard for agent-tool integration, adopted by Anthropic, OpenAI, Google, Microsoft, and thousands of developers. But MCP describes individual function calls — not the commercial lifecycle of a service. There’s no concept of “get a quote,” “place an order,” “track delivery,” or “handle a dispute.”

OpenAPI documents API endpoints comprehensively. But it describes technical interfaces, not business services. An OpenAPI spec tells you the endpoint accepts a POST with these parameters. It doesn’t tell you the service has a 48-hour lead time, requires GDP certification, costs CHF 1,200-4,500, and that a human reviews every order above CHF 100,000.

OSP occupies the layer above these standards. It doesn’t replace any of them — it complements them. An osp.md file can reference llms.txt for content. Service manifests can link to MCP endpoints for execution. The technical API uses OpenAPI under the hood. OSP adds the business semantics that agents need to discover, evaluate, order, and receive services.

Who OSP is For

Service providers — companies that deliver services through human expertise: logistics firms, consulting companies, IT service providers, insurance companies, staffing agencies, facility managers, auditors. These businesses want to be discoverable by AI agents without rebuilding their entire operation. OSP lets them start with a single file and progressively deepen the integration.

Agent developers — teams building AI agents that need to interact with the real world. Today, every service integration is a custom job: parse this website, fill out that form, interpret this email. OSP gives them a standardized interface to discover and consume services, regardless of the provider.

Platform builders — companies creating marketplaces, procurement systems, or orchestration layers where agents and service providers meet. OSP provides the common language that makes these platforms interoperable.

How it Works

OSP defines four layers that can be implemented independently:

Layer 1: Discovery makes a company’s services findable and evaluable. A provider publishes an osp.md file (compact Markdown summary) and detailed service manifests (structured YAML). An agent reads these files and can instantly determine whether the provider fits a given need. This is the only layer needed to get started — and it’s a single file.

Layer 2: Contracting enables ordering. An agent sends a quote request with structured requirements, receives a binding or indicative offer, and places an order. The flow works identically whether the service is fully automated, fully human, or anything in between.

Layer 3: Delivery handles execution tracking. The agent receives status updates, responds to provider questions during delivery, and confirms receipt of the result. For simple services, the result comes back in seconds. For complex consulting engagements, delivery spans weeks with interactive checkpoints.

Layer 4: Settlement manages billing and compensation. Token-based pricing, escrow for prepaid services, automatic refunds for failed deliveries, and structured dispute resolution.

The key design principle: the interface is identical regardless of who fulfills the service. Whether a human logistics dispatcher or an automated routing algorithm processes a transport order, the agent interacts through the same OSP endpoints. This means a company can start with 100% human delivery and progressively automate — without changing the external interface.

Why Now

The transition from a human-only web to a human-plus-agent web is accelerating. Cloudflare is building infrastructure to serve content to AI agents. MCP has become the standard for agent-tool integration. The first agent-driven procurement and comparison tools are emerging.

Companies that make their services agent-accessible now are positioned as the default providers when agents start making purchasing decisions. The first providers with structured, machine-readable service descriptions will be the ones agents find, evaluate, and recommend — simply because they’re the only ones that can be found, evaluated, and recommended.

This isn’t about replacing human relationships. It’s about being discoverable in the channel where the next generation of business decisions will be initiated.