AIBooking MVP PRD

Product thesis

Do not build a booking app first. Build a booking agent.

The wedge is private shared assets: houses, pools, guest rooms, studios, tools, or spaces. The agent hides setup complexity and makes each booking action reviewable.

Problem

Booking shared assets is messy

Owners coordinate by chat, remember rules manually, and answer the same availability questions many times.

Solution

Chat creates and runs the booking flow

The owner describes a service. The AI builds the calendar, checks slots, asks questions, and confirms bookings.

MVP proof

One full booking loop

One owner, one or many services, invited guests, owner approval, booking confirmation, and visible receipts.

Booking core

Use the VoxelBooking fork as the booking engine.

The fork is github.com/lytv/VoxelBooking. AIBooking should wrap it with agent tools instead of rebuilding booking rules from zero.

Reuse

Booking rules and reservations

Use VoxelBooking for service records, availability, blocked dates, resource bookings, and booking state.

Add

Agent-safe API layer

Add small endpoints or tools for create service, check availability, request booking, approve, reject, and cancel.

Do not start with

Full booking UI rewrite

Keep VoxelBooking admin UI as a fallback. Build the first AIBooking experience in OpenMuse chat cards.

AIBooking case	VoxelBooking pattern	MVP use
House, room, cabin	Resource	Main MVP path. Book dates or nights for one asset.
Swimming pool	Resource or capacity	Use resource for private pool blocks. Use capacity later for shared slots.
Class, dinner, workshop	Event	Skip for first MVP unless the booking loop needs it.
Massage, clinic, consultant	Timeslot	Good later use case. Not the first house-sharing proof.

Primary flows

The product is four chat flows.

Each flow must leave a structured record, not only a message. The agent can talk naturally, but every action writes to the booking system.

01

Create service

Owner says what they have. AI asks only missing questions and creates the service.

02

Check availability

Guest asks for a date. AI resolves the service and checks calendar rules.

03

Request approval

If free, AI creates a pending booking and asks the owner to approve or reject.

04

Confirm booking

AI confirms to guest, updates calendar, and shows a booking card to both sides.

MVP scope

Small enough to build. Real enough to test.

The MVP supports the 5 friends x 5 houses case because that is only 25 services. The hard part is identity, permission, and service selection, not scale.

Capability	MVP decision	Notes
Chat-first UI	Build	Use OpenMuse as the base personal AI surface.
Booking core	Reuse	Use lytv/VoxelBooking as the source for booking rules and reservation storage.
AI service setup	Build	User describes the asset. AI creates service fields in the booking core.
Multiple services per owner	Build	Required for 5 friends x 5 houses.
Private invite access	Build	Each service can be shared with friends.
Guest booking by chat	Build	Guest asks for a date. AI checks availability.
Owner approval	Build	Default safety model. No silent auto-booking.
Booking cards	Build	Cards show state, dates, people, and actions.
Payments	Skip	Too much risk for first proof.
Public marketplace	Skip	Later, after private agent loop works.
External calendar sync	Manual first	Export or import later. Internal calendar first.

Data and permissions

The model must handle many owners and many services.

The AI must never guess the service when a user has access to more than one. It must ask a clarifying question and show options.

User owns many Service has access to many ServiceShare Service belongs to one owner has AvailabilityRule has Booking has InviteLink Booking belongs to one Service has guest has status: pending | approved | rejected | cancelled ChatThread links to owner, guest, service, booking

Service selection rule

Ask when ambiguous

If a guest asks “Can I book Saturday?” and has access to five houses, the AI asks which house. It must not pick one silently.

Permission rule

Access is explicit

A guest can only see services shared with them. An owner can manage only their own services.

Approval rule

Owner controls booking

Every MVP booking starts as pending. Only the owner or owner-approved agent action can approve it.

Audit rule

Every action has a receipt

Each booking change shows who asked, what the AI did, and the resulting state.

Agent tools

OpenMuse gets booking-native tools.

The model chats, but trusted server tools own state changes in VoxelBooking. Tool output renders as chat cards.

Setup tools

create_service
update_service_rules
create_invite_link

Booking tools

check_availability
request_booking
approve_booking
reject_booking

Display tools

show_service_card
show_booking_card
list_accessible_services

Success metrics

Measure the loop, not the dream.

The first goal is not revenue. The first goal is proof that people complete bookings through an AI chat.

80%

Owners create a service without human help.

60%

Invited guests complete a booking request.

< 2 min

Median time to answer “is it available?”

0

Silent or unauthorized bookings.

Build sequence

Recommended first milestone

Build a local OpenMuse fork plus the lytv/VoxelBooking fork. Start with house booking through the resource pattern. Implement service creation, service selection, availability check, booking request, owner approval, and booking card receipts. Test with the 5 friends x 5 houses case before adding payments, marketplace features, capacity booking, or events.