Sprintbot — gestión ágil con IA
Plataforma de gestión de proyectos con 6 vistas, métricas ágiles y un asistente de IA propio.
- Año
- 2025
- Rol
- Desarrollo individual (full-stack)
Acerca del proyecto
Plataforma de gestión de proyectos en el espíritu de Jira o Linear: Kanban, tabla, calendario, Gantt, outliner y un canvas de dependencias (Blueprint) con React Flow, auto-layout y cálculo de ruta crítica. Incorpora sprints con burndown y velocity, colaboración en tiempo real, PWA con modo offline, y un asistente de IA propio (Sage) construido sobre un pipeline de orquestación con @google/genai: enrutado por intención, expertos especializados, decenas de flujos (briefings, alertas predictivas, retrospectivas) y memoria de corto y largo plazo. Arquitectura multi-workspace con roles y permisos. Proyecto personal con el que aprendí a construir SaaS de extremo a extremo.
Vista previa

Estudio de caso
Darle a un agente de IA permiso para crear, editar y borrar datos reales en una app multi-tenant es la parte fácil. La difícil —y la que importa— es contener lo que puede hacer cuando se equivoca, lo abusan o se desboca en costo.
- Jul 2025 → Jun 2026
- de prototipo a producción
- 41
- tools con RBAC + Zod
- 50K tok
- techo de tokens por conversación
- ~1.9K
- casos de prueba automatizados
El problema
Sprintbot incluye a Sage, un asistente que ejecuta acciones reales por lenguaje natural: crea tareas, edita proyectos, borra notas. Eso significa darle a un modelo, que a veces alucina, la llave de los datos de producción de varias organizaciones a la vez. Tres riesgos concretos: que un error del modelo corrompa datos, que un usuario cruce de un workspace a otro, y que una conversación larga dispare el costo de tokens sin techo.
La arquitectura
La respuesta no fue un framework de agentes, sino un pipeline propio en capas, cada una con un trabajo de contención. Un router barato —un modelo lite, más reglas que resuelven los intents comunes sin gastar una llamada al LLM— clasifica la intención antes de tocar el modelo caro. Un agent loop multi-turno acotado a 5 iteraciones y 50.000 tokens, que al agotar el presupuesto fuerza una respuesta de solo texto en vez de seguir gastando. Un registro de 41 herramientas donde cada llamada pasa por validación de esquema (Zod), permisos por rol (RBAC) y un envoltorio de resiliencia (reintentos con backoff, circuit-breaker, timeout). Y confirmación humana explícita antes de cualquier acción destructiva.
El tradeoff
Construir el loop, la capa de resiliencia y la conversión de esquemas a mano —en vez de adoptar un framework— es más código propio que mantener. Lo elegí a conciencia: me dio control total sobre el presupuesto de tokens, sobre el flujo de confirmaciones, y una forma de resolver una incompatibilidad real entre el JSON Schema que emite Zod (draft-04) y el que espera la API de Gemini (draft 2020-12). El costo es mantenimiento; la ganancia es que ninguna pieza es una caja negra cuando algo falla en producción.
El resultado
Sage está en producción. Lo más revelador no fue que funcionara, sino lo que encontré al auditarme: el endpoint del agente autenticaba al usuario pero no verificaba que perteneciera al workspace solicitado —y como las herramientas corren con privilegios de administrador que saltan las reglas de Firestore, eso abría la puerta a cruzar datos entre organizaciones. Lo cerré, escribí el modelo de amenaza en el propio commit, y registré el resto de la auditoría con trazabilidad por hallazgo: lo corregido, lo deferido como deuda conocida, y su plan de migración por fases. Documentar el riesgo que queda en vez de fingir que no existe es, para mí, la diferencia entre construir con IA y construir con criterio.