aterrizó en arXiv justo antes de la Navidad de 2025, un regalo anticipado del equipo de Google DeepMind, con el título "Hacia una ciencia de sistemas de agentes escaladores". Este artículo me pareció una lectura realmente útil para ingenieros y científicos de datos. Está plagado de consejos concretos basados en mediciones y repleto de conclusiones que puede aplicar de inmediato. Los autores realizan un gran estudio multifactorial, facilitado por la tremenda computación disponible en estos laboratorios de vanguardia, para variar sistemáticamente los parámetros de diseño clave para comprender realmente qué impulsa el rendimiento en los sistemas agentes.
Como muchos profesionales de la IA de la industria, dedico mucho tiempo a crear sistemas multiagente (MAS). Esto implica tomar un flujo de trabajo complejo de varios pasos y dividirlo entre un conjunto de agentes, cada uno de ellos especializado en una tarea específica. Si bien el paradigma dominante para los chatbots de IA es la interacción solicitud-respuesta de disparo cero, los sistemas multiagente (MAS) ofrecen una promesa más convincente: la capacidad de “dividir y conquistar” de forma autónoma tareas complejas. Al paralelizar la investigación, el razonamiento y el uso de herramientas, estos sistemas aumentan significativamente la efectividad con respecto a los modelos monolíticos.
Para ir más allá de las simples interacciones, la investigación de DeepMind destaca que el rendimiento de MAS está determinado por la interacción de cuatro factores:
Cantidad de agentes: la cantidad de unidades especializadas desplegadas. Estructura de coordinación: la topología (centralizada, descentralizada, etc.) que rige cómo interactúan. Capacidad del modelo: la inteligencia de referencia de los LLM subyacentes. Propiedades de la tarea: La complejidad inherente y los requisitos del trabajo.
La ciencia del escalamiento sugiere que el éxito en el desempeño de MAS se encuentra en la intersección de cantidad, topología, capacidad y complejidad de la tarea. Si nos equivocamos en el equilibrio, terminamos escalando el ruido en lugar de los resultados. Esta publicación lo ayudará a encontrar esa salsa secreta para sus propias tareas de una manera que lo ayudará de manera confiable a construir un MAS robusto y de alto rendimiento que impresionará a sus partes interesadas.
Una convincente historia de éxito reciente sobre dónde se encontró un equilibrio óptimo para una tarea compleja proviene de Cursor, la empresa de desarrollo de software impulsada por IA detrás de un popular IDE. Describen el uso de una gran cantidad de agentes trabajando en conjunto para automatizar tareas complejas durante ejecuciones prolongadas, incluida la generación de cantidades sustanciales de código para construir un navegador web (puede ver el código aquí) y la traducción de bases de código (por ejemplo, de Solid a React). Su artículo sobre cómo escalar la IA agente a tareas difíciles durante semanas de computación es una lectura fascinante.
El cursor informa que la ingeniería rápida es fundamental para el rendimiento y que la arquitectura de coordinación de agentes específica es clave. En particular, reportan mejores resultados con una descomposición estructurada planificador-trabajador que con un enjambre (o bolsa) plano de agentes. El papel de la coordinación es particularmente interesante y es un aspecto del diseño de MAS al que volveremos en este artículo. Al igual que los equipos del mundo real se benefician de un gerente, el equipo de Cursor descubrió que era esencial una configuración jerárquica, con un planificador al mando. Esto funcionó mucho mejor que una batalla campal en la que los agentes elegían las tareas a voluntad. El planificador permitió la delegación y la rendición de cuentas controladas, lo que garantizó que los agentes trabajadores abordaran las subtareas correctas y lograran avances concretos en el proyecto. Curiosamente, también descubrieron que es importante hacer coincidir el modelo correcto con el correcto, y descubrieron que GPT-5.2 es el mejor planificador y agente de trabajo en comparación con Claude Opus 4.5.
Sin embargo, a pesar de este primer vistazo de éxito por parte del equipo de Cursor, el desarrollo del sistema multiagente en el mundo real sigue estando en el límite del conocimiento científico y, por lo tanto, es una tarea desafiante. Los sistemas multiagente pueden ser complicados con resultados poco confiables, presupuestos simbólicos perdidos debido a conversaciones de coordinación y un rendimiento que varía, a veces empeorando en lugar de mejorar. Es necesario pensar detenidamente en el diseño y asignarlo a los detalles de un caso de uso determinado.
Al desarrollar un MAS, volvía a las mismas preguntas: ¿cuándo debería dividir un paso entre varios agentes y qué criterios deberían impulsar esa decisión? ¿Qué arquitectura de coordinación debo elegir? Con tantas permutaciones de descomposición y roles de agentes, es fácil terminar abrumado. Además, ¿cómo debería pensar en el tipo de agentes disponibles y sus funciones?
Esa brecha entre la promesa y la realidad es lo que hace que el desarrollo de un MAS sea un problema de ingeniería y ciencia de datos tan convincente. Lograr que estos sistemas funcionen de manera confiable y brinden un valor comercial tangible aún implica mucha prueba, error e intuición ganada con esfuerzo. En muchos sentidos, el campo puede parecer como si estuvieras operando fuera de lo común, sin suficiente teoría compartida o práctica estándar.
Este artículo del equipo de DeepMind ayuda mucho. Aporta estructura al espacio y, lo que es más importante, propone una forma cuantitativa de predecir cuándo es probable que una determinada arquitectura de agente brille y cuándo es más probable que tenga un rendimiento inferior.
En la prisa por construir una IA compleja, la mayoría de los desarrolladores caen en la trampa de la 'bolsa de agentes' al dedicar más LLM a un problema y esperar inteligencia emergente. Pero como muestra la reciente investigación Science of Scaling realizada por DeepMind, una bolsa de agentes no es un equipo eficaz, sino que puede ser una fuente de amplificación de errores de 17,2 veces. Sin las vallas y carriles de una topología formal que limiten la interacción agente, terminamos escalando ruido en lugar de una capacidad inteligente que probablemente resuelva una tarea empresarial.
No tengo ninguna duda de que dominar la construcción estandarizada de sistemas multiagente es el próximo gran foso técnico. Las empresas que puedan cerrar rápidamente la brecha entre agentes autónomos "desordenados" y topologías rigurosas basadas en planos cosecharán los dividendos de una eficiencia extrema y una producción de alta fidelidad a escala, lo que traerá enormes ventajas competitivas dentro de su mercado.
Según la investigación de escalamiento de DeepMind, la coordinación de múltiples agentes produce los mayores retornos cuando una base de referencia de un solo agente está por debajo del 45%. Si su modelo base ya alcanza el 80%, agregar más agentes podría generar más ruido que valor.
En esta publicación, destilo pepitas como las anteriores en un libro de jugadas que le proporciona el mapa mental adecuado para construir los mejores sistemas multiagente. Encontrará reglas de oro para construir un sistema multiagente para una tarea determinada, abordando qué agentes construir y cómo deben coordinarse. Además, definiré un conjunto de diez arquetipos de agentes principales para ayudarle a mapear el panorama de capacidades y facilitar la elección de la configuración adecuada para su caso de uso. Luego, extraeré las principales lecciones de diseño del artículo sobre Ciencia del escalamiento de DeepMind y las utilizaré para mostrar cómo configurar y coordinar estos agentes de manera efectiva para diferentes tipos de trabajo.
Definición de una taxonomía de arquetipos de agentes centrales
En esta sección trazaremos el espacio de diseño de los Agentes, centrándonos en los tipos generales disponibles para resolver tareas complejas. Es útil resumir los tipos de Agentes en 10 tipos básicos, siguiendo de cerca las definiciones de la encuesta de agentes autónomos de 2023 de Wang et al.: Orquestador, Planificador, Ejecutor, Evaluador, Sintetizador, Crítico, Recuperador, Guardián de la Memoria, Mediador y Monitor. En mi experiencia, casi todos los sistemas multiagente útiles se pueden diseñar utilizando una combinación de estos agentes conectados entre sí en una topología específica.
Hasta ahora tenemos una colección vaga de diferentes tipos de agentes, es útil si tenemos un punto de referencia mental asociado sobre cómo se pueden agrupar y aplicar. Podemos organizar estos agentes a través de dos lentes complementarios: una arquitectura estática de planos de control funcional y un ciclo de ejecución dinámico de Planificar-Hacer-Verificar. La forma de pensar en esto es que los planos de control proporcionan la estructura, mientras que el ciclo de ejecución impulsa el flujo de trabajo:
Plan: El orquestador (plano de control) define el objetivo de alto nivel y las restricciones. Delega al Planificador, que descompone el objetivo en un gráfico de tareas: mapea dependencias, prioridades y pasos. A medida que surge nueva información, el orquestador secuencia y revisa este plan dinámicamente. Hacer: El Ejecutor traduce tareas abstractas en resultados tangibles (artefactos, cambios de código, decisiones). Para garantizar que este trabajo sea sólido y eficiente, el Recuperador (Plano Contextual) proporciona al Ejecutor el contexto justo a tiempo, como archivos relevantes, documentación o evidencia previa. Verificar: Esta es la puerta de calidad. El Evaluador valida los resultados según criterios de aceptación objetivos, mientras que el Crítico busca debilidades subjetivas como casos extremos o suposiciones ocultas. La retroalimentación regresa al Planificador para su iteración. Al mismo tiempo, el Monitor vigila la salud del sistema (sigue la deriva, los estancamientos o los picos presupuestarios) y está listo para activar un reinicio si el ciclo se degrada.
Como se ilustra en nuestra Arquitectura Cognitiva de Agentes Múltiples (Figura 2), estos agentes especializados están situados dentro de Planos de Control Horizontales, que agrupan capacidades por responsabilidad funcional. Esta estructura transforma una caótica “bolsa de agentes” en un sistema de alta fidelidad al compartimentar el flujo de información.
Para fundamentar estas capas técnicas, podemos ampliar nuestra analogía del lugar de trabajo humano para definir cómo funcionan estos planos:
La capa de control: la gestión
El orquestador: Piense en esto como el director del proyecto. Tiene el objetivo de alto nivel. No escribe código ni busca en la web; su trabajo es delegar. Decide quién hace qué a continuación. El Monitor: Este es el oficial de “Salud y Seguridad”. Observa al Orquestador. Si el agente se queda atrapado en un bucle, quema demasiado dinero (fichas) o se desvía del objetivo original, el Monitor acciona el freno de emergencia o activa una alerta.
La capa de planificación: la estrategia
El Planificador: Antes de actuar, el agente debe pensar. El Planificador toma el objetivo del Orquestador y lo desglosa. Gráfico de tareas/trabajo pendiente (artefacto): esta es la "lista de tareas pendientes". Es dinámico: a medida que el agente aprende cosas nuevas, se pueden agregar o eliminar pasos. El Planificador actualiza constantemente este gráfico para que el Orquestador conozca los próximos pasos del candidato.
La capa de contexto: la memoria
El recuperador: el bibliotecario. Obtiene información específica (documentos, código anterior) necesaria para la tarea actual. El guardián de la memoria: el archivero. No es necesario recordar todo. Esta función resume (comprime) lo que sucedió y decide qué es lo suficientemente importante como para almacenarlo en el Context Store a largo plazo.
La capa de ejecución: los trabajadores
El Ejecutor: El Especialista. Esto actúa según el plan. Escribe el código, llama a la API o genera el texto. El sintetizador: el editor. La salida del Ejecutor puede ser confusa o demasiado detallada. El sintetizador lo limpia y lo formatea para obtener un resultado claro para que el orquestador lo revise.
La capa de garantía: control de calidad
El evaluador: comprueba la corrección objetiva. (por ejemplo, "¿Se compiló el código?" "¿La salida se adhirió al esquema JSON?") El crítico: verifica riesgos subjetivos o casos extremos. (por ejemplo, "Este código se ejecuta, pero tiene una vulnerabilidad de seguridad" o "Esta lógica es defectuosa"). Bucles de retroalimentación (flechas punteadas): observe las líneas de puntos que regresan al Planificador en la Figura 2. Si la capa de Garantía no funciona, el agente actualiza el plan para corregir los errores específicos encontrados.
La capa de mediación: resolución de conflictos
El Mediador: A veces el Evaluador dice "Aprobado" pero el Crítico dice "Reprobado". O tal vez el Planificador quiera hacer algo que el Monitor considere riesgoso. El Mediador actúa como desempate para evitar que el sistema se congele en un punto muerto.
Para ver estos arquetipos en acción, podemos rastrear una única solicitud a través del sistema. Imaginemos que presentamos el siguiente objetivo: "Escribir un script para extraer datos de precios del sitio de un competidor y guardarlos en nuestra base de datos". La solicitud no se dirige únicamente a un “trabajador”; desencadena una secuencia coreografiada a través de los planos funcionales.
Paso 1: Inicialización: carril de control
El orquestador recibe el objetivo. Comprueba sus “barandillas” (por ejemplo, “¿Tenemos permiso para raspar? ¿Cuál es el presupuesto?”).
La Acción: Entrega la meta al Planificador. El Monitor inicia un “cronómetro” y un “contador de tokens” para garantizar que el agente no gaste $50 tratando de raspar un sitio de $5.
Paso 2: Descomposición – Línea de planificación
El planificador se da cuenta de que en realidad se trata de cuatro subtareas: (1) investigar la estructura del sitio, (2) escribir el raspador, (3) mapear el esquema de datos, (4) escribir la lógica de ingesta de la base de datos.
La acción: completa el gráfico de tareas/el trabajo pendiente con estos pasos e identifica las dependencias (por ejemplo, no puede mapear el esquema hasta que haya investigado el sitio).
Paso 3: Conexión a tierra: carril contextual
Antes de que comience el trabajador, el Retriever busca en el Context Store.
La acción: extrae nuestros “Documentos de esquema de base de datos” y “Mejores prácticas de raspado” y se los entrega al Ejecutor. Esto evita que el agente "alucine" con una estructura de base de datos que no existe.
Paso 4: Producción – Línea de ejecución
El Ejecutor escribe el código Python para los Pasos 1 y 2.
La Acción: Coloca el código en el Espacio de Trabajo/Salidas. El sintetizador podría tomar ese código sin formato y incluirlo en una "Actualización de estado" para el orquestador, diciendo "Tengo un borrador de script listo para verificación".
Paso 5: La “prueba” – Línea de garantía
Aquí es donde las líneas de puntos de retroalimentación entran en acción:
El evaluador ejecuta el código. Falla debido a un error 403 Prohibido (bot anti-scraping). Envía una flecha punteada de regreso al Planificador: "El sitio de destino nos bloqueó; necesitamos una estrategia de rotación de encabezados". El crítico mira el código y ve que la contraseña de la base de datos está codificada. Envía una flecha punteada al planificador: "Riesgo de seguridad: las credenciales deben ser variables de entorno".
Paso 6: Conflicto y resolución: vía de mediación
Imagine que el Planificador intenta solucionar el problema de seguridad del Crítico, pero el Evaluador dice que el nuevo código ahora interrumpe la conexión a la base de datos. Están atrapados en un bucle.
La acción: El Mediador interviene, analiza las dos "opiniones" contradictorias y decide: "Priorizar la solución de seguridad; le indicaré al Planificador que agregue un paso específico para depurar la conexión de base de datos específicamente". El Orquestador recibe esta resolución y actualiza el estado.
Paso 7: Entrega final
El ciclo se repite hasta que el Evaluador (el código funciona) y el Crítico (el código es seguro) dan un "Aprobado".
La acción: El sintetizador toma el código final verificado y lo devuelve al usuario. Memory Keeper resume el encuentro "403 Forbidden" y lo almacena en Context Store para que la próxima vez que se le solicite al agente que raspe un sitio, recuerde usar la rotación de encabezado desde el principio.
Arquetipos de herramientas centrales: los 10 componentes básicos de sistemas agentes confiables
De la misma manera que definimos arquetipos de agentes comunes, podemos realizar un ejercicio similar para sus herramientas. Los arquetipos de herramientas definen cómo se fundamenta, ejecuta y verifica ese trabajo y qué modos de falla se contienen a medida que el sistema escala.
Como cubrimos en la Figura 5 anterior, las herramientas de recuperación pueden prevenir las alucinaciones al forzar la evidencia; los validadores de esquemas y los arneses de prueba previenen fallas silenciosas al hacer que la corrección sea verificable por máquina; los medidores de presupuesto y la observabilidad evitan bucles fuera de control al exponer (y limitar) la quema y la deriva de tokens; y las puertas de permiso más las zonas de pruebas previenen efectos secundarios inseguros al limitar lo que los agentes pueden hacer en el mundo real.
El antipatrón de la bolsa de agentes
Antes de explorar las Leyes de Escalamiento de la Agencia, es instructivo definir el antipatrón que actualmente detiene la mayoría de los despliegues de IA agencia y que pretendemos mejorar: la “Bolsa de Agentes”. En esta configuración ingenua, los desarrolladores lanzan múltiples LLM a un problema sin una topología formal, lo que da como resultado un sistema que normalmente exhibe tres características fatales:
Topología plana: cada agente tiene una línea abierta con todos los demás agentes. No existe jerarquía, ni guardián, ni planos especializados para compartimentar el flujo de información. Charla ruidosa: sin un orquestador, los agentes caen en una lógica circular o “bucles de alucinación”, donde se hacen eco y validan los errores de los demás en lugar de corregirlos. Ejecución de bucle abierto: la información fluye sin control a través del grupo. No existe un plano de aseguramiento dedicado (evaluadores o críticos) para verificar los datos antes de que lleguen a la siguiente etapa del flujo de trabajo.
Para usar una analogía con el lugar de trabajo: el salto de una “bolsa” a un “sistema” es el mismo salto que da una startup cuando contrata a su primer gerente. Los equipos en las primeras etapas se dan cuenta rápidamente de que la plantilla no equivale a la producción sin una estructura organizativa que la contenga. Como dijo Brooks en The Mythical Man-Month, “Agregar mano de obra a un proyecto de software tardío lo hace más tardío”.
¿Pero cuánta estructura es suficiente?
La respuesta está en las Leyes de escala de agencia del artículo de DeepMind. Esta investigación descubre las compensaciones matemáticas precisas entre agregar más "cerebros" de LLM y la creciente fricción de su coordinación.
Las leyes de escala de la agencia: coordinación, topología y compensaciones
El principal descubrimiento del artículo de Science of Scaling Agent Systems es que aumentar la cantidad de agente no es una solución milagrosa para lograr un mayor rendimiento. Más bien existe un equilibrio riguroso entre los gastos generales de coordinación y la complejidad de la tarea. Sin una topología deliberada, agregar agentes es como agregar ingenieros a un proyecto sin un administrador orquestador: normalmente no se obtienen resultados más valiosos; probablemente tendrá más reuniones, trabajo no dirigido y potencialmente inútil y charlas ruidosas.
Configuración experimental para la evaluación MAS
El equipo de DeepMind evaluó sus sistemas multiagente en cuatro conjuntos de tareas y probó los diseños de los agentes en cargas de trabajo muy diferentes para evitar vincular las conclusiones a tareas o puntos de referencia específicos:
BrowseComp-Plus (2025): navegación web/recuperación de información, enmarcada como ubicación de información en múltiples sitios web: una prueba de búsqueda, navegación y recopilación de pruebas. Agente financiero (2025): Tareas financieras diseñadas para imitar el desempeño de un analista de nivel básico: prueba el razonamiento estructurado, la interpretación cuantitativa y el apoyo a las decisiones. PlanCraft (2024): planificación de agentes en un entorno de Minecraft: una configuración clásica de planificación a largo plazo con estado, restricciones y secuenciación. WorkBench (2024): planificación y selección de herramientas para actividades comerciales comunes: prueba si los agentes pueden elegir herramientas/acciones y ejecutar flujos de trabajo prácticos.
En Hacia una ciencia de los sistemas de agentes escalables se examinan cinco topologías de coordinación: un sistema de agente único (SAS) y cuatro diseños de sistemas de agentes múltiples (MAS): independiente, descentralizado, centralizado e híbrido. La topología es importante porque determina si agregar agentes genera trabajo paralelo útil o simplemente genera más comunicación.
SAS (Agente único): un agente hace todo de forma secuencial. Gastos generales de coordinación mínimos, pero paralelismo limitado. MAS (Independiente): Muchos agentes trabajan en paralelo, luego los resultados se sintetizan en una respuesta final. Fuerte en amplitud (investigación, ideación), más débil en cadenas de razonamiento estrechamente acopladas. MAS (Descentralizado): Los agentes debaten en múltiples rondas y deciden por mayoría de votos. Esto puede mejorar la solidez, pero la comunicación crece rápidamente y los errores pueden agravarse a través de conversaciones cruzadas repetidas. MAS (Centralizado): Un único orquestador coordina a los subagentes especialistas. Este diseño de “gerente + equipo” suele ser más estable a escala porque limita la charla y contiene modos de falla. MAS (Híbrido): orquestación central más intercambio dirigido entre pares. Más flexible, pero también el más complejo de gestionar y el más fácil de construir en exceso.
Este marco también aclara por qué los diseños no estructurados de “bolsa de agentes” pueden ser muy peligrosos. Kim y cols. informan una amplificación de error de hasta 17,2 × en redes mal coordinadas, mientras que la coordinación centralizada contiene esto en ~4,4 × al actuar como un disyuntor.
Es importante destacar que el documento muestra que estas dinámicas dependen de los puntos de referencia.
En Finance-Agent (razonamiento financiero altamente descomponible), MAS ofrece las mayores ganancias (centralizado +80,8%, descentralizado +74,5%, híbrido +73,1% sobre SAS) porque los agentes pueden dividir el trabajo en subprocesos analíticos paralelos y luego sintetizarlos. En BrowseComp-Plus (síntesis y navegación web dinámica), las mejoras son modestas y sensibles a la topología: el descentralizado funciona mejor (+9,2%), mientras que el centralizado es esencialmente plano (+0,2%) y el independiente puede colapsar (-35%) debido a la propagación sin control y a las interferencias ruidosas. Workbench se ubica en el medio, mostrando solo un movimiento marginal (~-11 % a +6 % en general; Descentralizado +5,7 %), lo que sugiere un equilibrio cercano entre el beneficio de orquestación y el impuesto de coordinación. Y en PlanCraft (planificación estrictamente secuencial y dependiente del estado), cada variante de MAS degrada el rendimiento (~-39% a -70%), porque los gastos generales de coordinación consumen presupuesto sin proporcionar una ventaja paralela real.
El antídoto práctico es imponer alguna estructura en su MAS asignando agentes a planos funcionales y utilizando el control central para suprimir la propagación de errores y la dispersión de la coordinación.
Esto nos lleva a la contribución principal del artículo: las leyes de escala de agencia.
Las leyes de escala de la agencia
Con base en los hallazgos de Kim et al., podemos derivar tres reglas de oro para construir una arquitectura de coordinación agente efectiva:
La regla 17x: las redes no estructuradas amplifican los errores exponencialmente. Nuestro Plano de Control Centralizado (el Orquestador) suprime esto actuando como un único punto de verificación. La compensación entre herramientas y coordinación: más herramientas requieren más conexión a tierra. Nuestro plano de contexto (retriever) garantiza que los agentes no "adivinen" cómo utilizar las herramientas, lo que reduce el ruido que genera gastos generales. El punto de saturación del 45%: la coordinación de agentes produce los mayores rendimientos cuando el rendimiento de un solo agente es bajo. A medida que los modelos se vuelven más inteligentes, debemos apoyarnos en el Agente Monitor para simplificar la topología y evitar complejidades innecesarias.
En mi experiencia, la capa de Garantía suele ser el mayor diferenciador para mejorar el rendimiento de MAS. El bucle “Assurance → Planner” transforma nuestro MAS de un sistema de bucle abierto (disparar y olvidar) a un sistema de bucle cerrado (autocorrección) que contiene la propagación de errores y permite que la inteligencia escale a tareas más complejas.
Equipos de agentes de modelo mixto: cuando los LLM heterogéneos ayudan (y cuando perjudican)
El equipo de DeepMind prueba explícitamente equipos heterogéneos, es decir, un LLM base diferente para el Orchestrator que para los subagentes, y capacidades combinadas en un debate descentralizado. Las lecciones aquí son muy interesantes desde un punto de vista práctico. Informan tres hallazgos principales (que se muestran en la tarea/conjunto de datos de BrowseComp-Plus):
MAS centralizado: la combinación puede ayudar o perjudicar según la familia de modelos. Para Anthropic, un orquestador de baja capacidad + subagentes de alta capacidad supera a un equipo centralizado de alta capacidad (0,42 frente a 0,32, +31%). Para OpenAI y Gemini, las configuraciones centralizadas heterogéneas se degradan frente a las homogéneas de alta capacidad.
Conclusión: un orquestador débil puede convertirse en un cuello de botella en algunas familias, incluso si los trabajadores son fuertes (porque es el cuello de botella de enrutamiento/síntesis).
2. MAS descentralizado: el debate sobre las capacidades mixtas es sorprendentemente sólido
El debate descentralizado de capacidades mixtas es casi óptimo o, a veces, mejor que las líneas de base homogéneas de alta capacidad (dan ejemplos: OpenAI 0,53 frente a 0,50; Anthropic 0,47 frente a 0,37; Gemini 0,42 frente a 0,43).
Conclusión: la votación/verificación por pares puede “promediar” a los agentes más débiles, por lo que la heterogeneidad duele menos de lo que cabría esperar.
3. En los sistemas centralizados, la capacidad del subagente importa más que la capacidad del orquestador.
En todas las familias, las configuraciones con subagentes de alta capacidad superan a aquellas con orquestadores de alta capacidad.
El mensaje clave general práctico del equipo de DeepMind es que si está gastando dinero de forma selectiva, gástelo en los trabajadores (los agentes que producen la sustancia), no necesariamente en el gerente, sino valídelo en su familia modelo porque el patrón de “orquestador barato + trabajadores fuertes” no se generalizó de manera uniforme.
Comprender el costo de un sistema multiagente
Una pregunta frecuente es cómo definir el costo de un MAS, es decir, el presupuesto simbólico que finalmente se traduce en dólares. La topología determina si agregar agentes compra trabajo paralelo o simplemente compra más comunicación. Para concretar el coste, podemos modelarlo con un pequeño juego de pomos:
k = iteraciones máximas por agente (cuántos pasos de planificación/actuación/reflexión está permitido a cada agente) n = número de agentes (cuántos “trabajadores” generamos) r = rondas de orquestador (cuántos ciclos de asignación → recopilación → revisión ejecutamos) d = rondas de debate (cuántas rondas de ida y vuelta antes de una votación/decisión) p = rondas de comunicación entre pares (con qué frecuencia los agentes hablan directamente entre sí) m = promedio de solicitudes de pares por ronda (cuántos mensajes de pares envía cada agente por ronda de pares)
Una forma práctica de pensar en el costo total es:
Costo total MAS ≈ Costo de obra + Costo de coordinación
El costo del trabajo depende principalmente de n × k (cuántos agentes ejecuta y cuántos pasos toma cada uno). El costo de coordinación depende de las rondas × distribución, es decir, cuántas veces recoordinamos (r, d, p) multiplicada por la cantidad de mensajes que se intercambian (n, m), más el impuesto oculto de que los agentes tengan que leer todo ese contexto adicional.
Para convertir esto a dólares, primero use las perillas (n, k, r, d, p, m) para estimar el total de tokens de entrada/salida generados y consumidos, luego multiplique por el precio por token de su modelo:
$ Costo ≈ (Tokens de entrada ÷ 1M × $/1M_entrada) + (Tokens de salida ÷ 1M × $/1M_salida)
Dónde:
Los InputTokens incluyen todo lo que leen los agentes (transcripción compartida, documentos recuperados, resultados de herramientas, mensajes de otros agentes). Los OutputTokens incluyen todo lo que escriben los agentes (planes, razonamientos intermedios, mensajes de debate, síntesis final).
Esta es la razón por la que las topologías descentralizadas e híbridas pueden volverse costosas muy rápidamente: el debate y la mensajería entre pares inflan tanto el volumen del mensaje como la longitud del contexto, por lo que pagamos el doble ya que los agentes generan más texto y todos tienen que leer más texto. En la práctica, una vez que los agentes comienzan a comunicarse ampliamente entre sí, la coordinación puede comenzar a sentirse más cercana a un efecto n².
La conclusión clave es que el escalamiento de agentes solo es útil si la tarea gana más con el paralelismo de lo que pierde con la coordinación general. Deberíamos utilizar más agentes cuando el trabajo pueda paralelizarse claramente (investigación, búsqueda, intentos de solución independientes). Por el contrario, debemos ser cautelosos cuando la tarea es secuencial y está estrechamente acoplada (razonamiento de varios pasos, largas cadenas de dependencia), porque rondas adicionales y conversaciones cruzadas pueden romper la cadena lógica y convertir “más agentes” en “más ruido”.
Ley de escalamiento de arquitectura MAS: hacer que el diseño de MAS se base en datos en lugar de ser exhaustivo
Una pregunta natural es si los sistemas multiagente tienen “leyes de escalamiento de arquitectura”, análogas a las leyes de escalamiento empírico para los parámetros LLM. Kim y cols. argumenta la respuesta es sí. Para abordar el problema de búsqueda combinatoria (topología × recuento de agentes × rondas × familia de modelos), evaluaron 180 configuraciones en cuatro puntos de referencia y luego entrenaron un modelo predictivo en trazas de coordinación (p. ej., eficiencia frente a gastos generales, amplificación de errores, redundancia). El modelo puede pronosticar qué topología probablemente funcionará mejor, alcanzando R² ≈ 0,513 y seleccionando la mejor estrategia de coordinación para ~87 % de las configuraciones retenidas. El cambio práctico es pasar de “probarlo todo” a ejecutar un pequeño conjunto de configuraciones de sonda cortas (mucho más baratas y rápidas), medir la dinámica de coordinación temprana y solo entonces comprometer todo el presupuesto a las arquitecturas que el modelo predice que ganarán.
Conclusiones y reflexiones finales
En esta publicación, revisamos Towards a Science of Scaling Agent Systems de DeepMind y resumimos las lecciones más prácticas para construir sistemas multiagente de mayor rendimiento. Estas reglas de diseño nos ayudan a evitar husmear en la oscuridad y esperar lo mejor. La conclusión principal es que más agentes no es un camino garantizado hacia mejores resultados. El escalamiento de agentes implica compensaciones reales, regidas por leyes de escalamiento mensurables, y el número "correcto" de agentes depende de la dificultad de la tarea, la capacidad del modelo base y cómo está organizado el sistema.
Esto es lo que sugiere la investigación sobre la cantidad de agente:
Rendimientos decrecientes (saturación): Agregar agentes no produce ganancias indefinidas. En muchos experimentos, el rendimiento aumenta inicialmente, luego se estabiliza (a menudo alrededor de ~4 agentes), después de lo cual los agentes adicionales contribuyen poco. La “regla del 45%”: los agentes adicionales ayudan más cuando el modelo base tiene un desempeño deficiente en la tarea (menos de ~45%). Cuando el modelo base ya es sólido, agregar agentes puede desencadenar una saturación de capacidades, donde el desempeño se estanca o se vuelve ruidoso en lugar de mejorar. La topología importa: la cantidad por sí sola no es la historia; la organización domina los resultados. Los diseños centralizados tienden a escalar de manera más confiable, y un Orchestrator ayuda a contener errores y hacer cumplir la estructura. Los diseños descentralizados de “bolsa de agentes” pueden volverse volátiles a medida que el grupo crece, amplificando a veces los errores en lugar de refinar el razonamiento. Trabajo paralelo versus trabajo secuencial: más agentes destacan en tareas paralelizables (por ejemplo, investigación amplia), donde pueden aumentar materialmente la cobertura y el rendimiento. Pero para el razonamiento secuencial, agregar agentes puede degradar el rendimiento a medida que la “cadena lógica” se debilita cuando se pasan por demasiados pasos. El impuesto de coordinación: cada agente adicional añade gastos generales. Más mensajes, más latencia, más oportunidades de deriva. Si la tarea no es lo suficientemente compleja como para justificar esos gastos generales, los costos de coordinación superan los beneficios de los "cerebros" adicionales de LLM.
Con estas reglas de oro de la agencia en mente, quiero terminar deseándole lo mejor en su desarrollo de MAS. Los sistemas multiagente se encuentran justo en la frontera de la IA aplicada actual, preparados para aportar el siguiente nivel de valor empresarial en 2026, y vienen con los tipos de compensaciones técnicas que hacen que este trabajo sea realmente interesante: equilibrar la capacidad, la coordinación y el diseño para obtener un rendimiento confiable. Al construir su propio MAS, sin duda descubrirá sus propias reglas de oro que amplían nuestro conocimiento sobre este territorio inexplorado.
Una reflexión final sobre el umbral del “45%” de DeepMind: los sistemas multiagente son, en muchos sentidos, una solución alternativa para los límites de los LLM actuales. A medida que los modelos básicos se vuelven más capaces, menos tareas se ubicarán en el régimen de baja precisión donde los agentes adicionales agregan valor real. Con el tiempo, es posible que necesitemos menos descomposición y coordinación, y es posible que se puedan resolver más problemas con un único modelo de extremo a extremo, a medida que avanzamos hacia la inteligencia artificial general (AGI).
Parafraseando a Tolkien: un modelo aún puede gobernarlos a todos.
📚 Aprendizaje adicional
Yubin Kim et al. (2025) – Hacia una ciencia de los sistemas de agentes de escala: un gran estudio controlado que deriva principios de escalamiento cuantitativo para sistemas de agentes en múltiples topologías de coordinación, familias de modelos y puntos de referencia (incluidos los efectos de saturación y los gastos generales de coordinación). Cursor Team (2026): escalamiento de la codificación autónoma de larga duración: un estudio de caso práctico que describe cómo Cursor coordina una gran cantidad de agentes de codificación durante ejecuciones extendidas (incluido su experimento de “construir un navegador web”) y lo que eso implica para las topologías de estilo planificador-trabajador. Lei Wang et al. (2023): una encuesta sobre agentes autónomos basados en modelos de lenguaje grande: una encuesta integral que mapea el espacio de diseño del agente (planificación, memoria, herramientas, patrones de interacción), útil para fundamentar su taxonomía de 10 arquetipos en la literatura anterior. Qingyun Wu et al. (2023) – AutoGen: Habilitación de aplicaciones LLM de próxima generación a través de conversaciones con múltiples agentes: un documento marco sobre la programación de conversaciones y patrones de interacción entre múltiples agentes, con resultados empíricos en todas las tareas y configuraciones de agentes. Shunyu Yao et al. (2022) – ReAct: Sinergizar el razonamiento y la actuación en modelos lingüísticos: presenta el ciclo entrelazado “razón + acto” que sustenta muchos diseños de agentes modernos que utilizan herramientas y ayuda a reducir las alucinaciones a través de acciones fundamentadas. Noah Shinn et al. (2023) – Reflexión: agentes del lenguaje con aprendizaje por refuerzo verbal: una plantilla limpia para la mejora de circuito cerrado: los agentes reflexionan sobre la retroalimentación y almacenan "lecciones aprendidas" en la memoria para mejorar los intentos posteriores sin actualizaciones de peso. LangChain (nd) – Multiagente: documentación práctica que cubre patrones comunes de múltiples agentes y cómo estructurar la interacción para evitar la charla incontrolada sobre la "bolsa de agentes". LangChain (sin fecha): descripción general de LangGraph: una descripción general enfocada de las funciones de orquestación que son importantes para los sistemas reales (ejecución duradera, participación humana, transmisión y flujo de control). langchain-ai (nd) – LangGraph (repositorio de GitHub): la implementación de referencia para una capa de orquestación basada en gráficos, útil si los lectores desean inspeccionar opciones de diseño concretas y primitivas para agentes con estado. Frederick P. Brooks, Jr. (1975) — The Mythical Man-Month — La clásica lección de coordinación (Ley de Brooks) que se traduce sorprendentemente bien en los sistemas de agentes: agregar más “trabajadores” puede aumentar los gastos generales y ralentizar el progreso sin la estructura adecuada.