¿Necesitas tantos subagentes? Cuándo integrarlos en tu agente principal

Cuando uno arma un agente, es tentador darle un subagente a cada tipo de problema: uno que clasifica la intención, otro que planea, uno por cada área del negocio y un orquestador encima. Anthropic publicó el 22 de octubre de 2026 el artículo “Building agents: When to fold subagents into your main agent loop” (Diane Sarkis, categoría Best practices), donde explica que muchas veces esa estructura ya no hace falta.

Este artículo es un resumen en español de esa publicación, con mis comentarios marcados como tales. Habla de agentes construidos en Claude Platform, no de Claude Code. Si lo que buscas es crear subagentes dentro de Claude Code, empieza por esta guía práctica de subagentes.

La tesis de Anthropic

Según el artículo, el equipo de Applied AI de Anthropic encontró un patrón en despliegues empresariales: los agentes mejoraron al integrar en el bucle principal los enrutadores, planificadores y subagentes de dominio. En sus comparaciones entre varios despliegues, un solo agente con skills superó con frecuencia tanto al diseño de “un prompt para todo” como al diseño con subagentes, y a menudo con menor costo y latencia por tarea.

Lo dicen ellos, y conviene tomarlo como lo que es: observaciones de Anthropic sobre sus casos. El artículo cita, por ejemplo, a un cliente que midió un tiempo de ejecución de aproximadamente el doble de rápido con un solo bucle frente a su arquitectura multiagente, pero no es una cifra que se pueda generalizar a tu caso. Por eso la recomendación de fondo es medir.

Cuándo sí usar subagentes

El artículo aclara que los subagentes siguen teniendo su lugar, incluso en investigación. Los recomienda cuando:

1. Un solo bucle sufre una degradación medible por exceso de contexto.
2. Hay varias tareas que se pueden hacer en paralelo, cada una con una ventana de contexto limpia que se descarta al terminar.
3. Un solo agente tiene problemas para elegir la herramienta correcta, o el system prompt tiene instrucciones que se contradicen.

Lo que desaconsejan es dar a cada equipo o tipo de problema su propio subagente, de modo que la arquitectura del agente termine copiando el organigrama de la empresa (la ley de Conway).

Los problemas de dividir por equipo

El artículo enumera varios fallos típicos cuando cada equipo construye su agente y una plataforma central pone un orquestador encima:

• Manejo de contexto: hay que decidir qué se intercambia entre agentes, y en el ida y vuelta se pierden detalles.
• Proliferación de subagentes: cada equipo publica el suyo, sin estándares ni dueño claro.
• El “Frankenprompt”: cada equipo agrega una frase al prompt y acaban con reglas en conflicto y sin una voz consistente.
• Evals demasiado locales: cada quien optimiza su subtarea y nadie es dueño del conjunto.
• Latencia: más capas de agentes, más tiempo de respuesta.

La alternativa: un bucle con divulgación progresiva

La propuesta es un solo agente que ve descripciones cortas de skills y herramientas y carga el detalle completo solo cuando lo necesita. El artículo da tres razones:

1. El contexto compartido da mejores respuestas. Un agente que vio el resultado de cada paso puede conectarlos, algo que se pierde cuando recibe resúmenes de subagentes.
2. La divulgación progresiva evita el exceso de contexto, que era la razón principal para dividir el trabajo. Anthropic dice que redujo en más de 80% el system prompt de Claude Code para modelos más avanzados, con recortes relacionados con cargar skills y herramientas bajo demanda.
3. Los modelos son más capaces. Según el artículo, desde Opus 4.5 los modelos manejan mucho más en un solo bucle de lo que la mayoría esperaba, y una estructura multiagente rígida a menudo impedía que un modelo nuevo hiciera más trabajo por sí mismo.

Cómo se carga cada cosa

• Skills: según la guía de skills de Anthropic, en tiempo de ejecución solo se muestran el nombre y la descripción del frontmatter. Si el modelo decide que el skill hace falta, lee el SKILL.md completo, y los archivos de la carpeta references/ se cargan solo si se necesitan. Esa guía estima unos ~50 tokens para los metadatos, ~500 para un SKILL.md y más de 2,000 para archivos de referencia. Si no conoces los skills, mira cómo crear uno en Claude Code.
• Herramientas: con la herramienta de búsqueda (tool search) de la API, marcas con defer_loading: true las herramientas que no deben cargarse de entrada. Al menos una herramienta, normalmente la propia herramienta de búsqueda, debe quedar sin diferir. Claude busca y la API devuelve las coincidencias (hasta 5 por defecto) como bloques tool_reference, que expande a definiciones completas.

Cómo migrar por etapas

El artículo propone ir de un sistema multiagente a un solo bucle poco a poco:

1. Crea evals de tarea completa. Un conjunto compartido de extremo a extremo que mantiene un equipo central, más conjuntos pequeños que cada equipo entrega con sus skills. Dicen que incluso 10 ejemplos de referencia bastan para empezar. Mientras exista el orquestador, mide también si eligió el subagente correcto; después de integrar, mide si cargó el skill o llamó la herramienta correcta.
2. Combina especialistas que encadenan su salida, tocan los mismos datos o se llaman casi siempre juntos, empezando por los de más uso.
3. Llama a los subagentes como herramientas si decides conservarlos, para que el agente principal siga conversando con el usuario. Recomiendan el traspaso total de la conversación solo cuando el subagente necesita hablar directamente con el usuario. Es un buen primer paso porque no obliga a reescribir los subagentes y te da una línea base.
4. Integra uno por uno: convierte los prompts de cada subagente en skills y sus llamadas a API en herramientas MCP. Compara el eval con y sin el subagente y quédate con el subagente solo si la versión integrada puntúa peor.

Un detalle que me parece valioso del artículo: no basta con mirar la puntuación final, hay que ver qué tareas cambiaron. En un agente de soporte de muestra, integrar un subagente en otro bajó la latencia, pero rompió un proceso que antes pasaba: el agente principal tenía la herramienta de consulta de pedidos y respondía solo, sin preguntarle la fecha de entrega al especialista de envíos. Esa falla apareció en una de dos ejecuciones, así que recomiendan correr cada tarea más de una vez y tener una tarea por cada cadena de agentes que corre junta en producción y por cada regla que el agente no debe romper.

Herramientas, skills y conocimiento

• Herramientas MCP para actuar, leer datos en vivo o devolver resultados con formato fijo. Recomiendan agruparlas por intención del usuario (no una por endpoint) porque, según el artículo, pasando de 30-50 definiciones en el prompt la elección de herramienta tiende a empeorar. Los permisos por usuario se pueden validar dentro de cada herramienta, que devuelve un rechazo legible para el modelo.
• Skills para el “cómo trabaja el equipo”: pasos, reglas y criterios que antes vivían en el prompt del subagente. Cada equipo es dueño de sus skills, con un responsable por equipo.
• Bases de conocimiento para material de referencia que solo se necesita a veces, detrás de una herramienta de búsqueda o como archivos de referencia dentro de un skill, en lugar de que el código recupere y pegue contexto en los prompts.

Y un equipo central pequeño se queda con el system prompt y la calidad de extremo a extremo, revisando cada skill, herramienta y eval antes de que salga.

Herramientas para hacerlo

El artículo enlaza un kit de migración en GitHub: anthropics/single-agent-loop-kit. Según su README, es una implementación de referencia, no está mantenido y no acepta contribuciones, así que úsalo como punto de partida y no como dependencia.

Lo que hace, según el README:

1. Audita cada subagente y le da un veredicto: integrar (fold), combinar (merge), llamarlo como herramienta o conservarlo.
2. Calcula una línea base con tus evals, o te ayuda a crear una si no tienes.
3. Aplica un cambio a la vez, con su propia corrida de eval y comparación, y tú decides si se queda.

Para usarlo en tu repositorio, el README indica copiar la carpeta skill a .claude/skills/single-agent-loop y pedirle a Claude Code: Run the single-agent-loop skill. Incluye además un ejemplo (examples/support-desk) con una verificación gratuita que no necesita API key.

También menciona los subcomandos de /claude-api, que la documentación de comandos de Claude Code lista como prompt-audit, cost-optimize, build-eval e hillclimb. Y /skill-doctor, que muestra cuánto contexto cuesta cada skill y con qué frecuencia se usa; según esa documentación requiere Claude Code v2.1.252 o posterior.

Mi lectura

Esto es opinión mía, no del artículo.

Me quedo con el método más que con la arquitectura: mide, cambia una cosa a la vez y conserva lo que resiste la prueba. Antes de crear el siguiente subagente, me preguntaría si es un skill con herramientas, y haría esa pregunta con un eval pequeño en la mano. Si el subagente existe porque “ese equipo lo pidió”, es buena señal de que conviene revisarlo.

Este tema cambia rápido con cada modelo nuevo, así que verifica la guía actual de Anthropic antes de rediseñar un sistema en producción.

Fuentes

• Building agents: When to fold subagents into your main agent loop (Anthropic, 22 de octubre de 2026)
• single-agent-loop-kit (GitHub)
• Building agents with skills: equipping agents for specialized work
• Building multi-agent systems: when and how to use them
• Tool search tool (documentación de Claude Platform)
• Comandos de Claude Code