La promesa suena irresistible: un solo agente de IA que investiga, redacta, analiza métricas y además coordina tareas como si fuera un jefe de gabinete digital. El problema es que, cuando le pides todo al mismo sistema, también le cargas ruido, contexto sobrante y demasiadas decisiones a la vez. Ahí es donde los subagentes empiezan a tener sentido.
La discusión se está ordenando recién ahora. Microsoft publicó en diciembre de 2025 una guía concreta para decidir entre arquitecturas de un solo agente y sistemas multiagente, y Anthropic viene contando por qué su sistema de Research funciona mejor cuando un agente líder reparte trabajo en paralelo. La idea central no es “más agentes = mejor”, sino algo mucho más útil: usar varios agentes especializados solo cuando hay una razón clara para separarlos.
¿Qué es exactamente un subagente de IA?
Un subagente es una instancia separada de un modelo que trabaja con su propio contexto, sus propias instrucciones y, a veces, sus propias herramientas. En vez de tener un asistente generalista intentando hacerlo todo, montas una estructura donde un agente principal coordina y delega subtareas a especialistas.
En la práctica, eso puede verse así: un agente investiga fuentes, otro transforma hallazgos en texto y otro revisa métricas o valida datos. Si sigues de cerca el boom de los agentes en empresas, esta lógica conversa bastante con lo que comentamos en este episodio de Es La Hora de Aprender sobre por qué las empresas terminarán operando con más agentes que empleados.
Cuándo tres especialistas sí superan a un solo agente
Anthropic lo plantea de forma bastante simple: los sistemas multiagente empiezan a ganar cuando hay tres problemas que un solo agente resuelve mal.
- Contaminación de contexto: cuando una tarea mete miles de tokens irrelevantes y empeora la calidad de la siguiente.
- Trabajo paralelizable: cuando varias líneas de investigación pueden correr al mismo tiempo sin depender una de otra.
- Especialización real: cuando distintas subtareas requieren herramientas, criterios o tonos muy distintos.
Microsoft coincide en parte, pero le pone un freno importante al entusiasmo. Su recomendación oficial es empezar por un agente único salvo que tengas fronteras claras de seguridad y compliance, equipos distintos manteniendo dominios separados o una hoja de ruta donde el sistema va a crecer rápido en funciones y complejidad. Dicho de otro modo: multiagente no es el punto de partida por defecto, sino una respuesta a límites concretos.
Esa advertencia importa porque en 2026 ya hay demasiada venta de humo alrededor de “enjambres” de agentes. De hecho, Anthropic reconoce que muchas empresas invierten meses en arquitecturas complejas para descubrir después que un solo agente, mejor diseñado, resolvía casi lo mismo con menos costo.
La mejora existe, pero no sale gratis
El dato más llamativo viene del propio sistema de Research de Anthropic. Según la compañía, una arquitectura con Claude Opus 4 como agente líder y subagentes Claude Sonnet 4 mejoró un 90,2% frente a un Claude Opus 4 trabajando solo en sus evaluaciones internas de investigación. La mejora apareció, sobre todo, en preguntas de amplitud: tareas donde conviene abrir varias pistas en paralelo y luego sintetizar.
Ahora bien, el costo también sube rápido. Anthropic dice que los sistemas multiagente consumen en promedio unas 15 veces más tokens que un chat normal, y en su blog sobre cuándo usar varios agentes estima que, para tareas equivalentes, la sobrecarga típica frente a un agente único está en el rango de 3 a 10 veces más tokens. Microsoft añade otra capa del problema: cada traspaso entre agentes introduce más latencia, más manejo de estado y más puntos de falla.
Por eso el criterio correcto no es “si funciona mejor, úsalo”, sino si la mejora justifica el costo operativo. En investigación compleja, soporte con herramientas muy distintas o pipelines con validaciones separadas, puede tener todo el sentido. En tareas lineales y acotadas, probablemente no.
Los tres perfiles que hoy tienen más sentido
Si aterrizas esta arquitectura a una operación real, hay tres perfiles de subagente que aparecen una y otra vez.
- Investigación y síntesis: ideal para buscar fuentes, revisar documentos y devolver solo lo esencial al agente principal.
- Producción de contenido: útil para convertir material bruto en emails, briefs, propuestas o artículos sin mezclar ese contexto con otras tareas.
- Análisis y control: pensado para leer métricas, revisar resultados o detectar fallos semánticos y de ejecución.
Ese último punto ya está generando una mini industria propia. Herramientas como Sentrial, que monitorea agentes de IA en producción, existen precisamente porque un sistema con varios agentes no solo necesita ejecutar: también necesita observabilidad, trazabilidad y límites claros para no desordenarse a medida que escala.
El error más común: confundir arquitectura con madurez
Hay una razón por la que este tema entusiasma tanto a founders y equipos de producto: suena a estructura empresarial aplicada al software. Un líder, varios especialistas, trabajo en paralelo, resultados consolidados. Pero eso no significa que cualquier equipo esté listo para operarlo.
Microsoft lo resume sin adornos: si no tienes una necesidad explícita de separación, prototipa primero con un agente único. Anthropic va por una línea parecida: han visto equipos montar agentes separados para planificar, ejecutar y revisar, solo para terminar con pérdidas de contexto en cada handoff y más gasto en coordinación que en trabajo real.
La tentación es pensar que el multiagente es una señal de sofisticación. En realidad, muchas veces es solo una señal de complejidad prematura. Un sistema de tres especialistas mal definidos puede rendir peor que un solo agente bien promptado, con buenas herramientas y una política clara de memoria y permisos.
Por qué importa
El valor de esta conversación no está en vender la fantasía del “equipo autónomo” de IA, sino en ponerle criterio a una moda que viene creciendo muy rápido. Los subagentes sí pueden mejorar resultados, sobre todo cuando necesitas paralelizar investigación, proteger contexto o separar herramientas y responsabilidades. Pero también pueden disparar costos, latencia y fragilidad si se usan como arquitectura por defecto.
Para equipos pequeños y startups, la lectura correcta es bastante práctica: empieza simple, mide dónde un solo agente se queda corto y recién ahí especializa. Si tu cuello de botella es real, los subagentes pueden darte una mejora visible. Si no, probablemente solo estés pagando más por una idea que todavía no necesitabas.
