Por qué separé mi agencia en orquestador + ejecutores (y cómo te cambia el juego)

El error que cometen todos al empezar con agentes IA

Cuando descubrís que podés darle instrucciones complejas a un modelo de IA, la tentación natural es construir un agente que haga todo. "Vos sos mi asistente. Diseñá, desarrollá, respondé emails, llevá la contabilidad, manejá las redes sociales."

El problema no es la ambición. El problema es que ese enfoque no escala. Y el motivo es técnico: un agente que hace todo necesita cargar todo el contexto de todo. Cada decisión de diseño, cada línea de código, cada conversación con cada cliente, cada número de cada factura. El contexto explota, la calidad baja, y terminás con un agente mediocre en todo.

La solución es un patrón que usamos en gestión empresarial hace décadas, pero que tardamos en aplicar a sistemas de IA: separar quién decide de quién ejecuta.

---

La analogía que lo explica todo: el CEO y su equipo

El CEO de una empresa no escribe el código, no diseña las piezas gráficas, no atiende al cliente en el chat de soporte. El CEO define la dirección, asigna recursos, toma decisiones de alto nivel y coordina que los especialistas correctos estén trabajando en las cosas correctas.

Si el CEO empezara a hacer el trabajo técnico directamente, dejarían de pasar dos cosas importantes: primero, el trabajo técnico sería mediocre (porque el CEO no es el experto). Segundo, la coordinación estratégica se perdería (porque el CEO estaría demasiado en el detalle).

JARVIS funciona exactamente igual. JARVIS es el CEO del sistema. Nunca escribe una línea de código. Nunca genera una imagen. Nunca redacta un post. JARVIS decide:

• ¿Qué agente es el más adecuado para esta tarea?
• ¿Qué contexto necesita ese agente para trabajar bien?
• ¿Cuántos tokens puede gastar (token economics)?
• ¿En qué orden deben ejecutarse las tareas cuando hay dependencias?
• ¿Cómo se sintetizan los resultados de múltiples agentes?

Todo lo demás lo hacen los ejecutores: Trinity para diseño, Neo para desarrollo, Morpheus para contenido, y así con cada uno de los 11 agentes del equipo.

---

Por qué el contexto aislado es el superpoder del sistema

Acá está la parte técnica que más diferencia hace en la práctica.

Cuando Neo está construyendo un componente React, no necesita saber nada del brief de branding que Trinity está procesando. No necesita conocer el estado del pipeline de ventas de Niobe. No necesita leer las últimas métricas financieras de Oracle.

Cada agente recibe exactamente el contexto que necesita para su tarea y nada más. Esto tiene tres consecuencias directas:

1. Calidad más alta

Un agente con contexto limpio y específico produce outputs mejores que un agente generalist con contexto saturado. Es el mismo principio que hace que un especialista sea mejor que un generalista en tareas técnicas complejas.

2. Costo más bajo

Los modelos de IA cobran por token de entrada y salida. Un agente que carga todo el contexto de la empresa en cada llamada consume 10 veces más tokens que uno que carga solo lo que necesita. Con 11 agentes activos, esa diferencia se convierte en cientos de dólares por mes.

3. Errores contenidos

Si Neo comete un error en un componente, ese error no contamina el trabajo de Trinity ni el de Morpheus. Cada agente es un sistema independiente. Los fallos son locales, no sistémicos.

El contexto aislado no es una limitación del sistema. Es una feature de diseño. Un agente que sabe todo no es más inteligente — es más difícil de controlar.

---

El protocolo de comunicación entre agentes

Si los agentes tienen contexto aislado, ¿cómo se pasan información entre sí? Esa es la pregunta correcta, y la respuesta es el protocolo de comunicación que define el orquestador.

Cuando JARVIS delega una tarea a Neo, no le dice "mirá todo lo que pasó en el proyecto". Le dice exactamente lo que necesita:

• El objetivo específico de la tarea
• El contexto relevante (solo el necesario)
• Las restricciones (tech stack, patrones, convenciones)
• El formato esperado del output

Cuando Neo termina, devuelve el resultado a JARVIS, que lo sintetiza y decide qué pasa después: ¿se lo pasa a Ghost para auditoría? ¿Se lo pasa a Seraph para documentación? ¿Se publica directo a producción?

Este protocolo tiene un nombre en el mundo SDD (Spec-Driven Development) que uso en mis proyectos: el result contract. Cada agente sabe que tiene que devolver su resultado en un formato específico que el orquestador puede procesar. Sin eso, el sistema no escala.

---

Las ventajas concretas que noté en producción

Después de más de un año trabajando con este sistema, las ventajas que más siento en el día a día son estas:

Paralización real de tareas

JARVIS puede lanzar Trinity y Neo al mismo tiempo en el mismo proyecto. Trinity trabaja en los assets visuales mientras Neo construye los componentes del frontend. No se molestan. No se contradicen. Al final, JARVIS integra los dos outputs.

Especialización que se nota en la calidad

El código de Neo es mejor que el de un agente generalista porque Neo solo hace código. El copy de Morpheus es mejor porque Morpheus solo hace contenido. La especialización que aplica en equipos humanos aplica igual en equipos de agentes.

Escalabilidad sin complejidad lineal

Si mañana necesito un nuevo tipo de tarea (digamos, análisis de datos avanzado), agrego un nuevo agente especializado sin tocar los otros 11. El orquestador aprende a incluirlo en los workflows relevantes. La complejidad crece de forma modular, no exponencial.

Debuggeo localizado

Cuando algo sale mal, sé exactamente dónde buscar. Si el output de diseño no es lo que esperaba, es un problema de Trinity. Si el código tiene un bug, es un problema de Neo. No tengo que adivinar en un sistema monolítico cuál de las 50 responsabilidades del "agente único" falló.

---

Cuándo este patrón NO aplica

No todo necesita un orquestador. Si tenés una tarea simple y única, un agente directamente es más eficiente. El overhead del orquestador (la capa de decisión y coordinación) agrega latencia y costo que no vale la pena para tareas atómicas.

El patrón orquestador + ejecutores aplica cuando:

• La tarea tiene múltiples pasos con dependencias
• Se pueden ejecutar sub-tareas en paralelo
• Se necesitan diferentes tipos de expertise en el mismo proyecto
• El volumen de trabajo justifica la inversión en arquitectura

Para un proyecto chico de una semana, probablemente no lo necesitás. Para un negocio que quiere escalar operaciones sin escalar el equipo humano de forma lineal, es el camino.

---

¿Querés que diseñemos el sistema para tu empresa?

Cada negocio tiene sus propios cuellos de botella y sus propios flujos de trabajo. El sistema que construí para mi agencia no es el mismo que construiría para una empresa de e-commerce, una fintech o un estudio legal.

Si querés explorar cómo aplicar este patrón a tu operación, arranquemos con una conversación. Sin venta de humo: si tiene sentido para tu caso, lo construimos. Si no, te lo digo directo.

Escribime a @MickaelDesigner en Instagram o desde el formulario en mickaelvasquez.tech.