Cómo estructurar un equipo de agentes de IA para automatizar tu operación

Un equipo de agentes de IA no se vuelve más confiable por tener más agentes. La arquitectura que importa es un orquestador que decide y valida, acompañado por ejecutores con responsabilidades acotadas. Sin esa separación, agregar modelos solo multiplica el contexto perdido, los archivos pisados y los errores difíciles de rastrear.

En Ignicionlab usamos esta metodología para pensar sistemas de desarrollo y automatización: una entrada única para pedir trabajo, agentes especializados para ejecutarlo y señales explícitas para saber qué ocurrió. El objetivo no es quitar a las personas del proceso. Es sacar de la conversación principal la coordinación mecánica para reservar el criterio humano y técnico para las decisiones que sí lo necesitan.

El flujo completo: el orquestador coordina la tarea y valida el resultado a través de estados observables.

El patrón supervisor resuelve el problema de coordinación

El patrón supervisor separa dos preguntas que suelen mezclarse: qué debe hacerse y cómo se ejecuta. El orquestador recibe el objetivo, lo divide en subtareas, decide quién puede resolver cada una y reúne los resultados. Los ejecutores no reciben el proyecto completo como una conversación interminable; reciben una tarea concreta con límites claros.

Esto sirve para desarrollo web, migraciones, generación de contenido estructurado, pruebas y automatizaciones internas. Si una tarea exige cambiar la arquitectura de una aplicación, la toma un ejecutor orientado a código. Si exige transformar cientos de registros o redactar variantes con un formato fijo, la toma uno orientado a volumen.

La especialización tiene un costo. Un pipeline con varios agentes consume más tokens y requiere más coordinación que un chat único. Un análisis de patrones de orquestación en producción documenta precisamente ese intercambio. Divide el trabajo solo cuando las subtareas necesitan capacidades o criterios distintos.

Cada ejecutor necesita un contrato de trabajo

Un ejecutor genérico parece flexible, pero esa flexibilidad suele esconder instrucciones ambiguas. Para que un agente pueda trabajar sin la conversación original, su tarea debe incluir cinco elementos:

• Resultado esperado: qué archivo, cambio o reporte debe producir.
• Alcance: qué carpetas, sistemas o registros puede tocar.
• Criterios de aceptación: cómo se comprueba que terminó bien.
• Restricciones: qué no debe modificar y qué decisiones debe escalar.
• Señal de cierre: qué artefacto confirma que la tarea terminó.

Un ejemplo pobre sería “mejora el SEO del sitio”. Un contrato útil diría: “revisa los títulos y descripciones de estas diez páginas, no cambies el contenido visible, guarda un reporte con cada ajuste y marca como bloqueadas las páginas cuya intención no sea clara”. La calidad de la delegación determina el margen de error antes de que el modelo empiece a trabajar.

Este principio también aplica a un agente de IA para atención al cliente: no basta con que entienda lenguaje natural; debe saber qué información puede consultar, qué acción puede ejecutar y cuándo debe derivar el caso.

La conexión debe ser asíncrona y observable

Copiar un prompt de una ventana a otra puede servir para probar una idea. No sirve como operación diaria. El orquestador debe poder lanzar el ejecutor, seguir atendiendo la conversación principal y recibir una señal cuando el trabajo termine.

Para eso conviene tratar cada tarea como un proceso asíncrono: se inicia en segundo plano, se desacopla de la entrada interactiva y escribe su salida en una ubicación conocida. En un entorno tipo Unix, el patrón puede verse así:

# Lanzar un ejecutor sin depender de una entrada interactiva
codex exec --json -o "cola/salida/resumen-tarea.md" \
  -m <modelo> -c reasoning_effort=low \
  "Instrucción autocontenida de la tarea" \
  < /dev/null > "cola/log-proceso.log" 2>&1 &
disown

El mensaje “el proceso inició” no significa “la tarea terminó”. La diferencia parece obvia hasta que un sistema relanza un trabajo todavía activo porque alguien interpretó el primer evento como el segundo. El ejecutor debe tener logs propios y un archivo de salida final, mientras el orquestador observa esa señal acordada.

Una automatización confiable distingue inicio, progreso, éxito y error. Un indicador ambiguo —como la aparición de cualquier archivo nuevo— no alcanza porque puede representar un resultado parcial.

Una cola en disco evita que los agentes se pisen

El paralelismo solo ayuda cuando las tareas tienen fronteras. La forma práctica de marcarlas es una cola de trabajo en disco: cada encargo vive en un archivo autocontenido, pasa de pendiente a en-proceso y termina en hecho junto con su resumen.

El ejecutor procesa una tarea a la vez y nunca modifica el archivo que describe el encargo. El orquestador tampoco reencola una tarea solo porque tardó más de lo esperado. El estado debe vivir en el sistema de archivos, no en una suposición de la conversación.

Antes de lanzar dos tareas en paralelo, revisa tres cosas: que no escriban el mismo archivo, que no dependan de la salida de la otra y que cada una tenga una forma independiente de validarse. Si una tarea necesita el resultado de otra, no es paralela: es una cadena de pasos.

La misma disciplina aparece al implementar formularios inteligentes para filtrar contactos: primero se define qué dato entra, qué regla lo clasifica y qué resultado habilita el siguiente paso. Automatizar sin ese contrato solo acelera la confusión.

La memoria compartida debe tener una sola fuente de verdad

Cada agente necesita conocer convenciones del proyecto: nombres de carpetas, formatos, permisos, reglas de seguridad y criterios de entrega. Duplicar esas instrucciones en cada prompt crea versiones distintas de la misma realidad.

La solución es un documento de reglas versionado junto al proyecto, referenciado por ruta explícita. El orquestador y los ejecutores lo leen antes de actuar. Si cambia una convención, se actualiza un solo archivo y el cambio se propaga a todos los procesos que lo consulten.

Esto no significa meter toda la documentación del negocio en un prompt gigantesco. El contexto compartido debe contener reglas estables; el contexto de tarea debe contener decisiones temporales. Mezclarlos hace que cualquier cambio puntual parezca una regla permanente.

La validación sigue siendo responsabilidad del orquestador

Un ejecutor puede entregar un resumen convincente y aun así haber cambiado el archivo equivocado, omitido una ruta o dejado el build roto. Por eso el orquestador valida contra el proyecto real, no contra lo que el agente afirma haber hecho.

La comprobación depende del trabajo: ejecutar el build, revisar el diff, correr pruebas, abrir una página, comparar el número de registros o verificar que una integración responda. La validación debe estar definida desde el contrato inicial, no improvisarse cuando ya llegó el resultado.

También hay decisiones que no conviene delegar: publicar cambios irreversibles, modificar permisos, enviar mensajes a clientes o aceptar una excepción de seguridad. El patrón supervisor reduce coordinación, pero no convierte una acción de alto riesgo en una acción automática.

Para proyectos que evolucionan durante días, un tablero externo puede conservar la memoria de alto nivel: fase actual, decisiones, bloqueos y tareas terminadas. Un agente nuevo debería poder consultar ese estado sin reconstruirlo desde una conversación vieja.

Linear concentra el estado del proyecto en un tablero que cualquier agente puede consultar.

Qué implementar el lunes

Empieza con un flujo pequeño, no con una red de diez agentes:

1. Elige una tarea repetitiva con resultado verificable.
2. Escribe el contrato de trabajo en un archivo independiente.
3. Define una carpeta de pendiente, una de proceso y una de hecho.
4. Asigna un solo ejecutor y registra su log.
5. Haz que el orquestador valide el resultado antes de encadenar otra tarea.

No empieces por el modelo. Empieza por el estado, los límites y la prueba de que el trabajo quedó bien. Si ese flujo funciona con un ejecutor, entonces tendrás evidencia para decidir dónde la especialización adicional puede ahorrarte tiempo.

Si tu operación ya tiene tareas repetitivas y sistemas que necesitan conectarse, en desarrollo y automatización de sistemas podemos revisar un flujo específico y definir qué parte conviene orquestar.