JOTA Flow Studio: cómo orquestamos agentes de IA para construir software sin perder el control

El problema con los agentes de IA

Todos los días aparece una herramienta nueva que promete que un agente 'construye software por vos'. La realidad es otra: sin supervisión, los agentes de IA generan código rápido y sucio que después hay que reescribir. Sin estructura, se pierden en contextos enormes. Sin gates de aprobación, hacen cosas que no quisiste.

El problema no es la IA. El problema es la falta de arquitectura.

Así que diseñamos la nuestra.

JOTA Flow Studio: la arquitectura

JOTA Flow Studio es el sistema de orquestación que armamos en Buenas Ideas para que agentes de IA construyan software de calidad, bajo control humano, sin quemar dinero en APIs caras.

La clave: no es un producto que vendemos. Es la forma en que nosotros trabajamos. Y decidimos documentarlo para que otros puedan usarla o adaptarla.

Componentes

• Harold — Agente orquestador principal. Recibe requerimientos en lenguaje natural, coordina el flujo completo, toma decisiones de arquitectura y presenta resultados a los humanos en cada gate de aprobación.
• The Machine — Agente especializado en ejecución. Recibe tareas estructuradas con pasos claros, implementa código, commitea en branches, ejecuta tests. Opera en background sin consumir la atención de Jorge.
• OpenCode — Agente de revisión especializado. Usado como 'segundo par de ojos' para tareas específicas: explorar código desconocido, hacer code review, o desglosar tareas complejas en steps ejecutables.
• TaskFlow — Capa de persistencia que hace que todo sea durable: si el sistema se reinicia, el trabajo no se pierde. Cada fase tiene estado, cada decisión se registra.

Modelos que usamos

Todos los modelos corren localmente via Ollama. No gastamos dinero en APIs externas para coding.

• gemma3:latest — modelo principal de razonamiento (local, ~4GB)
• qwen2.5-coder:latest — especializado en código (18GB local)
• codestral:latest — segundo modelo de código (12GB local)
• minimax-m2.7:cloud — modelo principal de razonamiento (cloud Ollama, fallback para tareas complejas)
• glm-5.2:cloud — modelo secundario (cloud Ollama, fallback para tareas complejas)

El flujo: 6 fases

Fase 1 — Input: Jorge describe el requerimiento en lenguaje natural. No necesita saber cómo se hace. Solo describe qué necesita.

Fase 2 — Análisis: Harold investiga, busca documentación relevante en el codebase, explora el código existente relacionado, detecta dependencias y riesgos técnicos.

Fase 3 — Planificación: Harold genera un plan estructurado con pasos específicos, archivos a modificar, tests a ejecutar, riesgos identificados.

Fase 4 — Implementación: The Machine recibe el plan aprobado y ejecuta. Crea feature branch, implementa cambios, ejecuta tests, commitea cada milestone.

Fase 5 — Code Review: OpenCode revisa el código generado, detecta code smells, encuentra potenciales bugs, sugiere mejoras de performance.

Fase 6 — Validación: Tests unitarios, de integración, E2E con Playwright, security scan y smoke tests contra staging.

Lo que lo hace diferente

• Sin costo de API para coding — todos los modelos de coding corren local
• Gates de aprobación en cada transición — el agente nunca avanza solo
• Persistencia con TaskFlow — si Harold se reinicia, el trabajo no se pierde
• Especialización de agentes — cada uno tiene su modelo optimizado para su tarea
• Branch siempre — The Machine nunca toca main

Guía de implementación

Para los que quieran implementarlo, tenemos una guía paso a paso completa en PDF que cubre setup de cada componente, configuración de modelos locales con Ollama, scripts de integración y automatización, guía de troubleshooting y mejores prácticas para cada fase.