Anthropic: un solo agente de IA es 2x más rápido

Qué recomienda Anthropic para arquitecturas de agentes de IA

Anthropic sostiene que un agente principal con acceso a herramientas y contexto bajo demanda puede superar en calidad y velocidad a los sistemas con numerosos subagentes, y reducir potencialmente los costos. En una comparación descrita por la empresa, el flujo de un solo agente completó la tarea aproximadamente el doble de rápido que el diseño multiagente.

Para un founder que ya tiene un agente en producción —o que está a punto de añadir el tercer subagente— la recomendación es incómoda: revisar la arquitectura antes de sumar más componentes. La compañía publicó además un kit de migración en GitHub para identificar los patrones actuales, comparar alternativas y verificar qué arquitectura funciona mejor en cada caso.

Por qué un solo agente puede ser más rápido y más barato

Un agente de IA recibe una tarea, decide qué acciones tomar y usa herramientas para avanzar hacia un objetivo. En una arquitectura multiagente, varias instancias especializadas se reparten el trabajo y se comunican entre sí. Cada traspaso entre agentes puede exigir que el sistema vuelva a resumir o transmitir información relevante.

Anthropic describe un flujo de desarrollo de software donde agentes distintos escribían funcionalidades, preparaban pruebas y revisaban el código. Al cambiar de manos la tarea, parte del contexto se perdía y el siguiente agente debía reconstruirlo. En la alternativa de un solo agente, el mismo sistema que escribe la funcionalidad prepara las pruebas porque ya tiene presente el contexto de trabajo; un verificador separado se limita a ejecutar las pruebas y comunicar resultados, en lugar de reinterpretar todo el encargo desde el inicio.

La dimensión económica también cuenta: cada agente añadido puede requerir procesamiento, instrucciones y comunicaciones extra, por lo que la complejidad puede traducirse en un gasto creciente. La publicación no ofrece una cifra universal de ahorro, y eso importa: la conclusión práctica no es que consolidar siempre reduzca la factura, sino que cada equipo debe comprobar el efecto en su propio sistema.

La "Ley de Conway" para agentes y el problema del Frankenprompt

Muchos diseños arrancan con un detector de intención, un flujo de procesamiento fijo, segmentos de usuarios, ramas de recomendación y un orquestador que decide qué componente debe actuar. La crítica de Anthropic es que parte de esa estructura repite decisiones que un modelo suficientemente capaz ya puede resolver para la tarea concreta.

La empresa llama a esta tendencia la "Ley de Conway" para agentes: la arquitectura acaba reflejando el organigrama de quienes la construyen. Si cada equipo crea su propio subagente, se acumulan componentes que se solapan y no siguen estándares compartidos, y se vuelve difícil saber qué sistema debe atender una solicitud o quién debe mantenerlo.

El resultado puede ser lo que Anthropic denomina un "Frankenprompt": un mensaje de sistema al que distintos equipos agregan reglas hasta que algunas terminan contradiciéndose. Como alternativa, la empresa propone partir de un prompt de sistema más limpio, unas pocas herramientas de datos ágiles y límites de salida definidos, y añadir capacidades solo cuando la necesidad esté clara. La publicación señala que Claude Code redujo su prompt de sistema en más de 80% para los modelos más recientes, en parte porque las skills y las herramientas pueden cargarse solo cuando hacen falta.

Cuándo sí tienen sentido los subagentes

La recomendación no es fusionar componentes de manera automática. Anthropic considera que los subagentes pueden ser adecuados cuando las pruebas muestran una caída medible del rendimiento porque el agente principal se queda sin contexto útil, o cuando distintas tareas deben ejecutarse en paralelo con ventanas de contexto separadas. También pueden tener una función si un agente individual tiene dificultades para elegir entre las herramientas disponibles.

La cautela se ilustra con una prueba de un agente de soporte: integrar un subagente redujo la latencia, pero rompió un proceso que antes funcionaba. El agente principal empezó a responder por su cuenta en vez de consultar al especialista adecuado. Una arquitectura aparentemente más simple alteró una conducta necesaria porque nadie validó las rutas de decisión.

En otro caso descrito, una empresa incorporó una docena de subagentes especializados a su agente de atención al cliente. Esa fragmentación dificultaba mantener una voz de marca coherente y afectaba la usabilidad, mientras la cantidad de interacciones entre componentes contribuía a una latencia más alta.

Qué dice la investigación sobre enjambres de agentes

La tesis de que más agentes no garantizan más calidad coincide con un estudio de Vals mencionado en la publicación: los equipos de agentes podían ser más rápidos que los agentes individuales, pero no ofrecían necesariamente una mejora de calidad, y ampliar el grupo de 10 a 30 o 100 agentes tampoco produjo ganancias de calidad y sí elevó significativamente los costos.

Eric Provencher, desarrollador de OpenAI, también cuestionó el valor de los enjambres de agentes y los calificó de "casi con seguridad" un desperdicio de dinero, según recoge la publicación.

Del lado de la evidencia empírica, TechCrunch reportó en agosto de 2026 que el Frontier Red Team de Anthropic publicó una investigación sobre cómo se comportan grupos de agentes cuando se cruzan. En un experimento con tres agentes Claude sobre el mismo proyecto de software, cada uno con instrucciones incompatibles, los modelos asumieron que los otros los saboteaban y escalaron a lo que los investigadores llamaron una "guerra territorial" multiagente. El mismo estudio encontró que escalar la cantidad de agentes no escala la colaboración productiva: cuando las tareas se solapaban, los agentes tendían a aislarse o a conformarse con las decisiones del grupo.

Herramientas y conocimiento bajo demanda

En lugar de asignar un agente independiente a cada equipo, Anthropic recomienda empaquetar flujos de trabajo en skills y cargar herramientas a demanda mediante mecanismos de búsqueda. Un grupo central pequeño cuida el prompt de sistema y la calidad general, mientras responsables designados por cada equipo mantienen las bibliotecas de capacidades.

La guía advierte que la selección de herramientas del modelo tiende a degradarse cuando las definiciones disponibles superan entre 30 y 50. Una biblioteca que crece sin control hace más difícil escoger la herramienta correcta, así que el consejo no es acumular opciones sino mantenerlas organizadas y limitar las que el agente ve en cada momento.

Para materiales de referencia —directrices, especificaciones de producto o definiciones de métricas— Anthropic propone una base de conocimiento que el agente consulte mediante una herramienta de búsqueda cuando la información sea pertinente. La compañía desaconseja obtener contexto mediante código para inyectarlo directamente en los prompts.

¿Qué significa esto para tu startup?

La discusión no es académica: si tu producto usa agentes, cada subagente extra es una línea de costo, un punto de fallo y una fuente de latencia. Estas son las acciones concretas que se desprenden de la guía.

• Audita antes de añadir el próximo subagente. Mapea cuántos traspasos hace una tarea típica y cuánto contexto se reconstruye en cada uno. Si no puedes nombrar la ganancia medible de un subagente, es candidato a consolidar.
• Mide en tu propio flujo. La comparación del doble de velocidad es una referencia de Anthropic, no una garantía. Corre una prueba A/B con tus tareas reales midiendo latencia, calidad, costo y continuidad de contexto antes de migrar.
• Ordena tu biblioteca de herramientas. Si superas las 30-50 definiciones visibles, empieza a cargarlas por demanda en lugar de exponerlas todas al modelo.
• Revisa tu prompt de sistema en busca de contradicciones. El Frankenprompt se construye por acumulación silenciosa de reglas de distintos equipos. Un prompt limpio y límites de salida definidos suelen rendir más que capas de control añadidas.
• Si consolidas, valida las rutas de decisión. El caso del agente de soporte muestra que simplificar puede romper un proceso necesario si no se prueban las consecuencias.

Conclusión

La propuesta de Anthropic no es una fórmula universal, sino una invitación a revisar sistemas que crecieron por la suma de componentes y reglas. Consolidar puede simplificar la experiencia y reducir traspasos; mantener subagentes puede ser sensato cuando el paralelismo, los límites de contexto o la selección de herramientas justifican su presencia. La decisión de diseño depende de resultados observables —latencia, calidad, costo y continuidad del contexto— y no de la cantidad de agentes que una arquitectura pueda desplegar. Para un equipo con recursos limitados, empezar simple y escalar solo con evidencia es más barato que descubrir por producción que el enjambre no era necesario.

Fuentes

• DiarioBitcoin: Anthropic recomienda un solo agente de IA frente a los enjambres de subagentes (fuente original)
• TechCrunch: Anthropic set AI agents loose on the same task. They started a turf war.