Cuándo compensa dividir un sistema en varios agentes

Un equipo quiere revisar una integración antes de activarla. Hay que contrastar el contrato de la API, comprobar permisos y examinar cómo se recupera de los errores. Parte del trabajo puede hacerse a la vez. La decisión final depende de reunir los hallazgos sobre la misma versión del sistema.

Este ejemplo hipotético permite plantear la pregunta adecuada: ¿qué trabajo puede avanzar de forma independiente y quién se responsabiliza de combinarlo? Dibujar un agente para cada departamento no responde a ninguna de las dos.

Identifica una separación que se pueda probar

Revisa una ejecución real del sistema actual. Localiza tareas que puedan empezar con la misma información y terminar sin esperar a otra. Consultar fuentes distintas o revisar aspectos diferentes de un cambio son candidatos a trabajo paralelo.

Cuando un paso depende del anterior, conserva esa dependencia. Comprobar el stock antes de reservarlo sigue siendo una secuencia, aunque se asignen nombres distintos a sus llamadas. Un flujo programado puede coordinarla sin introducir varios agentes autónomos.

La distinción entre paralelización y delegación dinámica aparece en Building effective agents, de Anthropic. Úsala para describir el trabajo que debe hacer el sistema. El número de modelos no determina por sí mismo la calidad de esa separación.

Reparte objetivos, datos y autoridad

En la revisión de la integración, un agente podría examinar compatibilidad con la API y otro revisar los permisos. Ambos necesitan una versión identificada del código. Cada uno debe devolver hallazgos con referencias verificables y señalar lo que no pudo comprobar.

Define para cada tarea:

• La pregunta que debe resolver y cuándo debe terminar.
• Qué fuentes puede consultar y qué herramientas tiene permitidas.
• La forma del resultado, incluidas las condiciones de fallo o trabajo incompleto.
• La versión de los datos examinados y la persona o proceso que integra la entrega.

Separa los permisos en el código que ejecuta herramientas. Dar a cada agente una descripción de rol distinta no limita sus credenciales. En tareas de revisión, el acceso de lectura suele ser suficiente para empezar; las correcciones pueden pasar después a una fase autorizada de escritura.

Evita que la coordinación se convierta en otro fallo

Un resultado intermedio debe conservar la evidencia necesaria para tomar una decisión. «Todo correcto» pierde el alcance de la revisión. Es más útil saber qué se examinó, con qué versión y qué limitaciones quedaron abiertas.

El coordinador debe detectar tareas ausentes o fallidas. Si un agente agota su tiempo, no se puede presentar su área como revisada. Si dos informes discrepan, conserva la discrepancia y pide una comprobación concreta. Votar entre respuestas del mismo modelo y con las mismas fuentes no crea independencia estadística.

También hace falta un responsable de las escrituras. Dos agentes que modifican el mismo recurso pueden sobrescribirse o ejecutar una acción duplicada. Usa ámbitos de escritura separados cuando existan y una fase explícita de integración. En código, los worktrees ayudan a aislar cambios, pero los conflictos de comportamiento todavía requieren revisión y tests.

Mide el tiempo del flujo completo

Una rama paralela solo reduce tiempo si no depende de otra y su coordinación no consume el ahorro. Para dos tareas independientes, una aproximación útil es:

T_sequential = T_shared + T_a + T_b + T_merge
T_parallel = T_shared + max(T_a, T_b) + T_merge + T_coordination

Estas expresiones describen un modelo simplificado, sin colas ni reintentos. Sustituye cada término por mediciones de tu sistema e incluye las ramas fallidas. La llamada más lenta puede dominar la espera, aunque el resto termine pronto.

El informe de Anthropic sobre su sistema de investigación multi-agente explica por qué la exploración de varias direcciones se beneficia de contextos separados. También señala el coste de tokens y las dificultades con tareas muy dependientes. Sus resultados corresponden a ese trabajo de investigación; no establecen una mejora garantizada para una integración empresarial.

Compara contra una alternativa razonable

Evalúa el sistema existente después de corregir sus herramientas y sus instrucciones. Compáralo con una división fija de tareas y, si hay motivos, con delegación dinámica. Mantén las mismas entradas, versiones y criterios de aceptación.

Además del resultado final, mide el trabajo que se repite y lo que se pierde al integrar informes. Registra tiempo total, coste por tarea aceptada y revisión humana necesaria. Una respuesta parcial rápida debe seguir contando como parcial.

Incluye pruebas donde falte una fuente, una herramienta devuelva un error o dos resultados entren en conflicto. Los tests de contratos y permisos siguen siendo deterministas. La evaluación del modelo añade cobertura sobre sus decisiones y la utilidad de la respuesta; ambos tipos de prueba hacen falta.

Qué justificaría la complejidad adicional

La división merece continuar si corrige un fallo relevante o mejora una medida acordada sin empeorar las condiciones de seguridad y operación. Retírala si el beneficio desaparece al incluir reintentos, coste o tiempo de revisión. El equipo debe poder explicar qué aporta cada agente y qué sucederá si deja de responder.

El servicio de sistemas multi-agente puede acotar esa comparación. La guía del runtime de un solo agente ayuda a fijar la alternativa de partida.

Envía un flujo concreto y el motivo por el que quieres dividirlo. Una revisión técnica puede identificar tareas realmente independientes y proponer un experimento antes de comprometer una arquitectura más difícil de mantener.