El problema
Un ingeniero propone utilizar cuatro subagentes especializados para resolver una tarea de análisis que consiste en leer dos archivos y comparar dos cifras numéricas. La justificación presentada: "los sistemas multiagente son más robustos". En la práctica, el resultado son cuatro sesiones con contextos independientes, mayor latencia, costos multiplicados y cero mejoras en la calidad — porque la tarea nunca requirió perspectivas de razonamiento independientes. Exigía una comprobación determinista.
La orquestación multiagente no es una escala lineal de "mejor" a medida que añades más agentes. Es un patrón arquitectónico diseñado para condiciones específicas: cuando una tarea se beneficia genuinamente del aislamiento de contexto, la especialización estricta de dominios o el paralelismo real. Fuera de estos casos, solo introduce complejidad innecesaria.
El concepto central
La primera pregunta antes de adoptar cualquier topología multiagente es: ¿esta tarea cabe cómodamente en un único contexto, utilizando un conjunto reducido de herramientas, sin requerir razonamiento aislado? Si la respuesta es afirmativa, un coordinador único resuelve el problema con la menor cantidad de piezas móviles. Las arquitecturas multiagente se justifican únicamente cuando se cumple al menos una de estas condiciones:
- La tarea se beneficia de investigación paralela independiente: explorar múltiples fuentes o hipótesis simultáneamente sin que una contamine el razonamiento de la otra.
- La tarea exige una revisión aislada: un evaluador independiente que examine únicamente el resultado final sin acceso al razonamiento generativo previo, eliminando el sesgo de confirmación.
- La tarea abarca subdominios genuinamente especializados: donde cada subagente carga únicamente el contexto de su área en lugar de acumular un contexto monolítico sobrecargado.
Una comprobación determinista — como comparar dos números o calcular un hash de archivo — jamás justifica la creación de un subagente. Debe implementarse en código convencional o mediante una herramienta de alcance acotado, ya que no obtiene beneficio alguno de un bucle de razonamiento autónomo. Este es el distractor más recurrente en los escenarios: proponer arquitecturas multiagente para operaciones que siguen algoritmos deterministas.
El segundo eje de decisión es la topología. Un coordinador que delega en subagentes especializados funciona de forma óptima cuando las subtareas se conocen de antemano y tienen límites definidos — cada subagente recibe un alcance claro y devuelve una respuesta estructurada. El paralelismo real (múltiples subagentes ejecutándose al mismo tiempo) solo aporta valor cuando las subtareas son mutuamente independientes — si el paso B depende de la salida del paso A, paralelizar añade sobrecarga de coordinación sin reducir tiempos.
El tercer eje es la descomposición secuencial versus adaptativa. La descomposición secuencial es adecuada cuando los pasos están prefijados — una canalización fija de "extraer, validar, formatear". La descomposición adaptativa es indispensable cuando el siguiente paso depende dinámicamente de los hallazgos previos — donde el coordinador debe decidir en tiempo de ejecución si delega, a quién y con qué alcance a medida que evoluciona el problema.
El error más costoso en la orquestación multiagente no es utilizar pocos agentes — es utilizar demasiados agentes para una tarea que cabía en un único contexto, multiplicando la latencia y los costos operativos sin generar mejoras medibles en la calidad.
Ponlo en práctica
En el laboratorio de esta lección implementarás un motor de decisión de topologías en Python: a partir de señales operativas (¿requiere paralelismo real? ¿necesita revisión aislada? ¿es una operación determinista?), recomendará la arquitectura adecuada — incluyendo el reconocimiento de cuándo la respuesta correcta es "cero subagentes, ejecutar en código nativo".