MiamiFlow — a dance-studio CRM run by four AI agents

The problem

A dance studio runs on a hundred small operations: onboarding parents, selling subscriptions, chasing payments, booking hall rentals, marking attendance, and answering the same questions all day long. Almost all of it lands on one or two admins doing repetitive work in chat and spreadsheets. MiamiFlow replaces that grind with a real CRM — and puts four AI agents on the front line to actually do the work, not just record it.

What it does — four agents, four jobs

MiamiFlow is live in production for a real studio, and four ReAct (tool-use) agents carry the customer-facing and operational load:

• Eva — a Telegram agent for parents and students. She onboards new clients, creates child profiles, enrolls them in groups, sells subscriptions, and answers questions about schedule, prices, rules, and trainers. She issues payment QR codes and even reads payment screenshots to match them to the right invoice — then hands off to a human admin to verify and activate. Warm, on-brand voice.
• Anna — a web-chat agent for the front desk. Instead of clicking through forms, staff just tell Anna what they need: register a payment, change a subscription, look up a student, message a group — and she turns plain language into the right operations across the CRM.
• Maya — the administrator's management copilot. Ask her how attendance, finances, debt, or the schedule look, and she pulls the numbers and acts across the whole school through a broad ReAct toolset — reports, finances, schedule, trainers, and more.
• Vika — a second Telegram agent dedicated to selling hall rentals: checking availability, quoting a price, and booking the room.

Around the agents sits a full admin surface — invoices, subscriptions, attendance journals, finances and debt, trainer earnings, discounts, competitions, locations, agent monitoring, and LLM cost tracking.

What I built

Solo, end to end: the FastAPI backend (cleanly layered into API, services, models, and the agents with their tools), the Next.js + TypeScript admin app with dozens of screens, two Telegram bots, the database and migrations, and the agents themselves.

The agents are real ReAct loops with typed tools — each capability (enroll a child, sell a subscription, take a payment, book a rental, search the studio docs, pull an attendance report) is a tool the model can call. Maya, the admin assistant, streams her reasoning and tool calls over SSE, so staff can watch her work rather than wait on a black box.

Architectural choices

A custom LLM gateway. When three agents and two bots all call a model at once, you hit provider rate limits and silently lose requests (HTTP 429). So I built LLM Gate — an internal, OpenAI-compatible proxy between the apps and the providers (OpenRouter, Groq) that does rate limiting, request queuing, prioritization, and circuit breaking. Pointing any service at it is a one-line base_url change. It's the resilience layer that keeps the agents dependable under real concurrent load.

Model-agnostic by design. Every LLM call goes through the gateway over OpenRouter, so the model is a setting — fast and cheap by default, swappable to Claude, GPT, or another model without touching agent code. The same point I keep making: never marry one model.

Human-in-the-loop where money moves. Selling is automated; confirming payment is not. Eva recognizes a payment screenshot and attaches it to the invoice, but a human admin verifies it and activates the subscription. Sensitive, irreversible actions are gated to a person on purpose.

Cost and behaviour you can see. Per-call LLM logging and pricing plus an agent-monitoring view mean the studio can see what the agents are doing and what they cost. Observability is built in, not bolted on.

Clean architecture, tested. FastAPI with SQLAlchemy and Alembic migrations, Redis, a layered backend with agents and tools cleanly separated, end-to-end / performance / security test suites, Dockerized and deployed on Railway.

Current status

MiamiFlow is live in production at miamistudio.org, running a real studio's day-to-day — real clients, real invoices, real money. I built it solo, directing AI agents against a staged spec while owning the architecture, the agent design, and the review. It's the most complete example of the thing I keep arguing for: AI agents that don't just chat, but actually do the work — safely, observably, and in production.