NUEVA MIRADA · AGENTES
¿Necesitas cinco agentes de IA? Antes, demuestra qué mejora el segundo
Un agente de ventas, otro de soporte y un coordinador. Sobre el papel, todo parece ordenado. Pero antes de añadir agentes conviene demostrar qué mejora separarlos: calidad, tiempo, coste o aislamiento.
Imagen conceptual · No representa una implementación ni resultados experimentalesAgentesCONTEXTOCOORDINACIÓNEVALUACIÓN“Antes de añadir el segundo agente, define qué debería mejorar. Después, mídelo.”
Una arquitectura ordenada no demuestra mejores resultados
Un agente de ventas, otro de soporte, otro de datos y un coordinador que reparte el trabajo. Sobre el papel, todo parece ordenado. La arquitectura se parece a una empresa: cada especialista tiene su función. Pero dibujar responsabilidades no demuestra que el sistema vaya a funcionar mejor.
Antes de añadir agentes, yo plantearía una pregunta: ¿qué problema concreto resuelve separarlos y cómo vamos a comprobarlo?
La conversación ha vuelto a cobrar fuerza después de que Anthropic publicara, el 22 de octubre de 2026, recomendaciones para integrar determinados subagentes en un único agente principal. El artículo describe implantaciones que mejoraron al simplificar su arquitectura y menciona un cliente cuya ejecución fue aproximadamente el doble de rápida.
Es un resultado interesante. También es un caso concreto. No permite concluir que los sistemas multiagente hayan dejado de tener sentido.
Un agente con skills no es un agente que lo sabe todo
Una skill puede reunir instrucciones, procedimientos y recursos para realizar una tarea. El agente carga ese contenido cuando lo necesita, en lugar de recibir todas las instrucciones desde el principio.
Una herramienta cumple otra función: consultar una base de datos, ejecutar un cálculo o realizar una acción mediante una API. Un subagente, en cambio, dispone de su propio contexto y de un proceso de ejecución al que se delega trabajo.
La distinción importa. Si solo necesitamos incorporar un procedimiento especializado, quizá baste con una skill. Si necesitamos una consulta, puede bastar con una herramienta. Si queremos delegar una investigación independiente, un subagente puede aportar valor.
Dónde aparece la complejidad
Imaginemos un asistente que consulta un pedido, comprueba su entrega y prepara una respuesta al cliente. Si dividimos cada paso entre agentes, debemos decidir qué información pasa de uno a otro: identificadores, condiciones, excepciones y resultados anteriores. Un resumen incompleto puede hacer que el siguiente especialista responda correctamente a una pregunta mal planteada.
La pérdida de información no es inevitable, pero hay que diseñar cómo evitarla. Mi propuesta sería definir un contrato de intercambio: qué recibe cada componente, qué debe devolver, qué evidencias aporta y cómo comunica que no puede completar la tarea.
También necesitamos registros que permitan reconstruir la ejecución. Una respuesta final incorrecta puede tener su origen en datos desactualizados, una herramienta fallida o una instrucción ambigua. Cambiar el prompt sin localizar ese origen puede ocultar el problema.
Cuándo empezaría con uno y cuándo probaría varios
Cuando las tareas estén muy relacionadas, compartan información y formen parte de una misma conversación, probaría primero un agente con herramientas bien delimitadas. Por ejemplo: consultar una incidencia, buscar documentación y proponer una respuesta. Separar esas funciones exige demostrar una ventaja frente a mantener el contexto compartido.
Además, un agente puede lanzar varias consultas de herramientas en paralelo. Tener paralelismo no obliga a tener varios agentes.
Hay situaciones en las que separar el trabajo merece una evaluación. La tabla recoge posibilidades, no garantías de mejora.
Escribir «no puedes hacer esto» en un prompt no sustituye un control de acceso. Si un componente solo debe consultar datos, las credenciales y las herramientas deben imponer esa limitación. La seguridad no depende de cuántos agentes dibujemos.
| Situación | Qué puede aportar un subagente | Qué comprobar |
|---|---|---|
| Investigar varios proveedores | Explorar documentación en paralelo | Independencia de tareas y calidad de la síntesis |
| Analizar conjuntos extensos de información | Separar contextos y devolver resultados acotados | Que el resumen conserve las evidencias necesarias |
| Revisar una propuesta | Una comprobación adicional | Que la revisión detecte errores y no los repita |
| Funciones con permisos diferentes | Facilitar el aislamiento | Que la infraestructura imponga los permisos |
Anthropic también ha obtenido buenos resultados con varios agentes
En junio de 2025, Anthropic comunicó una mejora del 90,2 % frente a un agente individual en su evaluación interna de investigación, utilizando una configuración multiagente concreta.
Ese porcentaje no significa que cualquier empresa vaya a mejorar un 90,2 %. Corresponde a una evaluación y unos modelos determinados, con un mayor consumo de recursos. Los dos resultados son compatibles: simplificar puede ayudar en un flujo muy interdependiente; dividir puede ayudar cuando existe trabajo independiente suficiente.
Qué utilizaría para llevarlo a la práctica
Elegir una arquitectura también exige separar funciones. El modelo decide dentro del margen que le damos; el software debe controlar permisos, validar datos y registrar lo ocurrido. Para un prototipo, esta sería mi guía.
Es una selección orientativa, no una obligación de incorporar todas esas piezas. Los patrones y mecanismos están documentados por LangChain; la selección y el ejemplo son una propuesta de análisis.
En una solicitud ficticia de mantenimiento, empezaría con un agente que consulta documentación y prepara una propuesta. Añadiría un especialista únicamente si una prueba muestra que separar una parte mejora el resultado.
La autorización para intervenir sobre un equipo quedaría controlada fuera del modelo. Un agente que recomienda una actuación y otro que puede ejecutarla tienen responsabilidades diferentes.
| Necesidad | Pieza técnica | Qué comprobar |
|---|---|---|
| Incorporar un procedimiento | Skill con instrucciones y ejemplos | Carga adecuada y ausencia de instrucciones contradictorias |
| Consultar datos o ejecutar una operación | Función o API expuesta como herramienta | Entradas válidas, permisos y errores |
| Definir pasos y rutas explícitas | LangGraph | Estado recibido y condiciones para avanzar |
| Delegar trabajo independiente | Patrón de subagentes de LangChain | Límites de la tarea y formato del resultado |
| Conservar una ejecución interrumpida | Checkpointer persistente | Recuperación tras reinicio y ejecución correcta |
| Comparar arquitecturas | Evaluación y registro de ejecuciones | Calidad, coste, tiempo y fallos en las mismas tareas |
La comparación que haría antes de decidir
Prepararía un conjunto representativo de tareas y compararía las dos alternativas. Incluiría casos habituales, información incompleta y errores de herramientas.
Repetiría las pruebas: una ejecución acertada no acredita fiabilidad. También documentaría modelos, herramientas y presupuestos utilizados. Si una alternativa dispone de muchos más recursos, necesitamos saber cuánto de la mejora procede de esa diferencia.
Para mí, una buena arquitectura permite explicar por qué existe cada componente y qué evidencia justifica conservarlo. Antes de añadir el segundo agente, define qué debería mejorar. Después, mídelo.
Qué medir antes de elegir una arquitectura
- 01Tareas completadas correctamente.
- 02Coste por tarea resuelta.
- 03Tiempo de respuesta, también en los casos lentos.
- 04Intervenciones humanas necesarias.
- 05Incumplimientos de permisos o reglas.
- 06Esfuerzo para localizar y corregir un fallo.
¿Qué te ha dado más resultado en tus proyectos: simplificar el flujo o separar responsabilidades? Soy Noelia Gorod. En este blog comparto análisis sobre IA aplicada, agentes y transformación empresarial. Sigue la conversación en mis redes. Los ejemplos y criterios de decisión son propuestas de análisis: no describen implementaciones ni resultados internos de ninguna empresa.