Playbook de orquestación de agentes

Un super-agente que lo hace todo es frágil. Lo que escala es una orquesta: agentes especializados, cada uno con un trabajo, coordinados por una sola figura. Este playbook es cómo se monta esa orquesta sin que se convierta en ruido.

El principio: topología en estrella

• Hay un orquestador (la persona, o el agente que ella controla) y N agentes temáticos.
• Cada agente se nutre del sistema (el vocabulario, las reglas) pero no habla con los demás.
• Toda coordinación pasa por el orquestador. Los agentes no se llaman entre ellos.

¿Por qué? Porque agentes que se hablan libremente derivan: se contradicen, se realimentan, y nadie sabe quién decidió qué. La estrella mantiene la traza y la responsabilidad en un punto.

Los cuatro papeles

1. El orquestador. Decide qué agente hace qué, en qué orden, y responde del resultado. Es el único que habla con el middleware y con cada agente.
2. Los agentes temáticos. Uno por dominio: UI, copy, accesibilidad, datos. Cada uno hace una cosa y la hace bien.
3. El middleware. La capa que conecta. El orquestador define dónde se conectan las piezas; no construye el backend, define las juntas.
4. El humano que firma. Puedes delegar la ejecución; no la rendición de cuentas.

La secuencia

1. Descompón la tarea en trabajos de un solo dominio. Si un agente necesita dos competencias, divídelo.
2. Escribe el contrato de cada agente: qué recibe, qué devuelve, qué no le toca.
3. Define el orden y los puntos de control. Después de cada agente, una validación antes de pasar al siguiente.
4. Pon una escalera de autonomía: qué puede hacer un agente solo, qué requiere visto bueno, qué nunca.
5. Mide por agente: fidelidad, descarte, reintentos. Un agente que reintenta mucho está mal contratado.

Los anti-patrones

• Agentes que se hablan entre ellos. Pierdes la traza. Todo por el orquestador.
• Un agente para todo. Imposible de evaluar y de depurar. Especializa.
• Sin punto de control entre pasos. Un error temprano se amplifica en cada agente siguiente.

Orquestar bien no es saber de IA: es saber de diseño de sistemas. Quién decide, quién ejecuta, dónde se valida y quién responde. La IA solo cambia quién hace el trabajo manual.