Swim School Multi-Agent System
A real multi-agent system running a real small business, deployed for an instructor who had never used anything more technical than a spreadsheet, and documented as a longitudinal study in how trust in AI actually forms.
Apr 2026 – present
4 worker agents
on every write
every decision
the problem
Small service businesses (swim schools, tutoring, fitness studios) lose 30-40% of operating time to coordination work: scheduling, parent communication, payment follow-up, weekly reporting. It's exactly the kind of repeatable, judgment-adjacent workflow enterprise AI programs are trying to automate at scale, just easier to observe and document at fifty-student scale than at hundred-thousand-user scale.
the approach
Orchestrator/worker architecture: a coordinator agent routes requests to four single-purpose agents (scheduling, comms, payments, reporting), each scoped to its own tool set so it can't act outside its domain. Every irreversible action, anything that emails a parent or changes a published schedule, stops at a human approval gate before it executes.
Scheduling logic deliberately does not run through the model. Qualification, slot assignment, and constraint-checking (siblings scheduled back-to-back, capacity limits, arrival-time rules) run in plain Python, because a constraint-satisfaction problem doesn't need a language model guessing at it. The model's job is the conversational review loop: explaining the schedule, taking adjustment requests, not generating the schedule itself.
what shipped
A weather-cancellation flow is the clearest example of the design in practice: the instructor says "cancel Saturday, thunderstorm warning," the scheduling agent marks the session cancelled, updates the roster, and generates makeup-slot options; the comms agent drafts a parent notification using those options with tone matched to the situation. Nothing sends until the instructor approves. Every agent action is logged with what was requested, what it did, and why, not just for debugging, but so the system can explain itself to someone who didn't build it.
what I learned
Trust didn't move in one direction. The instructor 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. Review quality improved more from that than from anything on the model side.