Swim School Multi-Agent System
A solo swim instructor used to spend two weeks building each season's schedule by hand and write every parent email herself. Now she asks for a schedule in plain English, reviews it, and approves drafted emails. She stays in control of every decision.
Explore the Gamma audience adaptation ↓
in a summer season
+ her review
drafted, never auto-sent
spread or consolidate
the problem
Jayne runs Lakeway Swim School alone: one instructor, one pool, one class at a time. A summer season means about 550 kids across multiple sessions and four skill levels, and she scheduled every one of them by hand. She worked out each child's level from the registration form, matched their session preferences and time restrictions, and kept siblings back-to-back. Then she wrote to every family herself at every step, from registration through final payment.
- Levels worked out by reading each registration form
- Sessions, time restrictions, and siblings juggled by hand in a spreadsheet
- Every confirmation, reminder, and payment nudge typed from scratch
- Any change, like a rained-out class, meant working out who to tell
- Levels assigned from the form's skills checklist
- A solver places every child it can and flags anything it can't
- A visual summary instead of a raw spreadsheet: classes, fill, revenue, waitlist
- Parent emails drafted from templates; she sends them from her own Gmail
how it's orchestrated
Jayne talks to one thing: a Claude skill. It works out what she's asking for and hands the work to one of two specialists. Each specialist can only touch its own inputs and outputs, and everything that reaches a parent stops at her first.
Jayne, in plain English
"Build the fall schedule, consolidate mode." · "Cancel tonight's 6pm Guppy class, thunderstorm."
Orchestrator (Claude skill)
Classifies the request, asks the one question it needs (spread or consolidate? a whole session or one class?), and routes it. It never makes up a rule or a roster.
Scheduling engine
Plain Python with a CP-SAT solver. No language model involved. The same inputs always give the same schedule.
Comms agent
Picks the right template for the touchpoint, or writes a custom draft in Jayne's voice. It works only from the approved roster, so each email goes to the right families, one per family.
Human gate. Jayne reviews the schedule's flags before anything else, then reads every draft. Nothing goes out on its own. She sends from her own Gmail.
one engine, any season
Session dates, time slots, class sizes, and prices live in an Availability workbook, not in code. The same engine runs spring, summer, and fall. Jayne picks how the week should feel:
Spread
Classes spread across the available slots, so she has breathing room between them.
Consolidate
Classes packed into tight back-to-back blocks, so her pool time is compact.
Jayne's own rules ("no earlier than 5pm", "same class as Maya", "Session 2 only") use a small fixed vocabulary. The engine enforces them exactly. If it can't parse one, it doesn't guess: the child is pulled out of the automatic run and flagged for her to place by hand.
what Jayne actually sees
The engine writes a spreadsheet, but Jayne never has to open it. Every run also produces a one-page summary: totals up top, one row per class, and the flags she needs to check before anything else.
16 touchpoints, zero auto-sends
A season is a long conversation with every family. The comms agent covers all of it, using a template when the message is routine and a custom draft when the situation calls for one.
- Registration received
- Schedule confirmation
- Deposit confirmation
- Final payment reminder
- Paid in full
- R&R form
- What to bring
- Weather cancellations
- Schedule changes
what it looks like
A weather cancellation shows the design best. Weather usually knocks out one class, not a whole multi-week session, so the system confirms the scope first. It then drafts only for the families actually in that class, and it names anyone it can't reach instead of silently leaving them out.
what I learned
Trust didn't move in one direction. Jayne reviewed every output closely for the first several weeks, then started approving comms drafts with minimal review. A few weeks after that, she began catching errors she'd missed in the middle stretch. Over-trust turned out to be as real a failure mode as under-trust, and it showed up on a predictable schedule.
The single highest-leverage change wasn't a smarter model. It was adding one line to every approval request explaining why the system had flagged it. That improved review quality more than anything on the model side.
And the most important design choice was deciding what the model shouldn't do. Scheduling is a constraint problem, so a solver handles it. Sending is a trust problem, so a human handles it. Claude sits between the two: it takes the request, explains the result, and writes the words.
Adapting the story for its audience
Creating slides is my happy place. I used Gamma to tell this swim-school story to two different readers: one interested in how I built the tool, and the nontechnical owner who needed to understand what she would get, what to check, and which decisions still needed her input.
The previous and new version comparison was my favorite part. I loved seeing the layout stay the same while the storytelling changed for the reader.
Card 3: from the build process to the owner's outputs
The four-part circle stayed in place. Understand, Explore, Simplify and Iterate became Class assignments, Fill, Revenue and Flags. The same visual now explained the outputs the owner would review.
Card 6: from a design lesson to review questions
The photograph, text placement and yellow callout stayed familiar. A lesson about making decisions visible became questions about flagged requests, schedule review and tracking results. Human validation stayed in the workflow; unresolved operating details stayed as questions.
Matched screenshots captured on 7 October 2026. Select any image to inspect it at full size.
For me, the useful product idea is audience adaptation with a visible comparison. It lets me judge whether a new version keeps the facts and gives its reader the information they need.
This is a qualitative observation from two versions of one deck. No Gamma time savings were measured. The $4,000 additional school revenue and turnaround reduced from two weeks to one week are results of the underlying swim-school scheduling tool. They are not results attributed to Gamma.