Introducing the Open Service Protocol

March 2026

AI agents can read your website. They can call your API. But they can’t find out what your company actually does for its clients, compare you against alternatives, place an order, and receive the result — all through a standardized protocol.

The Open Service Protocol (OSP) addresses this gap. It defines how businesses describe their services for AI agents, how agents evaluate and order those services, and how delivery works — regardless of whether the service is performed by a human, a machine, or any combination of both.

The Missing Layer

The ecosystem for agent-to-world interaction is maturing rapidly. llms.txt makes website content agent-readable. MCP has become the standard for agent-tool integration, with adoption from Anthropic, OpenAI, Google, Microsoft, and thousands of developers. OpenAPI documents technical interfaces comprehensively.

But there’s a layer missing between “reading content” and “calling functions”: the business layer. How does an agent discover that a company offers temperature-controlled pharmaceutical transport across Europe? How does it compare that provider’s GDP certification, on-time rate, and pricing against two competitors? How does it place an order and track delivery?

No existing standard covers this. OSP does.

The Simplest Possible Start

OSP starts with a single file: osp.md, placed at the root of a website. It’s written in Markdown (token-efficient, human-readable) and follows a simple structure:

# TransLogistics

> International transport specializing in temperature-controlled
> shipments for pharma, biotech, and food. GDP-certified.
> Europe-wide, from 5 pallets to full truckloads.

## Available Services

- [LTL Transport](/osp/services/ltl-transport.yaml):
  5-15 pallets, temperature-controlled, 48-96h across Europe

## Not Available

- Air freight and ocean freight
- Dangerous goods classes 1, 6, 7

## Conditions

- Minimum order: CHF 800
- Regions: Switzerland, EU, UK, Norway
- Quote response: < 2h during business hours

## Integration

- OSP Version: 0.1

An agent reading this file consumes fewer than 300 tokens and knows immediately whether this provider is worth investigating further. The “Not Available” section is as important as the service list — it prevents agents from wasting time on requests that will be rejected.

For deeper evaluation, each service links to a YAML manifest with structured data: pricing ranges, SLAs, certifications, capacity parameters, maturity level, and confidence notes. An agent that needs to compare three logistics providers on temperature precision, on-time rate, and GDP certification can do so in seconds — because the data is standardized and machine-readable.

See it in Action

We built a demo agent that shows how this works in practice. It has 9 providers loaded across 3 industries (logistics, strategy consulting, IT infrastructure), each with three comparable companies.

Tell it “8 pallets of pharmaceutical products from Basel to Rotterdam, temperature-controlled at 5°C, GDP documentation required” — and it evaluates all three logistics providers against your specific requirements, citing exact numbers from their OSP manifests.

The demo deliberately runs on Meta’s Llama 4 Scout via Cloudflare Workers AI, not on Claude or GPT. This underscores a key point: OSP works because the format is structured, not because any particular model is used.

Try the demo →

Four Layers, Start with One

OSP defines four layers:

Layer 1: Discovery — the osp.md file and service manifests. Makes your services findable and evaluable. This is live and specified today.

Layer 2: Contracting — quotes, orders, and configuration. Enables agents to order services through a standardized flow. Planned.

Layer 3: Delivery — execution tracking, status updates, interactive delivery. Planned.

Layer 4: Settlement — token-based billing, escrow, compensation. Planned.

Each layer is independently implementable. A company that publishes only an osp.md file is already agent-discoverable. The deeper layers come when the business is ready.

The critical design principle: the interface doesn’t change when the service moves from human to automated delivery. A company can start with humans behind every API endpoint and progressively automate — the agents consuming the service never notice the difference. Only the response times and potentially the prices change.

Get Involved

OSP is an open standard, published under CC-BY-4.0 (specification) and Apache 2.0 (code). The specification, examples, and schemas are on GitHub.

The most valuable contribution right now: create an osp.md for your own business and submit it as a pull request. Every real-world example makes the standard stronger.

What’s Next

Layer 1 is specified and demonstrated. The next steps:

  1. Community feedback on the discovery format and service manifest schema
  2. More real-world examples across industries
  3. A validator tool for checking osp.md files and manifests
  4. Draft specification for Layer 2 (Contracting)

If you see something that doesn’t work for your service type, open an issue. If you have an idea for improvement, start a discussion. This standard will be shaped by the people who use it.