Key takeaways
- The scheduling platform, not the model, owns membership status, capacity, waitlist position and booking state.
- Availability must be checked again immediately before committing a booking.
- Booking, cancellation and waitlist actions need explicit member confirmation and idempotency.
- The agent may route accessibility or health-related questions but must not give medical or exercise advice.
- Success is a verified state change or a clear staff handoff, never a confident message without a booking receipt.
What business workflow does this agent own?
This agent handles a narrow front-desk workflow: answer approved membership and class-policy questions, find suitable classes, verify whether the identified member may book, create or cancel a reservation, join a waitlist and send a confirmation. It can also collect a prospective member’s contact details for staff follow-up with appropriate notice and consent.
It does not create membership contracts, set prices, waive fees, take payment, override age or access rules, change class capacity, recommend exercise for a medical condition or decide whether a person is fit to participate. Those actions remain with authorised staff and existing business systems.
Capacity-aware booking state machine
From request to confirmed system state
Business boundary and permissions
| Action | Agent may | Required control | Never autonomous |
|---|---|---|---|
| Membership questions | Answer from approved current policy | Citation/version and staff route | Invent price, contract term or exception |
| Class discovery | Read timetable, location and public description | Fresh read from source system | Promise availability from cached text |
| Book or waitlist | Call authorised booking tool | Verified identity, eligibility, confirmation, idempotency | Override capacity or membership restriction |
| Cancel | Cancel eligible member booking | Show applicable policy before confirmation | Waive fee or change policy |
| Health/accessibility | Collect minimal routing note and contact staff | Explicit purpose, restricted access | Medical, rehabilitation or personalised exercise advice |
| Payment/contract | Provide approved link or staff handoff | Authoritative checkout/CRM | Charge card, sign contract or change plan |
Input and output data schema
| Field | Type | Required | Rule |
|---|---|---|---|
| request_id | string | Yes | Unique idempotency key for the conversation action |
| intent | enum | Yes | membership_question, find_class, book, waitlist, cancel, human_help |
| member_reference | token/string | For member action | Use verified identifier; do not expose full profile in model context |
| club_id | string | For schedule | Must match authoritative location |
| class_id | string | For state change | Selected from fresh schedule result |
| requested_time | ISO datetime + timezone | For discovery | Normalise and repeat visibly to member |
| member_confirmed | boolean | For write | True only after showing exact class/action/policy |
| result_status | enum | Output | confirmed, waitlisted, cancelled, no_capacity, ineligible, needs_human, failed |
| booking_reference | string/null | On success | Returned by source system, never model-generated |
| staff_reason | enum/null | On handoff | policy_dispute, health_question, identity_failure, system_error, other |
How to build the workflow
- Choose the authoritative systems. Name the membership database, timetable/booking platform, policy source and support queue. Do not create a parallel capacity count in the AI workflow.
- Define intents and stopping conditions. Limit the first version to membership FAQs, discovery, booking, waitlist and cancellation. Stop on identity mismatch, unsupported policy exception or repeated tool failure.
- Create narrow read tools. Separate member eligibility, class search, live capacity, existing booking and cancellation-policy reads. Return typed results and freshness timestamps.
- Design confirmation. Before any write, show club, class, instructor if relevant, local date/time, booking or cancellation action and applicable rule. Require an explicit yes.
- Create idempotent write tools. The booking platform receives request_id, verified member and class. Repeating the same request must return the existing result rather than create another booking.
- Add waitlist logic. Join only if the platform reports no capacity and the member confirms. Never invent a waitlist position or promotion time.
- Add privacy and staff routes. Minimise member data in prompts and logs. Route contract disputes, sensitive health/accessibility notes and unresolved identity to an authorised person.
- Test and monitor. Run the matrix below, verify final system state, track error categories and alert staff when the booking source is unavailable.
Normal, error and escalation paths
| Path | Trigger | System behaviour | Member message |
|---|---|---|---|
| Normal booking | Eligible member, space available, confirmed | Write once, read receipt, store audit event | Confirmed class details and booking reference |
| Waitlist | Class full, waitlist open, confirmed | Create waitlist entry and verify result | Waitlist status from source; no promise of place |
| Ineligible | Plan/location/booking-window rule blocks | No write; show approved reason or staff route | Concrete rule and next option |
| Race condition | Space disappears before write | Return no_capacity; offer waitlist/alternatives | Explain capacity changed; do not claim booking |
| Tool failure | Timeout or malformed response | Retry bounded read; no blind write; open staff task | Booking not confirmed; staff will review |
| Policy/health dispute | Exception or advice request | Stop automation and restrict handoff data | Staff contact/handoff, no advice or exception |
Test matrix before launch
| Test | Expected outcome | Pass evidence |
|---|---|---|
| One available place | One booking after explicit confirmation | Single source-system receipt and audit event |
| Two simultaneous requests for final place | Only source-authorised result succeeds | No over-capacity; loser gets waitlist/alternative |
| Repeated webhook/message | No duplicate booking | Same idempotency result returned |
| Membership not eligible | No write and correct staff/policy route | Tool decision, not model invention |
| Cancellation after cutoff | No autonomous waiver | Policy displayed and staff escalation offered |
| Booking API timeout | No success message | Failed/pending state and staff alert |
| Health advice request | No medical or exercise recommendation | Safe boundary plus qualified staff/professional route |
| Unverified identity | No member data or state change exposed | Authentication request or human handoff |
Privacy and data retention
Gym bookings use personal data and may reveal routines. Under GDPR principles, the gym should state the purpose, collect only what is necessary, keep it accurate, restrict access and define retention. Do not copy full member profiles into the model prompt or retain free-form conversation by default.
Health information can receive special protection. The safer first version does not collect diagnoses or infer fitness. If a member volunteers sensitive information, minimise it, do not use it for advice and transfer the case through an approved restricted channel.
Learn to build the whole controlled workflow
This gym example is one industry-specific workflow. For the reusable build process, see the general BCS agent guide.
Barcelona Code School’s AI Agent & Automation Bootcamp teaches n8n, shared data, tools, RAG, approvals, QA, orchestration and monitoring through connected business systems. The programme runs for four weeks / 160 hours, full-time, on campus or remote live. Tuition is €3,600. It prepares portfolio evidence; it does not guarantee employment.
See the AI Automation BootcampFrequently asked questions
Can an AI agent book gym classes automatically?
It can complete a booking after verified identity, eligibility, live capacity and explicit member confirmation. The booking platform must return the final receipt. The model should never invent availability or confirmation.
How should the agent handle a full class?
It should read the current waitlist policy, offer the waitlist or alternative classes and create a waitlist entry only after confirmation. It must not promise a place or promotion time unless the source system provides it.
Can the agent cancel a booking?
Yes when the verified member requests it and the authoritative policy permits the action. The agent should show relevant cutoff or fee information before confirmation and escalate exception or waiver requests to staff.
Should the gym agent give workout or health advice?
No. This workflow is for membership information and booking operations. Medical, rehabilitation, injury and personalised exercise questions should go to an appropriately qualified person under the gym’s policy.
What systems does a gym booking agent need?
It needs approved access to membership eligibility, the live timetable and capacity, booking/waitlist/cancellation tools, current policy content, a notification channel, an audit log and a staff-support queue.
How do you prevent duplicate or over-capacity bookings?
Use an idempotency key for every action, recheck live capacity before the write, let the booking platform enforce capacity atomically and verify the returned final state before sending confirmation.