Equipos de agentes de Claude Code: Cuándo usar múltiples agentes y cómo hacerlo.

Un equipo orquestado de agentes que se comunican entre sí dentro del ecosistema de Claude Code está al alcance, y una versión final puede funcionar muy bien. Sin embargo, hacer que funcione es más difícil de lo que parece, y muchas personas se lanzan a formar equipos de agentes sin sopesar las contrapartidas. Los equipos de agentes parecen ser el siguiente paso lógico una vez que los subagentes funcionan sin problemas. Pero no lo son automáticamente. Un equipo es una capa de coordinación que conlleva un costo real en tokens, formas conocidas de fallar y un conjunto limitado de problemas que resuelve eficazmente.

La lección menos llamativa extraída de meses de uso real de múltiples agentes es también la más útil: comience con un agente bien configurado, herramientas adecuadas y una gestión disciplinada del contexto. Añada más agentes solo cuando pueda indicar una razón específica. La guía de Anthropic para crear agentes eficaces dice lo mismo, recomendando a los equipos buscar la solución más sencilla viable y añadir complejidad únicamente cuando sea necesario.

A continuación se presenta una forma de analizar la decisión y qué hacer después de tomarla. Se parte de la premisa de que ya está familiarizado con los subagentes, en qué se diferencian de las habilidades y por qué mantener el contexto aislado es la razón principal para utilizarlos. La pregunta abierta es cuándo dejar de ser suficiente un único subagente que informa y qué construir en su lugar.

El material aborda estas áreas:

• Por qué la mayoría de los equipos aún no necesitan varios agentes, y el error común de recurrir a equipos porque parecen más potentes.
• Cuatro factores concretos que indican que un agente ya no tiene suficiente capacidad.
• Cuatro patrones para combinar agentes, en una taxonomía neutral con respecto a los proveedores: orquestador, pipeline, especialistas en paralelo y enjambre.
• La pila Anthropic para equipos de agentes, que separa lo estable de lo experimental o solo disponible en versión preliminar.
• Qué son los equipos de agentes de Claude Code y cómo difieren de los subagentes.
• Cómo se comunican los agentes: tres formas, cuatro patrones de temporización y qué se debe pasar entre ellos.
• Ocho modos de fallo con soluciones prácticas.
• Un marco de toma de decisiones para orquestación nativa, autogestionada o híbrida.

La mayoría de los equipos no necesitan más de un agente

Muchas personas que buscan equipos de agentes están resolviendo el problema equivocado. El razonamiento habitual es que los subagentes funcionaron, que el sistema se está volviendo más complicado y que los equipos representan el siguiente paso. Esa lógica confunde la capacidad con la complejidad. Un equipo no hace que el sistema sea más capaz; lo hace más distribuido, y la distribución es un costo en lugar de una mejora.

La publicación de Anthropic sobre la creación de agentes eficaces explica los aspectos económicos relacionados. Los flujos de trabajo que no son basados en agentes son más predecibles, más económicos y fáciles de depurar; el consejo se resume en lo siguiente: cuando una función ordinaria puede realizar la tarea, es mejor escribir esa función en lugar de reunir a un grupo de distribuciones de probabilidad. Este punto es fácil de pasar por alto para quienes aún no han comprendido que los LLM son modelos probabilísticos. Incluso una instrucción explícita puede seguirse o no correctamente. Cada agente adicional representa un componente más que puede fallar, generar ilusiones o emitir resultados que el siguiente agente interprete erróneamente, por lo que la adición de agentes aumenta exponencialmente las posibilidades de error a gran escala.

El límite para un agente individual es más alto de lo que la gente supone. Un agente solo, dotado de herramientas adecuadas, instrucciones claras del sistema, una delegación eficaz de tareas complejas a subagentes y una gestión cuidadosa del contexto, puede manejar una cantidad sorprendente de trabajo. Se alcanza ese límite cuando se da al menos una de estas cuatro situaciones:

1. La tarea es demasiado grande para caber en una sola ventana de contexto, incluso con la delegación a subagentes.
2. Diferentes partes de la tarea requieren especializaciones realmente distintas, lo que implica acceso a herramientas y limitaciones de comportamiento diferentes, y no simplemente instrucciones distintas.
3. Algunas partes del trabajo pueden realizarse en paralelo, y el tiempo transcurrido es importante.
4. La calidad de la salida necesita una evaluación independiente, por ejemplo por parte de un segundo agente que no haya visto el razonamiento del primero.

Ninguno de estos es una afirmación sobre capacidad. Todos ellos se refieren a la arquitectura. Cuando se aplica uno, los agentes adicionales están justificados. Cuando no se aplica ninguno, solo añaden fricción, y si no se puede señalar uno específico, la opción de un único agente sigue estando disponible.

Los cuatro desencadenantes, con ejemplos

Aislamiento de contexto. Supongamos que el trabajo implica leer docenas de archivos, realizar búsquedas extensivas y almacenar grandes resultados intermedios, ninguno de los cuales necesita permanecer en la sesión principal. Un subagente se encarga de eso. Pero si la investigación es tan grande que incluso el contexto de un subagente se llena, o el trabajo se divide en investigaciones paralelas independientes, entonces se necesitan múltiples agentes. Este es el desencadenante legítimo más común.

Especialización. El trabajo requiere algo más que instrucciones separadas; necesita acceso a herramientas distintas y restricciones de comportamiento diferentes. Un revisor de código que no puede escribir archivos ni ejecutar comandos de shell tiene un perfil de riesgo claramente distinto al de un generador de código. Sin embargo, esas diferencias a menudo pueden codificarse como subagentes separados, cada uno con su propio prompt del sistema y lista restringida de herramientas, por lo que la especialización por sí sola no debería ser la razón para pasar a equipos. La propia documentación sobre agentes y equipos indica que los subagentes son ideales en este caso: contextos aislados, resúmenes devueltos al solicitante e instrucciones específicas para cada tarea.

Trabajo en paralelo. La tarea se divide en subtareas independientes que no comparten estado mutable: tres agentes que examinan al mismo tiempo diferentes aspectos de un error en el código, o cuatro agentes que revisan cada uno otro capítulo de un documento. Esta es la situación en la que los sistemas multiagente generan ahorros reales, ya que los agentes operan simultáneamente. El costo es una mayor cantidad total de tokens, por lo que la transacción solo resulta viable cuando el tiempo transcurrido es más importante que el gasto.

Crítica independiente. El resultado necesita una segunda opinión que no esté influenciada por el razonamiento de la primera. Imagine a un evaluador que solo lee el resultado final y no los razonamientos detrás de él, o a un agente del equipo rojo que busca defectos en lugar de validar afirmaciones. Esta es la idea detrás del sistema de investigación multiagente de Anthropic, donde subagentes en paralelo exploran diferentes aspectos y un agente líder sintetiza de forma independiente.

Cuando una de estas afirmaciones es claramente verdadera y se puede determinar cuál, añadir agentes justifica su costo.

Cuatro formas de combinar agentes

Supongamos que se toma la decisión. La investigación revela rápidamente un caos, ya que los laboratorios de vanguardia han desarrollado los patrones multiagente de manera diferente, aunque existen algunos elementos comunes. A continuación se presenta una taxonomía sintetizada a partir de la documentación del flujo de trabajo de Anthropic y la experiencia de producción de su equipo de ingeniería. No se trata de una clasificación oficial de Anthropic; es un resumen analítico que se basa en lo que describen esas fuentes.

Pipeline secuencial

Los agentes o etapas se ejecutan en un orden fijo, y las etapas posteriores utilizan los resultados de las anteriores. De las cuatro opciones, esta es la más sencilla de explicar a los ingenieros, ya que se parece al software habitual: investigación seguida de síntesis, redacción seguida de crítica, extracción seguida de validación.

Su fortaleza radica en los contratos explícitos entre las etapas. Su debilidad son los errores en cadena, ya que un error de extracción en la primera etapa puede hacer que las etapas posteriores estén incorrectas, con grandes costos. Las puertas de validación entre las etapas son obligatorias, porque impiden que el proceso avance con confianza en la dirección equivocada. Los esquemas de contrato JSON y otros artefactos que preservan el historial durante la ejecución constituyen las mejores puertas de control.

Orquestador central, o planificador-ejecutor

Un agente principal divide la tarea, la delega a los trabajadores y sintetiza los resultados. Los trabajadores no se coordinan entre sí; informan directamente al orquestador. Es el valor predeterminado más común y útil. Úsalo cuando la estructura de las subtareas no se conoce de antemano, pero es importante tener una responsabilidad clara a nivel superior. La función Research de Anthropic sigue exactamente este modelo: un agente principal analiza la consulta, inicia subtareas especializadas en paralelo y posteriormente combina lo que han encontrado.

No lo uses si el flujo de trabajo ya está lo suficientemente definido como para ser programado; en ese caso, un pipeline será más simple y predecible.

Su fallo característico es la falla del orquestador: un agente principal cuyas instrucciones de delegación son vagas hace que los trabajadores repitan búsquedas unos a otros, omitan límites o generen resultados que no encajan entre sí. La solución es proporcionar a cada trabajador un objetivo, un formato de salida esperado, orientación sobre fuentes y límites claros de la tarea.

Especialistas en paralelo, debate y equipo rojo

Aquí varios agentes se encargan al mismo tiempo de la misma tarea o de subtareas relacionadas, y luego sus resultados se someten a votación, crítica o agregación. Este enfoque es adecuado para casos en los que la resiliencia es más importante que la precisión: explicaciones competitivas sobre un error, revisión adversaria de una decisión política, evaluación de seguridad desde múltiples ángulos.

El costo es evidente. Más agentes significan muchos más tokens, más trabajo de agregación y un riesgo de confianza errónea derivada del consenso. Se dice que el sistema de investigación de Anthropic tuvo que establecer presupuestos de esfuerzo y una delegación más estricta para evitar que los trabajadores actuaran sin disciplina. Utilice este patrón solo cuando el dominio lo exija realmente.

Enjambre, o contexto compartido descentralizado

La coordinación surge del estado compartido, de los hilos de mensajes compartidos o de cambios en el entorno, en lugar de de un líder estricto. Aquí los sistemas multiagente comienzan a convertirse en sistemas distribuidos, con toda la complejidad que eso implica: titularidad poco clara, condiciones de carrera en el estado compartido y depuración difícil. Es adecuado para problemas verdaderamente abiertos en los que los agentes deben interoperar más allá de los límites de sesión o tiempo de ejecución. Evítelo cuando se necesite una rendición de cuentas sencilla o un cumplimiento estricto.

Para la mayoría de los profesionales, los dos primeros patrones abarcan casi todo.

Lo que ofrece Anthropic hoy

Antes de crear su propio conjunto de herramientas, vale la pena verificar qué ya proporciona Anthropic y qué enseñan sus soluciones. Existen varias plataformas para el trabajo con agentes, y no son intercambiables. Imagínese una escalera que va desde el control directo hasta la gestión alojada. La imagen a continuación muestra una situación alrededor de abril de 2026, y estos productos cambian con rapidez.

1. Messages API. Usted controla por completo el proceso. Aunque existen herramientas auxiliares, usted es quien escribe la lógica de ejecución, y no hay soporte integrado para múltiples agentes. Es el nivel más flexible, pero también requiere más trabajo.

Claude Agent SDK. El bucle del agente, las herramientas, el manejo de contexto, los subagentes, los ganchos y el seguimiento de costos provienen de Anthropic, pero se ejecutan en la infraestructura que usted opera. Los subagentes son nativos, y todo lo relacionado con múltiples agentes más allá de ellos es en su mayor parte un diseño propio. La autenticación funciona a través de Bedrock, Vertex AI y Azure Foundry, por lo que este es el nivel más portátil.

Claude Managed Agents. Anthropic se encarga de ejecutar el entorno en su lugar: contenedores, compactación, caché de prompts, historial de eventos, sesiones con estado y un conjunto de herramientas integradas. El uso de un solo agente ya está maduro, mientras que las sesiones con múltiples agentes se encuentran en una versión preliminar separada y restringida.

Agentes gestionados multiagente. Una versión preliminar de investigación con acceso restringido y una limitación importante: el diseño solo admite un nivel de coordinador. Un coordinador puede llamar a otros agentes, pero estos no pueden a su vez llamar a otros agentes. Se trata de orquestación multiagente, aunque aún no constituye una sociedad recursiva general de agentes.

Subagentes de Claude Code. Contextos de trabajo aislados dentro de una sesión principal que informan los resultados. Es una función oficial, pero no permite equipos punto a punto.

Equipos de agentes de Claude Code. Según la versión de abril de 2026, es experimental y está desactivado por defecto; se activa mediante una variable de entorno específica. Las limitaciones conocidas incluyen el comportamiento de reanudación de sesiones, casos límite en la coordinación de tareas y sesiones reanudadas que hacen referencia a compañeros de equipo que ya no existen.

En la práctica, la afirmación “Claude admite equipos de agentes” es cierta, mientras que “Claude ofrece orquestación multiagente de nivel profesional y de uso general en todas las plataformas” no lo es.

Equipes de agentes en Claude Code: aplicación práctica

Un recordatorio rápido de la diferencia:

• Subagentes se ejecutan dentro de una sola sesión principal. La instancia principal de Claude Code los crea; cada uno funciona por separado dentro de su propia ventana de contexto y envía los resultados, siendo usted quien se encarga de la orquestación. La sesión principal nunca asume el trabajo necesario para generar un resultado.

Equipos de agentes son sesiones separadas de Claude Code que se comunican entre sí. Cada miembro del equipo tiene su propia ventana de contexto y estado de sesión, además de una lista de tareas compartida y un buzón para mensajes directos. Los miembros del equipo pueden asignarse tareas entre sí y coordinarse sin tener que esperar a que el líder transmita cada instrucción. El líder establece la dirección, y los demás miembros pueden actuar en consecuencia y conversar entre ellos.

La configuración

1. La configuración del equipo se encuentra en ~/.claude/teams/{name}/config.json.
2. La lista de tareas compartida está en ~/.claude/tasks/{name}/.
3. Los miembros del equipo se definen en archivos de agentes reutilizables, que en esencia son definiciones de subagentes a los que se asignan roles específicos.
4. Los ganchos pueden funcionar como controles de calidad entre las transiciones de tareas.

Dos aspectos arquitectónicos son importantes para el diseño. Primero, los subagentes pueden conservar su propia memoria automática. Eso ayuda con la especialización, pero una vez que el trabajo se divide entre varios agentes con memorias separadas, hay que tomar una decisión arquitectónica sobre qué conocimiento permanece local, cuál se comparte y cuál se resume. Esa es una cuestión de diseño de sistemas.

Segundo, la documentación indica claramente cuándo los equipos rinden peor que los subagentes: tareas secuenciales, ediciones en el mismo archivo y trabajos con muchas dependencias entre pasos. Si los agentes deben transmitir el mismo resultado en orden, sin trabajar en paralelo, los subagentes en un flujo secuencial son más simples y predecibles.

Dado que los equipos aún eran experimentales y estaban desactivados por defecto en ese momento, úselos solo por una razón clara de la lista anterior, y espere imperfecciones.

Cómo se comunican los agentes entre sí

La comunicación entre agentes a menudo se considera un problema de estimulación. A gran escala, se trata de un problema de sistemas. Existen tres formas principales.

1. Mensajes en lenguaje sencillo. Es la forma más obvia, pero también la menos fiable a gran escala. Los compañeros de Claude Code se comunican directamente entre sí a través del buzón de correo. Aunque es flexible, el lenguaje natural es menos preciso que la invocación estructurada, lo que deja más espacio para malentendidos entre los agentes.
2. Invoque estructurado. Definiciones de herramientas mediante JSON Schema y uso estricto de estas. Las definiciones de herramientas de Anthropic garantizan que los argumentos se ajusten al esquema. Este nivel hace que la comunicación entre agentes y herramientas sea fiable, y el mismo mecanismo hace que las llamadas entre agentes sean más precisas cuando se modelan como llamadas a herramientas en lugar de mensajes libres.

Estatuto o artefactos compartidos. La forma más subestimada. El informe de investigación sobre múltiples agentes de Anthropic recomienda que los subagentes escriban sus resultados en un sistema de archivos o en un sistema externo y devuelvan referencias ligeras, en lugar de hacer pasar todo por el contexto del agente principal. La razón es sencilla: un archivo puede ser auditado, versionado e inspeccionado directamente, mientras que un mensaje que resume un archivo puede no ser ninguna de esas cosas.

El momento en que se realiza la acción es tan importante como el formato. Se identifican cuatro patrones:

• Llamadas síncronas. Un gestor llama a un especialista, espera y luego continúa. Es fácil de comprender, pero puede ser un cuello de botella. Según se informa, el equipo de investigación de Anthropic descubrió que la ejecución síncrona liderada se veía obstaculizada por trabajadores lentos y descartó la posibilidad de realizar ajustes durante el proceso.

Transferencias secuenciales. La responsabilidad pasa de un agente al siguiente: uno genera un resultado y el siguiente lo toma. OpenAI establece una distinción clara entre dos enfoques: en las transferencias, el especialista asume la responsabilidad de lo que sucede a continuación, mientras que cuando se utiliza un agente como herramienta, el administrador sigue al mando. Quién es responsable depende de cuál método se emplee.

Basado en eventos o en flujo continuo. Los agentes reaccionan a los eventos en lugar de mediante llamadas síncronas. Son más adecuados para tareas que duran mucho tiempo, pero resultan más difíciles de depurar y probar; a veces los ganchos ayudan en este proceso.

Consultas de estado compartido. No es la opción más atractiva, pero con frecuencia es la más fiable. Los agentes buscan el progreso en un archivo o almacén de datos compartido, registran allí sus actualizaciones y proceden. El trabajo continuo de Anthropic con herramientas de integración mantiene las listas de características en JSON, los archivos de progreso y los commits de Git como estado compartido duradero, y los puntos de control realizados por humanos se integran de forma natural.

La forma en que los agentes se transfieren información entre sí determina la fiabilidad de todo el sistema. Transmitir toda la historia de la conversación maximiza la continuidad, pero aumenta linealmente los costos y la latencia. Un resumen comprimido suele ser mejor, y eso es exactamente lo que hacen los subagentes de Claude Code por diseño. Transferir artefactos específicos para tareas, como archivos de salida estructurados, parches de código, listas de características en JSON e informes almacenados, suele ser el equilibrio práctico. El agente receptor puede inspeccionar directamente el artefacto en lugar de confiar en un resumen, lo que hace que el sistema sea auditable de una manera que las transferencias conversacionales no pueden igualar.

Lo que se transmite también determina cómo y cuándo se transmite, lo cual refuerza el punto central: construir equipos de agentes es un problema de diseño de sistemas, y estos son más difíciles de resolver que un flujo orquestado de forma lineal.

Ocho formas en que fallan los equipos de agentes

La mayoría de los tutoriales sobre múltiples agentes omiten esta parte. Las notas técnicas de Anthropic son una buena fuente. Se asemejan menos a un artículo de investigación que al diario de un equipo que, error tras error, descubrió que la adición de agentes multiplica los problemas de gestión. Se pueden extraer ocho lecciones de ellas.

• Deriva en la coordinación. Una delegación vaga hace que los trabajadores repitan búsquedas ya realizadas, omitan límites o devuelvan resultados que no son coherentes. Un artículo de investigación del sistema de Anthropic lo identificó directamente, y la solución fue enseñar al orquestador a especificar el objetivo, el formato de salida, las directrices de origen y el alcance para cada trabajador. Cuando no se define quién es el responsable, los agentes lo deciden por su cuenta, y de forma deficiente, al igual que lo hacen los humanos.

Propiedad ilusoria. El agente A cree que el agente B verificó algo que en realidad nadie verificó. La solución son los artefactos de finalización explícita: ganchos de tarea, verificación de extremo a extremo antes de marcar cualquier cosa como completada y archivos de estado duraderos que registren lo que realmente se confirmó, no lo que se asumió.

Fallo intermedio silencioso. Para depurar fue necesario realizar un seguimiento completo en producción, ya que nada indicaba si el fallo se debía a consultas de búsqueda inadecuadas, fuentes débiles o un error en las herramientas. El flujo de sesión de nivel superior es solo una vista resumida; para comprender qué hizo realmente el agente llamado es necesario examinar el historial a nivel de trabajador. Implemente el seguimiento desde el principio, mucho antes del primer incidente en producción.

Inflación del contexto y contaminación de la memoria. La ventana de contexto es un recurso finito, y la memoria compartida que se vuelve obsoleta o ruidosa deteriora todo el sistema. Cada llamada a una herramienta, lectura de archivo y análisis parcial se almacenan en el contexto y permanecen allí; esto se agrava cuando hay varios miembros en un equipo. Las medidas de mitigación conocidas son resumir las fases completadas, aislar las tareas complejas en subagentes y preferir archivos de memoria pequeños y específicos en lugar de archivos compartidos grandes.

Desequilibrio en los esquemas y contratos de prompts frágiles. Los agentes que intercambian datos en lenguaje natural son vulnerables. El segundo agente interpreta mal el resumen del primero y el error se propaga silenciosamente. Existe una normativa estricta para el uso de herramientas porque las llamadas no estrictas pueden generar tipos incompatibles o campos faltantes. Contratos más específicos entre agentes y herramientas reducen las posibilidades de que esto ocurra, lo cual representa un papel irónico para los tradicionales contratos de ingeniería en un entorno de IA.

Uso incorrecto de herramientas y fallos de seguridad. Cuantos más entornos abiertos haya, más puntos de entrada existen para la inyección de comandos, y cuanto más herramientas haya, más formas tiene un atacante de actuar una vez dentro del sistema. La investigación de Anthropic sobre agentes fiables denomina a la inyección de comandos un vector de ataque cibernético y no un caso aislado; además, los tests de equipo rojo realizados por METR en el sistema interno de monitoreo de agentes de Anthropic detectaron vulnerabilidades nuevas incluso en un sistema interno bien equipado. Para mitigarlo, se deben utilizar permisos limitados, herramientas adaptadas a las necesidades específicas de la tarea y aprobación humana para las acciones de mayor impacto.

Explosión de costos y acumulación de latencia. Los equipos utilizan muchos más tokens de los necesarios para una sola sesión. El paralelismo puede acortar el tiempo total, pero aumenta el gasto total en tokens en lugar de disminuirlo, ya que la mayor velocidad se logra al invertir más esfuerzo estructurado de una sola vez. A menos que la tarea lo justifique, un agente bien diseñado individualmente resulta más rápido y económico.

Dificultad de evaluación. Diferentes rutas internas pueden llevar al mismo resultado que parece exitoso. Si la única prueba es si el texto final suena creíble, en realidad se está admirando al sistema en lugar de evaluarlo. La recomendación de Anthropic es verificar si se alcanzó el estado final correcto, y no si se siguió el proceso previsto. El proceso varía, pero lo que se puede confirmar es el resultado.

Nativo, DIY o híbrido

Así que la gran pregunta: ¿construir la orquestación uno mismo o utilizar una solución lista para usar? Se trata de un compromiso arquitectónico entre tres opciones, y seguramente hay más; considere esto como una perspectiva subjetiva.

1. Gestionado nativo significa que Anthropic es dueño del entorno de ejecución y de la superficie de coordinación: Claude Managed Agents y, de forma más específica, Managed Agents multiagent o equipos de agentes Claude Code. Las ventajas son una menor carga de trabajo de ingeniería y una infraestructura alojada que no es necesario mantener. Las desventajas son una portabilidad limitada (Managed Agents solo se puede acceder a través de la API directa de Claude), una superficie multiagente que aún está en fase experimental o en versión de previsualización restringida, y la dependencia de un tercero. Elija esta opción cuando el problema principal sea la infraestructura y las restricciones específicas de Anthropic sean tolerables.

DIY significa que usted posee la lógica de orquestación y, por lo general, también el tiempo de ejecución, siendo la API de mensajes el ejemplo más claro. Ofrece el mayor control a un costo de ingeniería muy elevado. Elíjalo si su lógica empresarial es excepcional, las reglas de cumplimiento son estrictas, el enrutamiento es específico para su dominio, o la portabilidad del proveedor es un requisito real.

Híbrido significa que Anthropic proporciona el bucle y las herramientas mientras usted diseña el sistema, y el Claude Agent SDK es el ejemplo más claro. Usted obtiene el bucle de agentes, la gestión de contexto, los ganchos, los subagentes y la capacidad de observabilidad de Anthropic, pero sigue teniendo el control del diseño a nivel superior. La autenticación a través de Bedrock, Vertex AI y Azure Foundry representa una ventaja significativa en términos de portabilidad frente a las soluciones gestionadas nativas. Elija esta opción cuando desee utilizar el bucle de Anthropic sin tener que adaptar toda la arquitectura a su visión actual sobre cómo deberían funcionar los sistemas multiagente.

En resumen: soluciones gestionadas nativas cuando el problema radica en la infraestructura, enfoque DIY cuando los problemas están relacionados con la topología y las políticas, y opción híbrida cuando desea utilizar las primitivas de Anthropic pero necesita espacio para tomar sus propias decisiones arquitectónicas.

La cuestión de la arquitectura

La visión que la mayoría de las personas tiene sobre los equipos de agentes se centra en la capacidad, partiendo de la idea de que más agentes significan mayor capacidad. La visión útil es la arquitectura: ¿qué problema resuelve un agente adicional y cuál es su costo?

Los subagentes deciden quién realiza el trabajo, en qué contexto y con qué herramientas. Los equipos de agentes añaden una capa de coordinación encima, con estado compartido de tareas, compañeros que se comunican directamente entre sí y ejecuciones paralelas que se organizan solas. Tal capa solo resulta útil para problemas que realmente la requieran.

Un equipo de agentes bien configurado para un caso de uso real representa una tarea razonable para una semana de trabajo. La complejidad puede aumentar a partir de ahí, pero no tiene por qué comenzar así. El catálogo de fallos y los patrones de comunicación mencionados sirven como material de referencia, no como un plan para construir todo de una sola vez. Comience identificando cuál de los cuatro desencadenantes es realmente verdadero; si ninguno lo es, la opción con un solo agente sigue siendo la adecuada.