Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «IA Agéntica: Agentes que Operan Sistemas Reales».
Hasta aquí todo el curso razonó sobre un agente: un lazo, un contexto, un catálogo de herramientas. Repartir el trabajo entre varios no es una moda arquitectónica ni una forma de conseguir "más inteligencia": es una respuesta a cuatro limitaciones concretas y medibles del agente único.
Paralelismo. Si las subtareas son independientes, ejecutarlas a la vez reduce el tiempo de pared. Es la única de las cuatro razones que se nota en un reloj.
Especialización. Cada rol recibe su propio prompt de sistema y su propio catálogo reducido. Un agente con 6 herramientas bien elegidas se equivoca menos que uno con 40, por la misma razón de granularidad que viste en la lección 2: el catálogo entero compite por la atención del modelo en cada decisión.
Contexto limitado. Cada trabajador tiene su propia ventana. El orquestador no recibe todo lo que el trabajador leyó, sino su resultado estructurado. Es la forma más efectiva de atacar una tarea cuyo material no cabe en una sola ventana: en vez de resumir hasta perder detalle, se reparte y solo se consolidan las conclusiones.
Verificación independiente. Quien produjo un hallazgo es mal juez de su propia validez. Un agente que revisa su propio trabajo tiende a confirmarlo; uno que no vio cómo se produjo, no tiene ese apego. La lección 9 le pondrá nombre a ese sesgo.
Ninguna de las cuatro dice "el problema es difícil, pongamos más agentes". Si tu agente falla por un catálogo mal diseñado o por falta de grounding, replicarlo cinco veces te dará cinco fallos coordinados.
Tres topologías que cubren casi todo
Orquestador-trabajadores (fan-out / fan-in). Un orquestador descompone la tarea, reparte subtareas a W trabajadores idénticos o especializados, espera y sintetiza. Es la topología por defecto cuando las subtareas son independientes: revisar seis módulos, analizar veinte pases, comparar tres fuentes.
Panel de jueces. Varios agentes evalúan lo mismo de forma independiente y sus veredictos se agregan (mayoría, promedio o consenso con desempate). No paraleliza trabajo: reduce varianza. Su ventaja es estadística — los errores independientes se cancelan al agregar, mientras que un juez único traslada su sesgo íntegro al resultado. Se usa cuando el juicio es discutible y caro de equivocar.
Pipeline por etapas. Cada agente transforma la salida del anterior bajo un contrato fijo: extraer → normalizar → analizar → redactar. Es multi-agente pero secuencial, y por eso comparte casi todas las propiedades del workflow determinista de la lección 5: presupuestable, depurable por etapa, sin coordinación dinámica.
Ejemplo resuelto: seis módulos, tres diseños
Una tarea de revisión de código sobre seis módulos cuyos tiempos de análisis, medidos, son {40,55,30,65,45,25} segundos. El trabajo total es:
Ttotal=40+55+30+65+45+25=260 s
Con un agente secuencial, el tiempo de pared es 260 s. Con seis trabajadores en paralelo, el episodio dura lo que el módulo más lento: max=65 s, casi 4× más rápido. Con tres trabajadores, repartiendo el más largo primero (65, 55, 45, 40, 30, 25) las cargas quedan en 65+25=90, 55+30=85 y 45+40=85; el tiempo de pared es el máximo, 90 s, y la aceleración real es 260/90≈2.89 — no 3, porque el reparto nunca es perfecto.
El coste va en dirección contraria. Reusando las cifras de la lección 1 (contexto fijo por agente C0=6400 tokens, Δ=1850 tokens por iteración) y suponiendo 3 iteraciones por módulo, el trabajo útil es el mismo en los tres diseños: 18×1850=33300 tokens. Lo que cambia es el contexto fijo, que se paga una vez por agente:
Es decir: 1.9 veces más tokens a cambio de 4 veces menos tiempo de pared. Esa es la ecuación completa del fan-out, y conviene enunciarla sin adornos: el paralelismo se paga en tokens y se cobra en tiempo. Si a nadie le urge el resultado, el agente único es más barato y más simple.
De la misma fórmula sale el criterio de cuándo un trabajador vale la pena. Su eficiencia — fracción del gasto que es trabajo real — con k iteraciones es η=kΔ/(C0+kΔ). Con k=3: 5550/11950≈0.46; con k=12: 22200/28600≈0.78. Un trabajador que hace tres iteraciones desperdicia más de la mitad de su coste en montar su propio contexto. Reparte tareas gruesas, no tareas de un paso.
Verificación adversarial
Un verificador no es un revisor amable: su instrucción es intentar refutar cada hallazgo con evidencia del propio material. No pregunta "¿es plausible?", sino "¿qué línea exacta lo demuestra?". Los hallazgos que no sobreviven se descartan.
El efecto es cuantificable. Supón que los tres trabajadores reportan 14 hallazgos, de los cuales 9 son reales y 5 son falsos positivos. Sin verificación, la precisión de la entrega es:
Psin=9/14≈0.643
El verificador refuta los 5 falsos y, siendo estricto, descarta también 1 hallazgo verdadero cuya evidencia era ambigua. Quedan 8 confirmados, todos reales:
Pcon=8/8=1.00Rcon=8/9≈0.889
La precisión sube de 64.3% a 100% y la exhaustividad baja de 100% a 88.9%. Ese intercambio es deliberado y hay que elegirlo a conciencia: en revisión de código o en diagnóstico de una estación, un falso positivo cuesta la atención de un operador y erosiona la confianza en el sistema, mientras que un hallazgo perdido normalmente reaparece. En un chequeo de seguridad previo a una maniobra irreversible, la aritmética se invierte.
Comunicación entre agentes: contratos, no prosa
Los agentes de un sistema multi-agente no deben hablarse en prosa libre. Un trabajador entrega un objeto estructurado:
{"modulo":"decoder/apt.py","severidad":"alta","linea":214,
"hallazgo":"lectura fuera de rango cuando el pase dura menos de 2 s",
"evidencia":"buffer[i+1] sin comprobar i+1 < len(buffer)","confianza":0.86}
Tres razones, en orden de importancia. Seguridad: la prosa de un trabajador que leyó datos no confiables puede arrastrar instrucciones hasta el orquestador, y el orquestador suele tener más privilegios que el trabajador — es exactamente el vector que estudiaremos en la lección 7. Un campo severidad restringido a un enum no transporta instrucciones. Fidelidad: el orquestador necesita deduplicar, ordenar por severidad y agregar por módulo, y eso exige campos, no párrafos. Coste: la misma información en prosa ocupa varias veces más tokens, multiplicados por cada trabajador.
La regla práctica: entre agentes, contratos; con humanos, prosa. La redacción final es la última etapa, una sola vez, a partir de datos ya consolidados.
Cuándo NO usar multi-agente
El multi-agente es contraproducente cuando el coste de coordinación domina al trabajo coordinado. Cuatro señales claras:
Dependencias secuenciales fuertes: si el paso 2 necesita el resultado del paso 1, no hay nada que paralelizar y solo añades traspasos.
Subtareas de un solo paso: como calculamos arriba, con k pequeño la mayor parte del gasto es montar contexto.
Estado compartido mutable: dos agentes escribiendo sobre el mismo recurso producen conflictos que ningún prompt resuelve; eso es un problema de concurrencia y se arregla con mecanismos de concurrencia.
El proceso ya era un workflow: si el camino se conoce, la respuesta de la lección 5 sigue siendo válida — código determinista con nodos agénticos, no un enjambre.
Comprueba el criterio de reparto:
Tienes que revisar 6 módulos independientes, cada uno con unas 3 iteraciones de trabajo, y el resultado se necesita en minutos. ¿Qué diseño corresponde?
El laboratorio de esta lección convierte esta aritmética en algo que puedes mover: eliges el número de trabajadores y de verificadores, lanzas la revisión de los seis módulos y observas en vivo el tiempo total frente al secuencial, los hallazgos brutos frente a los confirmados y el coste en agente-segundos. Busca el punto donde añadir un trabajador más ya no reduce el tiempo pero sí sube la factura.
Laboratorio: Orquestador multi-agente · Paralelismo, coste y verificación