Un cliente de Anthropic comparó su agente de varios subagentes con un único bucle de agente y el segundo terminó las tareas en aproximadamente la mitad de tiempo. Con esa cifra y con lo que ha visto en despliegues empresariales, el equipo de Applied AI de Anthropic publicó el 22 de octubre de 2026 una guía con una recomendación concreta: revisar qué subagentes se pueden convertir en skills y herramientas de un solo agente, y un kit de código abierto para hacerlo midiendo cada paso.
No es un "los subagentes han muerto". Es un aviso a quien ha montado un orquestador con un especialista por equipo y paga esa estructura en latencia, en coste y en contexto perdido entre agentes.
Por qué tantos subagentes acaban dando problemas
El patrón que describe Anthropic es muy reconocible: cada equipo de producto construye su agente y un equipo de plataforma pone un orquestador encima. Sobre el papel es modular; en la práctica aparecen cuatro problemas:
- Contexto perdido en cada traspaso. Hay que decidir qué se pasa de un agente a otro, y en ese ida y vuelta se pierden detalles. Anthropic lo llama directamente un "teléfono roto".
- Proliferación de subagentes. Cada equipo publica el suyo y se acumulan cientos de agentes solapados, sin estándares ni dueño claro. Un cliente tenía una docena de subagentes especialistas en su agente de cara al público y no conseguía un tono de marca coherente.
- El "Frankenprompt". Cada equipo añade su frase al prompt de sistema hasta que las reglas se contradicen.
- Evals locales. Cada equipo optimiza la suya para su subtarea y nadie mide el sistema entero.
Es la ley de Conway aplicada a agentes: la arquitectura acaba copiando el organigrama.
La alternativa: un bucle que carga contexto bajo demanda
La propuesta es un modelo y una ventana de contexto ejecutando un bucle de herramientas abierto. En cada turno el modelo emite un lote de llamadas, el harness las ejecuta en paralelo y devuelve los resultados en bruto al mismo modelo, que decide el siguiente paso: otro lote, una pregunta al usuario o la respuesta. Los límites (presupuesto de turnos y de coste, puertas antes de escribir) viven en el harness, y un verificador puede revisar la respuesta al final.
La clave es la divulgación progresiva. El agente solo ve descripciones cortas de las skills y de las herramientas, y carga el contenido completo cuando lo necesita, mediante skills y tool search. Así desaparece el motivo principal para repartir el trabajo entre subagentes: que no cabía todo en un prompt. Anthropic da un dato propio: redujo más de un 80 % el prompt de sistema de Claude Code para los modelos más avanzados, en parte por cargar skills y herramientas solo cuando hacen falta.
El otro argumento son los modelos. Según la guía, desde Opus 4.5 los modelos gestionan en un solo bucle mucho más de lo que los equipos esperaban, y los actuales narran su progreso y revisan su trabajo, lo que deja sobrando capas del harness. El modelo que escribe el plan es el mismo que lo ejecuta, así que puede cambiarlo a mitad de camino.
| Orquestador con subagentes | Un bucle con skills y tool search | |
|---|---|---|
| Contexto | Uno por subagente; se pasan resúmenes | Uno compartido; nada se pierde entre pasos |
| Plan | Lo fija el orquestador o el código | Lo escribe y lo revisa el propio modelo |
| Conocimiento de cada equipo | En el prompt de cada subagente | En skills que se cargan bajo demanda |
| Latencia | Un bucle anidado por llamada | Un solo bucle; un cliente midió unas 2 veces menos tiempo |
| Propiedad | Cada equipo, su agente | Un equipo central y pequeño posee el prompt y la eval; cada equipo, sus skills |
Hay un límite que marca cómo diseñar las herramientas: según Anthropic, la elección de herramienta empeora a partir de 30 a 50 definiciones en el prompt. Por eso recomienda agruparlas por intención del usuario, no una por endpoint, y cargar el resto con tool search.
Cuándo un subagente sigue mereciendo la pena
La guía da tres casos claros: cuando el bucle único sufre una degradación medible por exceso de contexto, cuando hay tareas que se pueden hacer en paralelo con contextos nuevos que luego se descartan (investigación, verificación independiente) y cuando el agente no acierta al elegir herramienta o el prompt tiene instrucciones en conflicto. Incluso entonces, propone que el agente principal llame al subagente como una herramienta con un esquema de respuesta común, en vez de cederle la conversación.
La regla para dividir también cambia: por contexto, no por tipo de problema. Un subagente debe recibir trabajo que necesite poco del resto y devolver un resultado compacto.
Cómo migrar sin romper lo que funciona
El orden que propone Anthropic es medir primero (bastan 10 ejemplos de referencia para empezar), fusionar los subagentes que siempre se llaman en cadena y después absorber los demás de uno en uno, comparando con la misma eval. El aviso más útil del artículo sale de su propia prueba con un agente de soporte: al absorber un subagente bajó la latencia, pero se rompió un flujo que antes pasaba. El agente principal tenía la herramienta de pedidos y respondía por su cuenta, sin preguntar al especialista de envíos la fecha de entrega. El fallo solo apareció en una de cada dos ejecuciones, así que cada tarea de la eval hay que correrla más de una vez.
Para eso está single-agent-loop-kit, con licencia Apache-2.0. Incluye una skill para Claude Code que audita los subagentes y da un veredicto para cada uno (absorber, fusionar, llamar como herramienta o mantener), scripts para comparar ejecuciones y un agente de soporte de ejemplo con un router y seis subagentes. La comprobación inicial no usa API ni gasta tokens:
git clone https://github.com/anthropics/single-agent-loop-kit
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smokePara usarlo en un sistema propio, se copia la carpeta skill a .claude/skills/single-agent-loop del repo del agente y se le pide a Claude Code que la ejecute. Se detiene después de la auditoría, antes de cada ejecución de pago (con una estimación de tokens) y después de cada cambio.
Lo que no es trasladable
La cifra de 2x es de un cliente concreto y Anthropic no publica la comparativa ni la carga de trabajo. Y el propio kit es honesto sobre su madurez: es una implementación de referencia sin mantenimiento, solo se ha probado sobre el ejemplo, por una persona y con un modelo, y los pasos de fusión y mantenimiento no se han ejecutado con un modelo real. Lo que sí encaja con datos externos es la dirección: un estudio de Vals citado por The Decoder vio que los equipos de agentes pueden ser más rápidos, pero no dan más calidad, y que pasar de 10 a 30 o 100 agentes subía el coste sin mejorar el resultado.
Mi lectura: si tu agente es un organigrama con un orquestador encima, la pregunta ya no es cuántos especialistas añadir, sino cuáles sobreviven a una eval honesta frente a una skill.
Fuentes
- Building agents: When to fold subagents into your main agent loop, Anthropic, 22 de octubre de 2026.
- single-agent-loop-kit, Anthropic en GitHub.
- Anthropic says one AI agent beats many subagents now that models can handle complexity alone, The Decoder, 25 de octubre de 2026.