Sistema multi-agente de desarrollo de producto

Construyo sistemas multi-agente para flujos de producto e ingeniería. Este es el que uso a diario: un orquestador recibe una intención de producto, la rutea a agentes con roles definidos, y nada llega a producción sin aprobación humana explícita.

Un asistente de código resuelve el paso que le pides. No decide qué se construye, no mantiene coherencia entre la especificación y lo implementado, y no sabe cuándo detenerse. El resultado es velocidad local sin avance real: mucho código generado, poca convergencia hacia un producto.

Práctica propia de I+D, no un encargo de cliente. Nace de una molestia concreta: usar asistentes de código uno a uno funciona para tareas sueltas, pero no sostiene un ciclo completo de producto — especificar, diseñar, construir, verificar.

• Yo mismo, como ingeniero que ejecuta el ciclo completo de sus propios productos.
• El sistema aplicado a Academy Manager, Fintru y a este propio sitio.

• Presupuesto real de tokens: cada paso cuesta, así que el routing tiene que evitar trabajo innecesario, no maximizar agentes.
• Sin equipo que revise: el sistema debe fallar de forma visible, no degradar en silencio.
• Los productos tocan dinero (Fintru) y datos de menores (Academy Manager): hay límites que ningún agente cruza sin aprobación.

El sistema se diseñó por fronteras de responsabilidad, no por capacidades del modelo. Cada agente existe porque hay una decisión distinta que tomar, no porque se pueda dividir el trabajo. Si dos agentes toman la misma decisión, sobra uno.

• Un orquestador, no una cadena fija: el routing depende de la intención, y una petición pequeña no paga el coste de recorrer todos los roles.
• Salidas estructuradas obligatorias entre agentes. La prosa se permite solo en la frontera con el humano.
• Un único gate humano, antes de producción. Aprobar cada paso mata el leverage; no aprobar ninguno mata la confianza.
• Los reintentos son acotados y explícitos. Un agente que reintenta indefinidamente convierte un fallo barato en una factura cara.
• Sin memoria persistente entre ejecuciones no relacionadas: el contexto se construye por tarea. La memoria global suena potente y en la práctica contamina.

El orquestador es el único componente con estado de la ejecución: conoce la intención, decide el routing, arma el contexto de cada agente y consolida las salidas. Los agentes son sin estado — reciben su contexto completo en cada llamada, lo que los hace reintentables y testeables por separado. Las tools (lectura de repositorio, escritura de ficheros, ejecución de tests, consultas) se declaran por rol: un agente de producto no tiene permiso de escritura.

Es el objeto del caso, no una ayuda lateral: orquestación, routing por intención, context engineering, tool calling con permisos por rol, structured outputs, reintentos acotados, human-in-the-loop y trazas por ejecución para poder reconstruir por qué el sistema decidió lo que decidió.

• Context engineering: pasar el estado suficiente sin arrastrar toda la historia. El contexto que sobra no es neutro — degrada la salida y multiplica el coste.
• Fallos de herramienta frente a fallos de razonamiento: se parecen en el log y se arreglan de forma opuesta. Separarlos exigió tipar los errores en la frontera de cada tool.
• Evaluación más allá de «funcionó»: verificar que lo implementado corresponde a lo especificado, no solo que compila.
• Observabilidad: sin trazas por paso, un sistema multi-agente es una caja negra que a veces acierta.
• Coste y latencia: cada agente añadido tiene que justificar su precio en calidad de salida, no en elegancia de arquitectura.

• Ciclo completo especificación → implementación → verificación operado por el sistema, con aprobación humana antes de producción.
• Academy Manager, Fintru y este sitio construidos con él.
• Trazas por ejecución que permiten reconstruir el razonamiento de una decisión.
• Permisos por rol: los agentes sin responsabilidad de escritura no pueden escribir.

• El cuello de botella de un sistema agentic no es el modelo: es el diseño del contexto y de las fronteras.
• Human-in-the-loop es una decisión de producto —dónde pones el gate—, no un patrón de AI que se activa.
• Un agente que no puede fallar de forma visible no está listo para trabajo real.
• Más agentes no es más capacidad. Cada uno debe existir por una decisión distinta.