Guía · Avanzado · 11 min
Sistemas multiagente: cuándo conviene usar varios agentes, arquitecturas, costos y riesgos
Los sistemas multiagente reparten el trabajo entre agentes especializados. Descubra cuándo utilizarlos, cómo organizarlos y cómo mantener sus costos bajo control.
Un sistema multiagente resulta útil cuando el trabajo puede dividirse en misiones independientes, requiere contextos especializados o necesita permisos separados. Puede ampliar la cobertura de un tema y acortar algunos plazos, pero también añade intercambios, costos y posibles fallos. Para decidir si conviene, compare sus resultados con los de un único agente bien equipado y conserve solo las delegaciones cuyo beneficio haya medido.
Qué distingue a varios agentes de un simple flujo de trabajo
Un sistema multiagente coordina varios agentes capaces de tomar decisiones dentro de su ámbito. Cada uno recibe una misión, puede utilizar herramientas y entrega un resultado. Todos pueden compartir el mismo modelo: lo que los diferencia también son sus instrucciones, su contexto, su estado y sus permisos.
Por tanto, encadenar extracción, traducción y formato no equivale automáticamente a formar un equipo de agentes. Si cada etapa aplica una operación predefinida, se trata de un flujo de trabajo. Esta solución suele ser preferible cuando el proceso es estable, porque resulta más fácil comprobar el recorrido que sigue.
La orquestación determina quién recibe cada tarea, en qué orden, con qué información y según qué regla de parada. Puede programarse, dejarse en manos de un modelo o combinar ambas opciones. Que una decisión sea flexible no obliga a que todo el sistema lo sea.
La guía de referencia de Anthropic Building effective agents distingue precisamente entre recorridos predefinidos y decisiones dinámicas. Esta diferencia ayuda a evitar una confusión frecuente: multiplicar los roles con nombre propio no demuestra que exista más autonomía ni que mejore la calidad.
Para identificar las herramientas disponibles, el directorio de agentes y frameworks reúne sus fichas. Aun así, la arquitectura debe partir de la necesidad que se quiere resolver, antes de elegir un framework o recurrir a la idea de un equipo humano.
Cuándo aporta valor la delegación
El primer caso favorable es una investigación que pueda dividirse. Para comparar proveedores, distintos agentes pueden examinar por separado la documentación técnica, las condiciones contractuales y las opciones de integración. El coordinador reúne después los resultados con unos criterios comunes. Este ejemplo describe una arquitectura posible, no un caso de cliente con resultados medidos.
El segundo caso es el aislamiento del contexto. Una investigación puede generar numerosos documentos y resultados intermedios, aunque solo una pequeña parte sea útil para la decisión final. Un subagente puede explorar ese material y devolver una síntesis acompañada de evidencias, sin sobrecargar la conversación principal.
El tercer caso responde a límites operativos. Un agente consulta información pública y otro accede a un sistema interno con permisos restringidos. Esta separación solo protege los datos si la infraestructura hace cumplir las restricciones.
En su artículo técnico sobre su sistema de investigación multiagente, publicado en junio de 2025, Anthropic describe una organización con un coordinador y subagentes que trabajan en paralelo. El artículo se refiere a su propio sistema; no demuestra que una arquitectura similar mejore cualquier tarea.
En cambio, mantenga un único agente cuando las etapas dependan estrechamente unas de otras, el contexto quepa con facilidad en una sesión o la misión sea breve. Antes de delegar, compruebe también si basta con mejorar las herramientas, precisar las instrucciones o facilitar un acceso más selectivo a la documentación.
Arquitecturas y sus contrapartidas
Los siguientes esquemas responden a necesidades diferentes. Pueden combinarse, pero cada combinación aumenta la cantidad de transiciones que habrá que explicar, supervisar y probar.
| Arquitectura | Organización | Uso adecuado | Costo de coordinación | Riesgo principal |
|---|---|---|---|---|
| Cadena secuencial | Cada agente entrega su resultado al siguiente | Etapas especializadas con entregables distintos | Traspasos sucesivos | Un error inicial se propaga |
| Coordinador y ejecutores | Un agente delega y después integra los resultados | Investigaciones divisibles y consultas específicas | Planificación y síntesis | El coordinador se convierte en un cuello de botella |
| Enrutamiento | La solicitud se envía al especialista elegido | Categorías de solicitudes bien diferenciadas | Clasificación inicial | Asignación al especialista equivocado |
| Traspaso | Un especialista toma el control de la conversación | Procesos que requieren distintas competencias sucesivas | Transferencia de contexto y responsabilidad | Traspasos repetidos o pérdida de contexto |
| Producción y verificación | Un agente produce y otro comprueba | Resultados con criterios verificables | Revisión y correcciones | Coincidencia engañosa entre agentes |
Una cadena secuencial mantiene un orden claro, pero no necesariamente reduce el tiempo de respuesta. El trabajo en paralelo solo aporta una ventaja cuando las ramas son independientes. Si cada agente espera al anterior, lo que añade principalmente son separaciones entre contextos.
Un coordinador central facilita la asignación de misiones y la integración final. A cambio, debe entender los resultados recibidos, detectar contradicciones y decidir si falta alguna evidencia. Interpretar mal un resumen puede echar a perder una investigación bien realizada.
La documentación de LangChain sobre arquitecturas multiagente presenta, entre otras opciones, subagentes, enrutamiento y traspasos. También recuerda que un único agente, con las herramientas y el contexto adecuados, puede bastar para una tarea compleja.
Elija, por tanto, el esquema según las dependencias del trabajo. Una organización que se parece a un organigrama humano no tiene por qué ser adecuada para un programa.
Definir misiones y traspasos verificables
Un rol como «especialista en calidad» no basta para delimitar una delegación. El subagente debe recibir una pregunta concreta, un ámbito de actuación, las fuentes permitidas y una descripción del resultado esperado. También debe saber cuándo detenerse y cómo comunicar que no puede completar la misión.
En una investigación documental, la definición de la misión puede especificar:
- los puntos que deben establecerse y los que quedan fuera del alcance;
- los documentos accesibles y su nivel de confianza;
- el formato de los hallazgos y las referencias;
- los límites de tiempo, gasto y llamadas a herramientas;
- las condiciones para trasladar un problema al coordinador.
El entregable debe distinguir los hechos establecidos, las hipótesis y las cuestiones pendientes. Una respuesta bien redactada pero sin referencias no permite al coordinador verificarla. Solicite los elementos necesarios para comprobar el resultado: el fragmento de la fuente, la fecha relevante, el resultado de una herramienta o el identificador del documento consultado.
Evite también los traspasos que copian sistemáticamente toda la conversación. Difunden datos innecesarios y aumentan el volumen que debe procesarse. En el extremo contrario, una misión con demasiado poco contexto obliga al especialista a repetir una exploración que ya se había realizado.
El contexto adecuado contiene el objetivo general necesario, las restricciones aplicables y los documentos pertinentes. El coordinador mantiene un registro de las misiones: responsable, estado, dependencias, entregable esperado y motivo de finalización. Este registro permite detectar tareas abandonadas, duplicaciones y resultados que llegan después de la decisión final.
Organizar el estado compartido y el acceso a las herramientas
Separe el estado de cada agente de la información que se considera válida para el conjunto del sistema. Las notas de exploración pueden permanecer en el contexto local. Las decisiones validadas, los entregables y las referencias deben incorporarse a un espacio controlado, con su procedencia y versión.
Cuando se trabaje con archivos, asigne expresamente la responsabilidad de modificarlos. Si varios agentes editan el mismo documento al mismo tiempo, pueden sobrescribir cambios o trabajar sobre supuestos incompatibles. Utilizar espacios separados y realizar después una integración controlada permite hacer visibles los conflictos.
La recuperación tras un fallo exige el mismo cuidado. Antes de repetir una acción, compruebe si ya se completó. La creación de un ticket o un envío no deben repetirse solo porque se haya perdido la respuesta de la herramienta. Utilice identificadores de operación y mecanismos para evitar duplicados cuando el servicio lo permita.
Los protocolos no resuelven automáticamente estos problemas. La arquitectura oficial de MCP describe los intercambios entre aplicaciones y servidores que ofrecen, entre otras cosas, herramientas y recursos. No sustituye su política de asignación de tareas.
La documentación del protocolo A2A aborda la comunicación y la colaboración entre agentes. Un sistema interno puede funcionar sin este protocolo; su utilidad depende de las necesidades de interoperabilidad.
En cualquier caso, defina quién puede leer, modificar y transmitir cada dato. Un mensaje entre agentes sigue siendo una transferencia de información, aunque ambos pertenezcan al mismo proyecto.
Calcular el costo por tarea aceptada
La cantidad de agentes no permite anticipar directamente la factura. El costo depende de las llamadas al modelo, los volúmenes procesados, las herramientas de pago, la infraestructura y los reintentos. Un equipo con contextos breves puede consumir menos que un agente que relee continuamente un historial extenso.
En cada llamada, distinga los tokens de entrada, los de salida y las posibles categorías que se facturen por separado. Aplique las tarifas utilizadas y sume después los gastos de los agentes y del coordinador. La calculadora de precios de LLM ayuda a preparar estas estimaciones.
Ejemplo aritmético ficticio, sin medición de rendimiento. La ficha de Claude Sonnet 5.5 indica 2 dólares por millón de tokens de entrada y 10 dólares por millón de tokens de salida, según los datos recogidos por el sitio en octubre de 2026. Con esas tarifas, una llamada hipotética de 10 000 tokens de entrada y 2 000 de salida cuesta 0,04 dólares, sin incluir otros conceptos ni mecanismos de facturación.
Cuatro llamadas idénticas costarían, por tanto, 0,16 dólares. Esto no implica necesariamente cuatro agentes: un único agente puede realizar esas llamadas, mientras que un equipo puede realizar muchas más. El ejemplo ilustra un método de cálculo, no un presupuesto habitual.
Mida sobre todo el costo por tarea aceptada: el gasto de todos los intentos dividido entre la cantidad de resultados que cumplen sus criterios. Contabilice por separado el tiempo dedicado a las correcciones humanas. Una arquitectura más barata por intento puede acabar costando más si exige repetir el trabajo con mayor frecuencia.
Controlar los plazos, los presupuestos y la parada
Cuando se trabaja en paralelo, el plazo depende de la rama más lenta y de la integración final. También hay que contar las colas de espera, los límites de los servicios y los posibles controles humanos. Iniciar más tareas no garantiza, por tanto, una respuesta más rápida.
Además, una rama puede dejar de ser útil después de un hallazgo realizado en otra. Prevea un mecanismo de cancelación y una forma de recuperar el trabajo parcial. De lo contrario, el sistema seguirá gastando aunque la decisión ya esté tomada.
Establezca límites en varios niveles: misión global, subtarea y herramienta. Pueden referirse al tiempo, al gasto, a los intentos o a la profundidad de las delegaciones. El coordinador no debe poder eludir un límite creando nuevos ejecutores.
Defina también los estados de salida: resultado completo, resultado parcial, bloqueo técnico, evidencia insuficiente o validación pendiente. Superar el presupuesto no debe traducirse en una respuesta que aparente estar completa.
La guía Reducir el costo de un agente de IA profundiza en el contexto, el enrutamiento y los presupuestos. En un sistema multiagente, añada una regla: cada nueva delegación debe tener un motivo explícito.
Elegir un framework según las necesidades de operación
Conviene distinguir dos enfoques. LangGraph permite representar expresamente las etapas y transiciones de un sistema. Su documentación sobre flujos de trabajo y agentes presenta, entre otros, esquemas de enrutamiento, ejecución en paralelo y coordinación.
CrewAI organiza el trabajo, entre otros elementos, en torno a agentes y tareas. Su documentación de procesos describe organizaciones secuenciales y jerárquicas. Estos conceptos pueden facilitar la representación de un reparto de responsabilidades.
| Criterio de diseño | Enfoque basado en un grafo explícito | Enfoque basado en equipos y tareas |
|---|---|---|
| Descripción del trabajo | Estados, transiciones y condiciones | Misiones, roles y delegaciones |
| Control buscado | Recorridos y reanudaciones visibles | Asignación de tareas fácil de entender |
| Principal punto de atención | Complejidad del grafo | Delegaciones demasiado abiertas |
| Verificación necesaria | Transiciones y estado persistente | Misiones y entregables transferidos |
Esta tabla compara enfoques, no establece una frontera absoluta entre productos. Un framework puede ofrecer varias abstracciones; disponer de ellas no demuestra que su aplicación gestione correctamente los incidentes.
Antes de elegir una biblioteca, compruebe la conservación del estado, la cancelación, la inspección de las ejecuciones, la gestión de secretos y la posibilidad de sustituir un modelo. Pruebe estas funciones en un escenario con fallos.
El artículo sobre cómo elegir un framework de agentes de IA complementa esta guía con un enfoque centrado en el aprendizaje y las herramientas. Para una tarea acotada, también puede bastar con programar la orquestación dentro de su aplicación.
Riesgos de fiabilidad y seguridad
El primer riesgo es el error compartido. Los agentes que utilizan las mismas fuentes o reciben la misma hipótesis inicial pueden coincidir en una respuesta falsa. Su acuerdo no equivale a una validación independiente.
Para la revisión, proporcione al verificador criterios observables y acceso a las evidencias originales. Pídale que busque defectos concretos: una referencia ausente, un cálculo incorrecto, una restricción olvidada o una acción no autorizada. Los controles de software deben encargarse de lo que pueda comprobarse de forma mecánica.
El segundo riesgo es que las instrucciones pierdan fuerza durante los traspasos. Una restricción global puede desaparecer al transferir una misión. Las reglas esenciales deben aplicarse mediante el orquestador y las herramientas, en lugar de depender únicamente de un recordatorio escrito.
El tercer riesgo afecta a los contenidos maliciosos. Un documento externo puede inducir a un agente a transmitir una instrucción manipulada a su coordinador. Que un mensaje proceda de un subagente no convierte el contenido citado en una instrucción fiable.
Limite, por tanto, los permisos de cada ejecutor, mantenga los secretos fuera de su contexto y controle las salidas al exterior. La validación de una acción sensible debe referirse a sus parámetros exactos. Una aprobación general del plan no basta para autorizar todas sus consecuencias.
La guía Proteger un agente de IA desarrolla estas medidas. En un equipo de agentes, deben aplicarse a lo largo de toda la cadena de delegación.
Evaluar el beneficio antes del despliegue
Prepare un conjunto de tareas representativas antes de multiplicar los roles. Incluya solicitudes sencillas, ambiguas, incompletas y difíciles, así como situaciones en las que las herramientas no estén disponibles. Defina para cada caso qué constituye una respuesta aceptable y qué obliga a detenerse.
Compare el flujo determinista, cuando se conozca el recorrido, con el agente único y la arquitectura multiagente propuesta. Mantenga condiciones comparables: acceso a los datos, herramientas, presupuesto máximo y criterios de calidad. Si cambia a la vez el modelo y la arquitectura, no podrá atribuir con claridad la mejora a ninguno de ellos.
Observe el éxito final, los errores críticos, el costo por resultado aceptado, los plazos y las intervenciones humanas. Repita las pruebas cuando los resultados varíen. Un promedio favorable puede ocultar bloqueos prolongados o fallos costosos.
Examine después los registros de ejecución para identificar problemas: una división inadecuada del trabajo, tareas duplicadas, evidencias perdidas, una síntesis incorrecta o permisos excesivos. Elimine temporalmente una delegación para comprobar qué aporta. Si su ausencia no empeora el resultado, conviene simplificar esa parte de la arquitectura.
Antes de poner el sistema en producción:
- cada misión tiene un entregable y una regla de parada;
- los presupuestos y los permisos se hacen cumplir mediante controles técnicos;
- las modificaciones simultáneas y los reintentos están controlados;
- el verificador conserva acceso a las evidencias;
- los resultados se comparan con los de una solución más sencilla;
- las acciones sensibles cuentan con una validación adecuada.
Mantenga también la posibilidad de volver al sistema anterior. Una arquitectura multiagente se justifica cuando ofrece un resultado más completo, más fiable o disponible en un plazo útil, con un costo que pueda explicarse. La cantidad de participantes sigue siendo una decisión de diseño, nunca una medida de calidad.
Páginas relacionadas
Preguntas frecuentes
¿Se necesitan varios modelos para crear un sistema multiagente?
No. Varios agentes pueden utilizar el mismo modelo con instrucciones, herramientas y contextos diferentes. Emplear modelos distintos es una decisión de diseño que debe evaluarse según la calidad obtenida y el costo total.
¿Puede funcionar un sistema multiagente en un entorno local?
Sí, siempre que los modelos y las herramientas elegidos puedan ejecutarse en su infraestructura. Sin embargo, los agentes compiten por los recursos disponibles: varias tareas iniciadas a la vez pueden acabar esperando al mismo motor de inferencia.
¿Qué diferencia hay entre un subagente y una llamada a una herramienta?
Una herramienta ejecuta una función definida, mientras que un subagente puede elegir sus propios pasos para cumplir una misión. Aun así, el coordinador puede invocar un subagente mediante una interfaz de herramienta: ambos conceptos describen niveles diferentes.
¿Cuántos agentes conviene utilizar?
No existe una cantidad óptima para todos los casos. Empiece con una arquitectura sencilla y añada una delegación solo cuando resuelva una limitación observada. La cantidad útil depende de las tareas independientes, los plazos y el presupuesto disponible.
¿Se puede dejar que los agentes se supervisen entre sí?
La revisión entre agentes puede detectar algunos errores, pero no ofrece una garantía. Para una acción sensible, combine controles de software, permisos limitados y una validación humana proporcional a sus consecuencias.