Roadmap

For integrators, agent builders, and contributors who want to know where OSBP is heading next.

OSBP v0.1.0 is a usable proof and formative contract. It shows an agent completing a real booking through a narrow tool set, bounded by a user-approved BookingMandate, with local idempotency, audit, and fail-closed behavior. The v0.1.0 surface is create-only: holds, change, cancel, reschedule, and payment collection are roadmap items below, not part of the current contract.

The project is pre-1.0. The near-term roadmap is directional, not a compatibility promise. For how these land across releases, see Versioning.

Near-term directions

• Remote MCP transport. A hosted, streamable HTTP MCP endpoint so agent hosts that cannot launch local stdio servers can validate the same tool contract.
• Verifiable agent identity and transport authorization. Moving beyond a self-declared User-Agent toward cryptographically verifiable agent identity (for example HTTP Message Signatures (RFC 9421) and the emerging Web Bot Auth profile) and, for the remote MCP server, OAuth resource-server authorization, so the booking platform can authenticate the caller and attribute a booking to a specific user. Where a booking platform exposes an opaque metadata field on its appointment record, OSBP will also write the mandate id and audit reference into it, so a booking stays durably attributable on the platform side.
• Broader agent-host validation. Testing the booking flow across more agent surfaces while keeping mandate enforcement server-side rather than trusting host UI alone.
• Cancel and change surfaces. Cancellation and booking-change tools, designed only after the create-booking proof is stable enough to extend without blurring the trust boundary.
• Payment-protocol composition. Keeping payment authority separate and defining how booking mandates can compose with payment-mandate protocols when a booking requires money movement.
• Contention controls for scarce slots. Because OSBP holds no slot and the platform is the system of record, the first completed mutation wins, which is a race when provider time is scarce and sharper when a deposit sits inside a multi-step booking. OSBP will explore an optimistic-concurrency token (an availability_snapshot_id carried on a mutation, so a stale attempt fails cleanly with fresh availability instead of double-booking) and, where a platform supports it, a short-lived hold with an explicit complete-by deadline (hold_expires_at) that lets a booking reserve, authorize payment, and confirm inside one window, releasing the hold and voiding the authorization on failure so a user is never booked-not-paid or paid-not-booked. Holds stay optional and platform-dependent; OSBP will not require one where a platform has none.
• Global-readiness hardening. v0.1.0 already carries canonical machine values and leaves user-language presentation to the agent or host. v0.2.0 can add merchant locale/language metadata, structured Problem params and receipts, Unicode-normalized idempotency hashing, and evolvable enum policy without breaking the create-booking proof; broader shape changes such as required slot timezones belong in the planned v0.3.0 breaking release.
• Integrator-facing conformance. OSBP has a first credential-free conformance kit for BookingAdapter implementations, and will grow examples, traces, and machine-checkable schemas so platform adapters can be generated, reviewed, and verified against the same narrow contract.

What stays out for now

OSBP will not become a marketplace, payment processor, identity wallet, or general agent-to-agent coordination layer. It should stay small enough that a booking platform can implement it, an AI agent can reason over it, and a user can understand exactly what authority they granted.

Have a direction you want to see? Open an issue at github.com/osbp-dev/osbp/issues.