Case Study Skeleton: Scheduling Agent for a Multi-Location Clinic
Status: SKELETON. Sections marked [PILOT DATA] are populated only with measured results from an actual engagement — never estimated.
Dry-run evidence (simulated). Our deterministic pilot simulator already exercises this exact agent stack end-to-end: over a 14-day synthetic window it processed 55 booking requests → 20 appointments booked, 35 guardrail rejections, zero double-bookings and zero off-hours slips (full dry-run report available on request, see the live demo scenario). No real customers were involved.
The client
Multi-location physical therapy clinic, three sites, ~120 appointment changes/day across front-desk phone, voicemail, and email. [CLIENT NAME PENDING CONTRACT]
The problem
- Double-bookings erode utilization — the shared-equipment slot is regularly overbooked
- After-hours requests are hand-transcribed the next morning, errors included
- Cancellation gaps are never proactively backfilled
What we deployed
A Scheduling Agent running our standard loop, wired through:
- a calendar provider adapter — swappable without core agent changes
- hard guardrails in code, not in the prompt: business hours, weekday policy, slot grid, overlap/double-booking rejection — each rejection carries an explicit machine-readable reason
- a counter-offer path: rejected requests get concrete alternative slots instead of a dead "no"
- instrumented lessons: repeated after-hours demand or slot conflicts surface capacity/self-serve-booking recommendations to the owner
Results framework (fill during/after pilot)
| Metric | Before | After | Source |
|---|---|---|---|
| Double-bookings reaching the calendar | [PILOT DATA] | [PILOT DATA] | calendar audit log |
| % requests resolved without staff touch | — | [PILOT DATA] | agent outcome records |
| Rejections converted via counter-offer | — | [PILOT DATA] | outcome records |
| Front-desk hours freed / week | — | [PILOT DATA] | client timesheets |
| Cost per processed booking | [PILOT DATA] | [PILOT DATA] | token ledger |
Why the guardrails matter
In scheduling, a confident wrong answer is worse than no answer. Booking policy lives in deterministic code the language model cannot override — the LLM interprets the request; the guardrails decide whether it can execute. Every booking is attributable to a request ID, a guardrail verdict, and a loop cycle.
Lessons learned section
[POST-PILOT: list top 3 lessons from data/loops/<project>/ — real ones, verbatim.]