An open standard for agent-first service discovery, contracting, and delivery.
⚠️ Draft specification — not yet stable. This is an early proposal. Everything is subject to change. Feedback welcome via Issues and Discussions.
AI agents can read websites (llms.txt, Cloudflare Markdown). They can call tools (MCP, OpenAPI). But they can't discover what a company does, evaluate whether it fits their needs, place an order, and receive the result — all through a single, standardized protocol.
OSP closes this gap. It defines how businesses describe their services for AI agents, how agents order those services, and how delivery works — regardless of whether the service is performed by a human, a machine, or any combination.
Create an osp.md file in your website's root directory:
# Your Company Name
> One-paragraph description of what you do, who you serve,
> and what makes you relevant for an AI agent looking for
> your type of service.
## Available Services
- [Service A](/osp/services/service-a.yaml): Brief description
- [Service B](/osp/services/service-b.yaml): Brief description
## Not Available
- Things you explicitly don't do (saves agents time)
## Conditions
- Geographic scope, minimum order, languages, response times
## Integration
- OSP Version: 0.1That's it. Your business is now discoverable by AI agents.
| Standard | What it solves | What it doesn't solve |
|---|---|---|
| llms.txt | Agents can read your content | Agents can't act on it |
| MCP | Agents can call tools | No service lifecycle (order, deliver, pay) |
| OpenAPI | API endpoints are documented | No business semantics (SLAs, pricing, human steps) |
| OSP | Agents can discover, evaluate, order, and receive services | — |
OSP doesn't replace these standards. It builds on them. Service manifests link to MCP endpoints. The osp.md file complements llms.txt. Technical APIs use OpenAPI under the hood.
OSP has four layers. Each is independently implementable.
Layer 4: Settlement — billing, compensation, dispute resolution
Layer 3: Delivery — execution, tracking, result handover
Layer 2: Contracting — quotes, orders, configuration
Layer 1: Discovery — catalog, evaluation, comparison
Start with Layer 1 (a single file). Add layers as you need them.
- Layer 1: Discovery — the
osp.mdfile format and how agents find your services - Service Manifest Reference — complete YAML schema for describing a service
- Profiles (v0.2+) — branch-specific vocabularies for attributes that matter within an industry but not across
- Layer 2: Contracting (planned)
- Layer 3: Delivery (planned)
- Layer 4: Settlement (planned)
Machine-readable schemas for validation:
- osp-md.schema.json — validates the structure of
osp.mdfiles - service-manifest.schema.json — validates service manifest YAML files
- profiles/ — seven pilot domain profiles (logistics, cold-chain, consulting, IT managed services, legal, energy, cleaning)
- profiles/registry/index.json — machine-readable profile registry, mirrored at
profiles.openserviceprotocol.org/registry/index.json - profiles/profiles.txt — llms.txt-style Markdown summary of the registry for LLM-friendly discovery, served at
profiles.openserviceprotocol.org/profiles.txt
Discovery files for different industries:
- Logistics provider — international transport, temperature-controlled
- Consulting firm — strategy advisory, multi-phase engagements
- IT service provider — managed cloud, continuous service
Complete YAML manifests showing all schema sections, each declaring the relevant domain profiles:
- LTL Transport — logistics-general + cold-chain-logistics; transactional, async delivery
- Market Entry Strategy — consulting; consultative, interactive delivery
- Managed Cloud Hosting — IT managed services; continuous, tracked delivery
- Swiss Market Entry Legal Package — legal advisory
- SME Green Electricity — energy supply
- Medical Cleaning Specialist — cleaning services
These examples deliberately cover different engagement types, maturity levels, delivery modes, and branches to show the full range of the format.
- Agent-first, human-compatible. Optimized for machines, readable by humans.
- Progressive disclosure. 50 tokens for a first impression. Full detail on demand.
- Maturity-agnostic interface. Same API whether a human or algorithm fulfills the service.
- Build on what exists. Markdown for readability, JSON Schema for structure, MCP for tool integration.
osp/
├── spec/
│ ├── discovery.md # Layer 1 specification
│ ├── service-manifest-reference.md # Complete manifest schema docs
│ └── profiles.md # Domain profile mechanism (v0.2)
├── schemas/
│ ├── osp-md.schema.json # JSON Schema for osp.md
│ └── service-manifest.schema.json # JSON Schema for manifests
├── profiles/ # Branch-specific vocabularies (v0.2)
│ │ Directory layout mirrors the
│ │ public URL at profiles.openserviceprotocol.org
│ ├── logistics-general/v1.schema.json
│ ├── cold-chain-logistics/v1.schema.json
│ ├── consulting/v1.schema.json
│ ├── it-managed-services/v1.schema.json
│ ├── legal-advisory/v1.schema.json
│ ├── energy-supply/v1.schema.json
│ ├── cleaning-services/v1.schema.json
│ ├── profiles.txt # llms.txt-style Markdown summary
│ ├── index.html # Landing page for the subdomain
│ ├── CNAME # profiles.openserviceprotocol.org
│ └── registry/
│ ├── index.json # Machine-readable registry
│ └── index.schema.json
├── examples/
│ ├── logistics.osp.md
│ ├── consulting.osp.md
│ ├── it-services.osp.md
│ └── manifests/ # Six full example manifests
├── proposals/ # RFCs and drafts
│ └── 001-profiles-and-attributes.md
├── tools/
│ └── validate.py # Manifest + profile + registry validator
└── .github/
└── workflows/
├── validate.yml # CI: runs validator on PRs and main
└── deploy-pages.yml # Publishes profiles/ to Pages
See CONTRIBUTING.md. We welcome feedback, examples, and implementations.
The most valuable contribution right now: create an osp.md for your own business or industry and submit it as a pull request.
- Specification: CC-BY-4.0
- Code and tools: Apache 2.0
See NOTICE for details.