Anthropic aconseja deshacerse de la mitad de los subagentes: un solo bucle resultó el doble de rápido

Anthropic ha publicado un artículo sobre cuándo conviene devolver los subagentes al bucle principal del agente. Los autores son el equipo de Applied AI, que ve los despliegues corporativos desde dentro. La conclusión es provocadora: un único agente con skills suele superar en calidad tanto a la variante de «un prompt para todo» como a una arquitectura con un montón de subagentes. Además, sale más barato y más rápido. En uno de los clientes, el bucle único funcionó aproximadamente 2 veces más rápido que el montaje multiagente. En otro, una docena de subagentes especialistas en el agente de cara al cliente rompía el tono de marca unificado y añadía latencia.

Por qué los subagentes copian el organigrama

La observación principal suena casi a ley de Conway: la arquitectura del agente repite la estructura de la empresa. Cada equipo construye su propio subagente y, por encima, el equipo de plataforma coloca un orquestador. Después se acumula un conjunto de males previsibles:

• el contexto se pierde al pasar de un agente a otro;
• aparecen cientos de subagentes que se solapan, sin estándares ni responsable;
• el prompt de sistema se convierte en un «prompt Frankenstein» al que cada equipo ha añadido una frase;
• los evals locales de cada equipo pasan a ser la base de las decisiones de la dirección, aunque no reflejan la calidad del sistema;
• aumentan las latencias, porque cada salto entre agentes es una llamada independiente al modelo.

Desde el punto de vista de la economía de tokens, el panorama es sencillo. Cada traspaso de control implica reexplicar el contexto, duplicar instrucciones y una ronda extra de inferencia. Todo ello se paga dos veces: en dinero y en tiempo de respuesta.

Un solo bucle en lugar de una orquesta

El esquema recomendado parece modesto. Un bucle, una ventana de contexto, límites estrictos en el número de turnos y en el presupuesto. A partir de ahí, cuatro prácticas de ingeniería:

• Revelación progresiva. El modelo ve solo descripciones breves de skills y herramientas, y carga los textos completos cuando los necesita. Así redujo Anthropic el prompt de sistema de Claude Code en más de un 80%.
• Agrupar las herramientas por intenciones del usuario, no por API. A partir de 30–50 descripciones de herramientas, la selección empieza a degradarse. Por eso, tres decenas de envoltorios finos sobre métodos REST funcionan peor que una decena de herramientas que se corresponden con tareas reales.
• Comprobación de permisos dentro de las herramientas. Si no hay acceso, la herramienta devuelve al modelo una denegación comprensible. Así, un único bucle atiende a usuarios con distintos niveles de acceso y no hacen falta agentes separados para cada rol.
• Propiedad central de la calidad. Un único equipo pequeño se encarga por completo del prompt de sistema y de la calidad final. El resto de los equipos son responsables de skills y herramientas, no de agentes.

Los subagentes, con todo, no quedan prohibidos. Anthropic señala tres casos en los que están justificados:

• existe una degradación medible por un contexto inflado;
• se necesitan tareas paralelas con contexto limpio;
• el agente se confunde con las herramientas y las instrucciones contradictorias.

Hay una sola condición: los subagentes deben dividirse por contexto, no por tipo de tarea. La división por tipo de tarea produce un «teléfono descompuesto», en el que cada eslabón distorsiona un poco la petición original.

Migración: de los ejemplos a los skills

El artículo describe el procedimiento con bastante concreción:

• Primero, reunir ejemplos. Bastan incluso 10; serán el conjunto de comparación del antes y el después.
• Fusionar los subagentes más utilizados y más acoplados entre sí.
• Invocar a los restantes como herramientas, no como agentes independientes.
• Convertirlos en skills uno por uno y, tras cada paso, comparar el resultado con los ejemplos de referencia.

Para ello, Anthropic ha publicado en GitHub un migration kit con un skill que ayuda a recorrer el proceso.

Si en producción tiene un orquestador con una decena de especialistas, empiece por medir: tiempo de respuesta, número de llamadas al modelo y coste por consulta típica, y compare después con un bucle único sobre esos mismos 10 ejemplos. Compruebe además si las descripciones de las herramientas están inflados: si hay más de 30–50, agruparlas por intenciones aportará una mejora incluso antes de cualquier reestructuración de la arquitectura. La conclusión organizativa es tan dura como la técnica: los equipos dejan de ser propietarios de agentes y pasan a ser propietarios de skills y herramientas.

La historia, además, resulta reveladora para toda la industria. El año pasado los orquestadores y los sistemas multiagente eran la tendencia principal, y ahora se reconstruyen como si fueran legacy. El autor del resumen en Telegram señala que OpenAI llegó a conclusiones similares en una publicación sobre sus Forward Deployed Engineers.