Cómo los subagentes y los sistemas multiagente dividen el trabajo y los tokens de costo.
Subagentes vs sistemas multiagente: el diseño orquestador-trabajador, cuatro topologías, cuánto cuesta cada uno en tokens, y los casos en los que un único agente funciona mejor.
Fuentes: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
Por qué un agente solitario llega a su límite
Cualquiera que haya visto funcionar Claude Code, LangGraph o la función de investigación de Claude ha presenciado el momento en que el asistente deja de responder por sí mismo y busca ayuda. Aparece un ayudante encargado de buscar archivos, investiga y regresa con los resultados. Una pregunta de investigación consulta silenciosamente una docena de fuentes en el tiempo que tarda una persona en abrir dos pestañas. El modelo no se ha vuelto de repente más inteligente; es un pequeño equipo el que realiza el trabajo.
A continuación se presenta una explicación sencilla de cómo se organiza ese trabajo en equipo, abordando los subagentes, los sistemas multiagente, su arquitectura subyacente y su costo.
Un agente único, es decir, un modelo que funciona en bucle con herramientas, es capaz de leer archivos, navegar, escribir código y razonar a través de numerosos pasos. Sin embargo, el diseño incluye tres limitaciones:
- Una ventana de contexto. Todo lo que el agente lee, piensa y hace se acumula en el mismo espacio. En una tarea exploratoria prolongada, la salida de las herramientas acaba haciendo que la pregunta original pierda importancia.
- Una sola línea de ejecución. El trabajo se realiza de forma secuencial. Cincuenta búsquedas de dos segundos cada una consumen más de noventa segundos antes de que comience cualquier escritura.
- Una sola perspectiva. Un único prompt determina cada decisión, por lo que al agente le resulta difícil mantener dos enfoques rivales al mismo tiempo o identificar sus propios puntos ciegos.
Los subagentes y los sistemas multiagente son dos soluciones a este problema, que a menudo se combinan. El resto explica qué es cada uno, cómo se estructuran y cuándo resultan rentables.
Qué es un subagente
Un subagente es una herramienta de alcance limitado que se activa dentro de una sesión. Se encarga de una tarea específica en una ventana de contexto propia y luego informa al respecto.
Claude Code es una buena ilustración. Si la sesión principal de programación debe comprender alguna parte desconocida de un código, puede transferir esa tarea a un subagente y así liberar la conversación principal. El subagente:
- comienza con una ventana de contexto nueva y limpia
- generalmente cuenta con un conjunto más reducido y restringido de herramientas
- ejecuta su propio ciclo de lectura, búsqueda y razonamiento
- envía un resumen a la sesión principal y conserva el registro para sí mismo
El valor aquí es aislamiento, no inteligencia adicional. La conversación principal nunca ve los cincuenta archivos que abrió el asistente, solo las tres frases importantes, por lo que el hilo principal mantiene su agudeza a lo largo de una sesión larga y no se llena de ruido.
Algunas características definen este patrón en las herramientas como Claude Code que lo implementan:
- Los subagentes existen dentro de una sola sesión. Son una forma de delegar tareas, no procesos independientes en ejecución.
- Por lo general, no pueden iniciar subagentes propios, lo que mantiene la jerarquía simple y fácil de seguir.
- La definición de un subagente se escribe una vez y se reutiliza. Al darle a un subagente de revisión un prompt del sistema fijo y una lista corta de herramientas, actúa de manera idéntica en cada llamada.
Qué es un sistema multiagente
Un sistema multiagente tiene una estructura diferente. Varios agentes independientes, cada uno con su propio contexto, sus propias herramientas y a veces su propio modelo, persiguen un objetivo común, generalmente en un proceso más largo o complicado que la delegación en una sola sesión.
La función de investigación de Anthropic es el caso público más conocido. Una pregunta amplia no se responde directamente. En su lugar, un agente principal elabora un enfoque y genera varios subagentes, cada uno analizando un ángulo diferente al mismo tiempo. Sus resultados se combinan, se verifica la precisión de las fuentes y se devuelven como una sola respuesta.
En conjunto, un agente líder, especialistas paralelos y un paso de síntesis final conforman el patrón que utilizan la mayoría de los sistemas multiagente de producción hoy en día, y es el diseño que se analiza en el resto de este artículo.
Dónde difieren las dos ideas
En línea estos términos se usan de manera intercambiable, lo que genera confusión. La distinción real se muestra aquí.
La forma más sencilla de recordarlo es: un subagente es una técnica utilizada dentro de un agente, mientras que un sistema multiagente es una arquitectura diseñada alrededor de varios agentes. En la práctica, muchos sistemas multiagente se construyen a partir del patrón de subagentes. Un agente líder que emplea subagentes es ambas cosas al mismo tiempo.
La arquitectura de orquestador y trabajadores
Casi todos los sistemas multiagente de producción, incluida la función de investigación de Anthropic, el patrón de supervisor de LangGraph y el modelo de subagente de Claude Code, son alguna variante de un mismo diseño: orquestador y trabajador.
Cada componente tiene una responsabilidad específica:
- Agente líder (orquestador). Lee la consulta, elabora una estrategia y evalúa cuánto esfuerzo requiere la tarea. Esa evaluación es más importante de lo que parece. Las versiones iniciales de estos sistemas a veces lanzaban cincuenta subagentes para una pregunta que solo necesitaba uno.
- Memoria o área de trabajo temporal. El plan se escribe fuera de la conversación. Las ejecuciones prolongadas de los agentes pueden superar el límite de contexto del modelo, y si eso ocurre a mitad de camino, el plan debe sobrevivir a la truncación y no desaparecer junto con ella.
- Subagentes. Cada uno recibe un objetivo claro, un formato de salida definido, recomendaciones sobre qué herramientas y fuentes utilizar, y límites estrictos para que dos de ellos no repitan en silencio el trabajo del otro. Cada uno ejecuta su propio ciclo de búsqueda, evaluación y perfeccionamiento.
- Agente de citación (o paso de síntesis y validación). Una fase separada compara el borrador con el material de referencia y relaciona cada afirmación con su origen. Separar esta tarea de la redacción realizada por el agente principal mejora significativamente la precisión factual, ya que quien verifica no es quien formuló las afirmaciones.
El diagrama utiliza dos tipos de flechas. Las continuas dirigen las tareas hacia abajo, mientras que las discontinuas dirigen los resultados resumidos hacia arriba. La asimetría es intencional: los subagentes devuelven un resultado condensado y no toda su historia de trabajo, lo que evita que el contexto del agente principal se vuelva excesivo.
El flujo de trabajo desde la pregunta hasta la respuesta
Si nos alejamos de los componentes, este es el orden de los eventos desde la pregunta escrita por el usuario hasta la respuesta final.
Algunos pasos merecen atención:
- Paso 2 (pensar antes de planificar) tiene más importancia de lo que parece. Aquí el sistema determina cuánto esfuerzo merece la consulta: una verificación rápida de hechos podría requerir un agente y unas pocas llamadas a herramientas, mientras que una pregunta de amplio alcance podría necesitar diez o más subagentes con funciones claramente definidas.
- Paso 7 (bucle de retroalimentación) separa a un sistema agente de un flujo fijo. No hay nada programado de antemano, ya que el agente principal examina los resultados y decide entre responder o seguir buscando. Es en esta decisión donde más a menudo surgen problemas. Un agente demasiado reacio a realizar el bucle proporciona respuestas superficiales, mientras que uno demasiado entusiasta con ello pierde tiempo y recursos buscando fuentes que en realidad no existen.
- Pasos 8 y 9, con la citación como etapa independiente, existen porque cuando un agente se encarga de redactar una respuesta y también de evaluar sus propias fuentes, tiende a hacer afirmaciones seguras que no se sostienen. Una segunda revisión independiente permite detectar eso.
Cuatro formas de organizar múltiples agentes
La estructura típica es la de orquestador y trabajadores, pero no es la única. Dependiendo de cómo se divida realmente una tarea, una de las cuatro topologías generales será más adecuada que las demás.
Cuando no está claro qué elegir, los equipos de producción suelen seguir una regla práctica: usar una jerarquía con un supervisor para todo lo que va a producción, y mantener diseños en red o en malla para trabajos exploratorios o de investigación donde el flujo no puede determinarse de antemano. Los diseños en malla se ven elegantes en un diagrama, pero son consistentemente los más difíciles de depurar.
Por qué funciona: la economía de tokens
Es útil ser preciso sobre por qué los sistemas multiagente superan a los de un solo agente en las tareas que logran resolver, ya que la respuesta no es “más agentes significa más inteligencia”.
En las evaluaciones internas de Anthropic, una configuración con Claude Opus 4 como agente principal y Claude Sonnet 4 como subagentes superó a un único agente Claude Opus 4 en un 90,2% según un benchmark de investigación interno. Al analizar las razones, la capacidad explicó la mayor parte del diferencial. En un benchmark de búsqueda compleja, el uso de tokens por sí solo representó alrededor del 80% de la variación en el rendimiento, mientras que el número de llamadas a herramientas y la elección del modelo cubrieron la mayor parte de lo restante.
En resumen, la ventaja en tareas que requieren una gran cantidad de información proviene principalmente de la capacidad. Distribuir el trabajo en ventanas de contexto separadas brinda al sistema mucho más espacio para razonar que lo que ofrece una sola ventana, y cada subagente comprime lo que lee en un informe breve.
La capacidad no es gratuita. Los datos de producción indican que los flujos de trabajo con agentes consumen aproximadamente cuatro veces más tokens que un intercambio de chat normal, y los flujos de trabajo con múltiples agentes, unas quince veces más. Ese factor multiplicador debe determinar si realmente vale la pena utilizar dicha arquitectura, lo cual nos lleva al siguiente punto.
Cuando un sistema de múltiples agentes es la herramienta inadecuada
La mayor parte de los escritos sobre arquitecturas de agentes omiten esta parte, y es precisamente ella la que protege tanto el tiempo como el presupuesto de tokens.
La tarea debe dividirse en partes verdaderamente independientes. Cuando las subtareas dependen en gran medida unas de otras, distribuirlas entre agentes añade una carga de coordinación sin generar un verdadero paralelismo. Las preguntas de investigación separadas se dividen bien, mientras que escribir una función coherente por lo general no lo hace.
La programación es el contrejemplo más claro. La propia descripción de Anthropic es directa: la mayoría de las tareas de programación tienen menos subtareas paralelizables que la investigación, y los agentes actuales aún no son fiables para coordinarse y transferirse tareas entre sí en tiempo real. Otros puntos de referencia coinciden. Una evaluación académica encontró que las configuraciones de programación con múltiples agentes consumen entre 4 veces y más de 200 veces más tokens que un agente individual comparable, y un análisis industrial distinto mostró que los sistemas multiagente rinden de 39 a 70 por ciento peor que un agente único en tareas estrictamente secuenciales.
Los errores se propagan. Una suposición errónea en un agente sigue siendo un único error. Dentro de un sistema coordinado, puede extenderse a través de las transferencias de tareas y crecer. Un análisis estimó una amplificación de aproximadamente 4 veces con orquestación centralizada, y resultados mucho peores cuando los agentes operan de forma independiente sin coordinación.
La recompensa debe cubrir el costo. Con un multiplicador cercano a 15 veces, los diseños multiagente son adecuados para tareas de alto valor y alta complejidad como la investigación profunda, el análisis multidominio y las grandes refactorizaciones. Para cualquier tarea que un agente individual bien instruido con herramientas adecuadas pueda completar de una sola vez, estos diseños son un exceso.
Existe una prueba rápida: cuando no se puede especificar qué debería manejar cada agente de manera distinta a los demás, la solución probable es contar con un agente individual más potente en lugar de añadir más.
Lecciones de su desarrollo
La reflexión de Anthropic sobre su sistema de investigación se encuentra entre los relatos públicos más sinceros sobre qué falla cuando una demostración funcional se convierte en una configuración multiagente en producción. Las lecciones más aplicables, resumidas:
- La formulación de instrucciones es el elemento clave. Dado que las instrucciones guían a cada agente, pequeños cambios en su redacción al asignar tareas tuvieron un efecto considerable en si los subagentes repetían acciones o dejaban espacios en blanco.
- Una delegación poco clara duplica el esfuerzo. Una instrucción como “investigar la escasez de semiconductores” parece clara, pero en realidad no lo es. En los sistemas iniciales varios subagentes exploraron el mismo ángulo, ya que nadie había indicado dónde terminaba una tarea. Una buena instrucción debe especificar el objetivo, el formato esperado del resultado y los límites del alcance de cada agente.
Un esquema mínimo del patrón
Lo que sigue es un esquema simplificado y neutral con respecto a frameworks, que describe al orquestador y al trabajador. Se han omitido las reintentos, el streaming y la memoria persistente para que sea fácil visualizar la estructura lógica, y funciona como pseudocódigo para su adaptación a LangGraph, el Claude Agent SDK o un bucle de API básico.
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
Dos detalles merecen la mayor atención, y ninguno suele aparecer en los ejemplos simplificados. El primero es run_in_parallel: ejecutar a los subagentes uno por uno desperdicia casi todo el aumento de velocidad. El segundo es el bucle while explícito que vuelve a planificar, ya que una sola ronda fija de subagentes no puede adaptarse cuando la primera pasada deja más preguntas que respuestas.
Verificaciones antes del envío
Antes de lanzar un subagente o un flujo de trabajo multiagente, revise los siguientes puntos:
- Cada subagente tiene un objetivo explícito, un formato de salida y unos límites de tarea definidos, y no solo una instrucción de una sola línea.
- Los subagentes se ejecutan en paralelo siempre que sean realmente independientes.
- El plan se guarda en el almacenamiento y no solo se mantiene en la conversación, por si el contexto se acorta.
Leer más
- Cuando dos agentes vencen a uno: Un Copilot de revisión de código LangGraph creado de ambas maneras — Construye un revisor de código como un único agente y también como Analizador más Revisor de riesgos en LangGraph, y luego aprende los tres casos en los que usar sistemas multi-agente vale la pena.
- Notas prácticas: Cómo convertirse en un usuario de agentes Hermes del 1% superior: El playbook completo número ninguno — Guía paso a paso de las Notas prácticas: Cómo convertirse en un usuario de agentes Hermes del 1% superior: El playbook completo número ninguno: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.