MiamiFlow — un CRM de estudio de danza gestionado por cuatro agentes de AI

El problema

Un estudio de danza se mueve a base de cien pequeñas operaciones: onboardear padres, vender abonos, perseguir pagos, reservar alquiler de salas, marcar asistencia y responder las mismas preguntas todo el día. Casi todo eso cae sobre uno o dos administradores haciendo trabajo repetitivo en el chat y en planillas. MiamiFlow reemplaza esa rutina con un CRM de verdad — y pone cuatro agentes de AI en la primera línea para que de hecho hagan el trabajo, no solo lo registren.

Qué hace — cuatro agentes, cuatro trabajos

MiamiFlow está en producción para un estudio real, y cuatro agentes ReAct (tool-use) cargan con el trabajo de cara al cliente y operativo:

• Eva — un agente de Telegram para padres y estudiantes. Onboardea nuevos clientes, crea perfiles de niños, los inscribe en grupos, vende abonos y responde preguntas sobre horarios, precios, reglas y entrenadores. Emite códigos QR de pago e incluso lee capturas de pago para emparejarlas con la factura correcta — y luego le pasa la posta a un administrador humano para verificar y activar. Voz cálida y fiel a la marca.
• Anna — un agente de chat web para la recepción. En lugar de hacer clic por formularios, el personal simplemente le dice a Anna lo que necesita: registrar un pago, cambiar un abono, buscar un estudiante, escribirle a un grupo — y ella convierte el lenguaje natural en las operaciones correctas a lo largo del CRM.
• Maya — el copiloto de gestión del administrador. Preguntale cómo van la asistencia, las finanzas, las deudas o el horario, y saca los números y actúa a lo largo de toda la escuela a través de un amplio set de tools ReAct — reportes, finanzas, horario, entrenadores y más.
• Vika — un segundo agente de Telegram dedicado a vender alquiler de salas: chequear disponibilidad, cotizar un precio y reservar la sala.

Alrededor de los agentes hay una superficie de administración completa — facturas, abonos, registros de asistencia, finanzas y deudas, ganancias de entrenadores, descuentos, competencias, ubicaciones, monitoreo de agentes y seguimiento del costo de LLM.

Qué construí

En solitario, de principio a fin: el backend en FastAPI (limpiamente dividido en API, servicios, modelos y los agentes con sus tools), la app de administración en Next.js + TypeScript con decenas de pantallas, dos bots de Telegram, la base de datos y las migraciones, y los agentes en sí.

Los agentes son bucles ReAct reales con tools tipadas — cada capacidad (inscribir a un niño, vender un abono, cobrar un pago, reservar un alquiler, buscar en los documentos del estudio, sacar un reporte de asistencia) es una tool que el modelo puede invocar. Maya, la asistente del administrador, transmite su razonamiento y sus llamadas a tools por SSE, así el personal puede verla trabajar en lugar de esperar a una caja negra.

Decisiones arquitectónicas

Un gateway LLM propio. Cuando tres agentes y dos bots llaman a un modelo a la vez, te chocás con los límites de tasa del proveedor y perdés requests en silencio (HTTP 429). Por eso construí LLM Gate — un proxy interno, compatible con OpenAI, entre las apps y los proveedores (OpenRouter, Groq) que hace rate limiting, encolado de requests, priorización y circuit breaking. Apuntar cualquier servicio hacia él es un cambio de una línea en base_url. Es la capa de resiliencia que mantiene a los agentes confiables bajo carga concurrente real.

Model-agnostic por diseño. Cada llamada al LLM pasa por el gateway sobre OpenRouter, así que el modelo es un ajuste — rápido y barato por defecto, intercambiable por Claude, GPT u otro modelo sin tocar el código de los agentes. El mismo punto que repito siempre: nunca te cases con un solo modelo.

Human-in-the-loop donde se mueve el dinero. La venta está automatizada; confirmar el pago no. Eva reconoce una captura de pago y la adjunta a la factura, pero un administrador humano la verifica y activa el abono. Las acciones sensibles e irreversibles están deliberadamente reservadas a una persona.

Costo y comportamiento que podés ver. Logging y precio por cada llamada al LLM más una vista de monitoreo de agentes significan que el estudio puede ver qué hacen los agentes y cuánto cuestan. La observabilidad está integrada, no atornillada por encima.

Arquitectura limpia, con tests. FastAPI con SQLAlchemy y migraciones de Alembic, Redis, un backend en capas con agentes y tools limpiamente separados, suites de tests end-to-end / de performance / de seguridad, dockerizado y desplegado en Railway.

Estado actual

MiamiFlow está en vivo en producción en miamistudio.org, llevando el día a día de un estudio real — clientes reales, facturas reales, dinero real. Lo construí en solitario, dirigiendo agentes de AI contra una especificación por etapas mientras era dueño de la arquitectura, el diseño de los agentes y la revisión. Es el ejemplo más completo de eso que sigo defendiendo: agentes de AI que no solo charlan, sino que de hecho hacen el trabajo — de forma segura, observable y en producción.