La tentación de dividir
La idea es seductora y suena a buena ingeniería: en vez de un agente que hace todo, varios especializados. Uno que investiga, uno que redacta, uno que revisa, un coordinador que reparte. Se parece a cómo organizamos equipos humanos, y por eso convence en la pizarra.
En producción, el resultado depende casi por completo de una sola característica del trabajo: si las subtareas son independientes o si cada una necesita lo que produjo la anterior.
Lo que muestran los estudios de 2026
La evidencia publicada este año apunta en una dirección bastante consistente, con dos resultados que conviene tener presentes antes de diseñar:
- En trabajo paralelizable, dividir ayuda. Cuando las subtareas no dependen entre sí, la coordinación centralizada mejora el resultado de forma apreciable.
- En planificación secuencial, dividir perjudica. Los estudios de escalado reportan caídas importantes de desempeño en tareas donde cada paso depende del anterior, y lo hacen en todas las variantes multiagente probadas.
Hay además un efecto que se discute menos: la propagación de errores. Un agente que arranca con una premisa equivocada no solo falla él; entrega su resultado al siguiente, que lo da por bueno. En arquitecturas sin coordinación central el error se amplifica varias veces más que en las coordinadas, y mucho más que en un agente único, donde al menos el error se queda donde nació.
Dos matices sobre estas cifras: la mayoría circula a través de resúmenes secundarios, y los porcentajes exactos varían según el estudio. La dirección es sólida; los números concretos conviene tomarlos como orden de magnitud.
Los tres costos que no se ven en la pizarra
Tokens. Cada agente necesita su propio contexto, y el resultado de uno se vuelve entrada del siguiente. El mismo trabajo puede consumir de cuatro veces a dos órdenes de magnitud más tokens que resuelto por un solo agente. Eso es dinero y es latencia.
Depuración. Cuando un agente único falla, se lee su traza. Cuando falla una cadena de cinco, hay que reconstruir qué entendió cada uno de lo que le pasó el anterior. Los fallos más difíciles no están dentro de ningún agente: están en el traspaso.
Contexto perdido. Cada handoff es una compresión. El agente investigador sabía que el dato venía de una fuente dudosa; lo que pasa al redactor es una frase afirmativa. El matiz se evaporó y nadie lo notará hasta que el cliente lo señale.
Cuándo sí conviene dividir
| Señal | Qué indica |
|---|---|
| Las subtareas corren a la vez sin esperarse | Buen caso para multiagente |
| Hay un límite de contexto real, no imaginado | Buen caso, si ya se intentó resumir |
| Se necesita aislamiento de permisos | Buen caso: facturación no debe ver ingeniería |
| Dominios con herramientas muy distintas | Puede ayudar, con coordinación central |
| Cada paso usa el resultado del anterior | Mal caso: un solo agente |
| Hay estado compartido que todos modifican | Mal caso: la coordinación cuesta más de lo que suma |
| Todavía no hay trazas | Mal caso en cualquier escenario |
El caso de aislamiento por seguridad merece una mención aparte, porque es el único donde dividir se justifica aunque empeore un poco el desempeño: separar un agente que toca facturación de uno que toca infraestructura crea una frontera real de permisos. Ahí el multiagente no es una optimización, es un control.
Por qué el código es casi siempre caso de un solo agente
Vale la pena detenerse en este ejemplo porque es el que más se intenta dividir. Escribir código es trabajo secuencial y con estado compartido: el cambio en un archivo condiciona el siguiente, el refactor obliga a actualizar las pruebas, el nombre elegido en un módulo se usa en otros tres.
Repartir eso entre agentes que no comparten el mismo contexto produce exactamente lo que uno esperaría: inconsistencias de nombres, funciones duplicadas, cambios que se pisan. Algunos equipos que apostaron fuerte por la especialización terminaron dando marcha atrás justo por el costo de los traspasos.
La excepción razonable es el trabajo verdaderamente paralelo: generar pruebas para módulos independientes, migrar cincuenta archivos con la misma transformación mecánica, revisar en paralelo áreas distintas del sistema.
La regla práctica
- Empieza con un agente capaz y bien instrumentado. Es más rápido de construir y muchísimo más fácil de depurar.
- Mide dónde falla. Casi siempre el problema real es el contexto o el prompt, no la falta de especialistas.
- Antes de dividir, agota lo barato: mejores instrucciones, menos herramientas pero mejor descritas, resumen del historial, recuperación más precisa.
- Si divides, hazlo con coordinación central y por una frontera clara: paralelismo real o aislamiento de permisos.
- Nunca sin trazas. Varios agentes sin observabilidad es un problema de soporte esperando a ocurrir.
Conclusión
«Multiagente» describe una topología, no un nivel de inteligencia. Añadir agentes agrega capacidad de paralelizar y, al mismo tiempo, puntos donde se pierde contexto y se amplifican errores. Cuando el trabajo se puede repartir de verdad, el intercambio sale a favor; cuando es una cadena de pasos dependientes, sale en contra casi siempre.
Antes de rediseñar la arquitectura, vale la pena descartar la causa más frecuente de un agente que rinde mal: lo que se le está dando de entrada. Eso se trata en context engineering, y la forma de comprobar si un cambio mejoró algo, en cómo evaluar si tu IA funciona.