Skip to content
OSBP

Openings Example

Openings is a booking platform for appointment-based service businesses. In practical terms, they help businesses publish services, schedules, provider availability, customer records, and appointment workflows through software instead of ad hoc messages and calendars.

That made Openings an ideal launch design partner for OSBP. OSBP is about provider-bound time, not generic checkout, and Openings works directly in that world. Their team helped pressure-test OSBP’s adapter shape against a real booking platform: how to resolve a business and service, how to read policy before mutation, how to handle customer verification, how to return a receipt, and where an agent must stop rather than guess.

The Openings adapter ships in v0.1.0 as a regular OSBP adapter for a booking platform: it integrates AI-agent booking through OSBP while Openings remains the system of record. That is a meaningful contribution: it gives other platform teams something concrete to inspect, adapt, and critique instead of starting from a blank connector.

Adapter shape

Section titled “Adapter shape”

The Openings example wires one AI agent to OSBP, through an adapter, to an Openings-backed service business:

AI agent <-> OSBP tools <-> Openings adapter <-> Openings booking platform

The adapter maps the OSBP contract onto Openings’ native booking model. The platform remains authoritative for service data, availability, customer verification, appointment creation, and booking status. OSBP supplies the trust boundary around the agent: every mutation must fit inside the user-approved BookingMandate, and a request that cannot be completed safely returns a structured problem or handoff.

In OSBP terms, the example exercises the same loop as the reference backend:

BookingMandate -> lookup -> policy readback -> user approval -> create -> verification if required -> status -> receipt

What Openings adds to the proof

Section titled “What Openings adds to the proof”

The credential-free reference backend is intentionally controlled. Openings adds the useful friction of a real product surface: native ids, platform policy, live availability semantics, customer verification, and platform-owned appointment state.

Those details are exactly where agent integrations tend to become unsafe if they are only treated as “call the booking API.” The Openings work helped show what an OSBP adapter needs to make explicit:

  • the service and schedule the agent is actually allowed to book
  • the policy and price impact the user must see before approving
  • the native create call that must not happen before final confirmation
  • the verification step when the platform requires one
  • the status and receipt data the agent can safely report back
  • the handoff boundary when payment, policy, verification, or platform state cannot be completed inside OSBP

This is why the Openings example is important: it connects the small OSBP contract to the real operational shape of appointment software without asking the agent to become trusted infrastructure.

Read-only and live paths

Section titled “Read-only and live paths”

The adapter has two useful modes.

The read-only path resolves the configured Openings business, discovers service and schedule data, finds availability, and explains policy. It must not create a booking, send customer verification, or write a live appointment. This is the right first smoke test for an adapter because it proves the read lane without touching scarce provider time.

The live booking path is deliberately gated. A real booking attempt needs eligible customer details and a way for the user to supply any verification code Openings requires. Live business values, customer ids, phone numbers, and verification codes belong in ignored local files, not in source, traces, screenshots, or public docs.

Tool flow

Section titled “Tool flow”

An MCP-compatible host can drive the OSBP tool set. The adapter exposes the same eight OSBP tools:

osbp_service_describe
osbp_availability_find
osbp_policy_explain
osbp_verification_send
osbp_verification_verify
osbp_booking_create
osbp_booking_status
osbp_handoff_request

A safe read-only prompt should produce the sequence osbp_service_describe, osbp_availability_find, osbp_policy_explain, and no appointment.

For a live booking, the host constructs a BookingMandate, shows it to the user with a human-readable price cap and policy summary, and reuses the mandate and idempotency_key across retries. The first osbp_booking_create call omits approval and returns requires_user_confirmation before any appointment is created. After the user approves that exact summary, the agent retries osbp_booking_create with the same logical attempt and the returned approval.

If Openings requires verification, the agent relays the platform’s challenge to the user and retries only with the user’s supplied code. If payment, a deposit, a policy fee, or an ambiguous platform state cannot be handled safely inside the mandate, the adapter returns a problem or osbp_handoff_request result instead of forcing the booking through.

Publication status

Section titled “Publication status”

The public v0.1.0 repository ships the credential-free reference backend, trace gallery, conformance kit, adapter starter, local stdio MCP server, and Openings adapter/integration kit.

It should be read as an implementation example, not a special-case endorsement surface. The neutral claim is stronger: a booking platform with real product constraints can expose AI-agent booking through the same small OSBP contract as the synthetic reference backend.

Openings deserves clear credit: They worked with the OSBP protocol at its earliest stage, let it meet real scheduling infrastructure early, and rapidly iterated with OSBP on turning open feedback into documentation and changes when needed. That is the difference between a neat schema and a proof that survives contact with a platform. My sincere thanks to Eddie and the Openings team.

Repository · Read the specification