Original project visual
01 / SeatMapOS Agentic Booking
The challenge
Connect AI-directed venue and booking actions to explicit application state, so seat selection, holds, expiry and confirmation follow the same booking rules across interfaces.
Reading the problem / SeatMapOS Agentic Booking
Conversation and inventory need the same source of truth.
The independent platform connects venue building, live availability and hold-confirm-release operations to conversational booking.
Live availability and atomic hold-confirm-release operations need explicit states. The booking demo simulates payment.
How can conversational booking obey the same seat and hold rules as the visual interface?
Evidence: the project account and the attributed artifacts on this page. Process drawings and interaction studies are reconstructed explanations; numerical research or business results are included only where separately supported.
02 / SeatMapOS Agentic Booking
The approach
Venue-generation tools feed the designer; commerce tools use the same booking lifecycle as the web interface. A single-threaded Durable Object serializes seat holds, while confirmation and replay handling reuse the shared checkout path. Unit-testable core rules cover concurrent holds, expiry and confirmation.
- Design the venue. Generate and edit venue geometry through MCP tools.
- Find seats. Connect event discovery to availability and seat options.
- Hold availability. Coordinate atomic seat holds and expiry.
- Complete the lifecycle. Confirm a reservation or release the held seats.
03 / SeatMapOS Agentic Booking
My contribution
- Built MCP tools for parametric venue generation, pushed geometry and spreadsheet-shaped venue data.
- Exposed event discovery, seat options, holds, release, booking confirmation and order lookup to conversational clients.
- Implemented atomic seat coordination on Cloudflare Durable Objects, with live availability, expiry and confirmation rules.
- Connected D1 metadata, R2 seat data, WebGL views and a ChatGPT seat-picker/booking widget.
The process / SeatMapOS Agentic Booking
A direction.
A way to build it.
The design follows the booking engine’s commitments, from an available option to a temporary hold and a confirmed result.
A schematic of sequence and overlap, not a dated project schedule.
Identify the booking states
Distinguish availability, selection, hold, expiry, confirmation and release.
Align visual and agent actions
Make the conversational and visual interfaces refer to the same seat and hold operations.
Prototype venue and seat flows
Explore the connection between venue setup, seat options and temporary holds.
Review state transitions
Check how the interface explains a conflict, an expired hold or a completed booking action.
How can conversational booking obey the same seat and hold rules as the visual interface?
Finding a seat, holding it and confirming it are different commitments. SeatMapOS connects conversational and visual interfaces to the same hold-confirm-release operations. The design has to make those boundaries understandable, especially when availability changes while someone is deciding.
Journey map / SeatMapOS Agentic Booking
See the whole task in context.
Choose a step to connect the person’s intent with the interface and the design decision.
Current intent
Describe the venue
Live availability and atomic hold-confirm-release operations need explicit states. The booking demo simulates payment.
- Interface context
- Venue workspace
- Review question
- When does an option become a temporary hold, and when does it become a confirmed booking?
Representative task sequence and recovery path, not a measured emotional curve or historical research map.
Behind the experience
The visible task depends on work behind it.
For SeatMapOS Agentic Booking, this map connects “Describe the venue” to “Confirm or release”. Read across to follow the task, then select a layer to inspect the interface, design and delivery references behind it.
| Layer | Describe the venue | Inspect seat options | Hold selected seats | Confirm or release |
|---|---|---|---|---|
| The task | Describe the venue | Inspect seat options | Hold selected seats | Confirm or release |
| Visible interface | Venue workspace | Venue workspace | Seat selection | Hold confirmation |
| Design checkpoint | Live availability and atomic hold-confirm-release operations need explicit states. The booking demo simulates payment. | Establish the venue and available seating context. | Distinguish an option from a temporary hold. | Explain whether the hold is confirmed, expired or released. |
| Implementation reference | Distinguish availability, selection, hold, expiry, confirmation and release. | Make the conversational and visual interfaces refer to the same seat and hold operations. | Explore the connection between venue setup, seat options and temporary holds. | Check how the interface explains a conflict, an expired hold or a completed booking action. |
| Recovery | Hold expires or seat becomes unavailable → refresh availability → choose again | |||
A reconstructed delivery map: the implementation row summarizes design-process dependencies, rather than claiming to document the original backend architecture.
Engine-backed seat actions.
Reconstructed comparison of design approaches. These are review studies, not a claim that both directions were historically tested or shipped.
What this direction changes
Engine-backed seat actions
Requires explicit state changes against the availability reference.
Represent the hold as a temporary state.
The venue workspace leads into seat selection and hold confirmation. These reconstructed views emphasize what a user needs to inspect before and after a hold exists. An expiring option should not be presented with the same language as a confirmed booking.
01 / Venue workspace
SeatMapOS Agentic Booking⌕
01Venue workspace↗
02Seat selection↗
03Hold confirmation↗
Inspect seat options
Establish the venue and available seating context.
02 / Seat selection
SeatMapOS Agentic Booking⌕
Describe the venueVenue workspace
Inspect seat optionsSeat selection ⌄
✓Hold selected seats
Hold selected seats
Distinguish an option from a temporary hold.
03 / Hold confirmation
SeatMapOS Agentic Booking⌕
Confirm or release
- Venue workspace
- Review
- Seat selection
- Review
Confirm or release
Explain whether the hold is confirmed, expired or released.
Try the interaction
SeatMapOS Agentic Booking / Task & review study
SeatMapOS Agentic Booking01 / 03
View 01
Venue workspace
Establish the venue and available seating context.
Keep this context visibleVenue workspace
Establish the venue and available seating context.
Starting context
Describe the venue
Availability, expiry and confirmation are separate messages.
Make seat names, hold expiry, availability and confirmation states legible. Do not rely on color alone to describe booking status.
Illustrative type-role specimenSeatMapOS Agentic Booking
Describe the venue.
Confirm or release.
HeadingSeat selection
24 / 30 px · regularBodyHow can conversational booking obey the same seat and hold rules as the visual interface?
16 / 26 px · regularLabelConfirm or release
12 / 18 px · regularStateHold expires or seat becomes unavailable → refresh availability → choose again
12 / 18 px · regularPortfolio-font hierarchy illustration; the source does not establish the exact client font or token scale.
Resolve competing intentions with explicit state.
When does an option become a temporary hold, and when does it become a confirmed booking?
The interface should identify when a chosen option has become a hold. That change affects what the user can do next and how long the option remains valid.
How should the agent and visual interface explain expiry or a conflicting selection?
Expiry and conflicting selections need a route back to current availability. A confirmation-looking surface should not survive after its underlying hold is no longer valid.
Review the interface against the state transition.
This platform connects venue design and live booking operations. For each interaction, the handoff needs to name the booking state before the action, the allowed transition and the result that the visual and conversational interfaces should both report.
A future Codex change should exercise hold, expiry, confirm and release behavior using the same rules as the interface. Keep simulated checkout language intact; the demo should not imply that it processed a real payment.
The booking platform demonstrates live availability and atomic holds; its checkout demonstration simulates payment.
Accessibility & standards
Access belongs in the design.
For this ticketing experience, prioritize seat-selection alternatives, availability announcements, reservation time limits and recovery without losing a selection.
WCAG 2.2 AA · EN 301 549 · APCA · WAI-ARIA · Platform guidance
Complete the task without a mouse
Define tab order, visible and unobscured focus, named controls, table relationships and error recovery using native semantics and WAI-ARIA patterns.
Understand every state
Pair color with text or icons for selection, warnings and availability. Review text at WCAG contrast thresholds and use APCA alongside font size and weight for readability decisions.
Keep the workflow usable
Review zoom and reflow, 24 × 24 CSS-pixel minimum targets or qualifying spacing, alternatives to dragging, validation and accessible authentication where applicable.
Review scope & standards references
These are design references and review priorities, not a claim that this historical project passed a WCAG audit. Record criterion-level evidence, assistive-technology and device results, unresolved issues and retest outcomes before making a conformance statement.
APCA supplements the WCAG 2.2 contrast checks; it does not replace them. WCAG 3 remains a draft. EN 301 549 v4.1.1 is the latest published edition checked on 6 November 2026; its publication and its formal EU legal citation are separate matters. Confirm the applicable procurement or legal baseline with the client.
Outcomes & scope
What the work delivers.
- Independent SeatMapOS platform with implemented venue and reservation tools. The demo checkout simulates payment. This project is separate from the TicketCo prototypes.
Results are described within the documented project scope. Illustrative studies are identified separately from original project artifacts.
Review & next iteration
What needs to hold up in use.
Use these questions to review SeatMapOS Agentic Booking against the behavior the design is intended to support.
- 01
Does a released hold stop appearing as reserved?
- 02
Can a conversation distinguish a suggested seat from a confirmed booking?
Project-specific acceptance questions for a future review, not reported usability-test results.
Reflection / SeatMapOS Agentic Booking
What I’d carry forward.
Conversation can make booking more approachable, but it cannot replace inventory rules. The durable design boundary is between an agent’s suggestion and a confirmed system action.