Los agentes de IA generan un entusiasmo desproporcionado respecto a su madurez actual. No porque sean inútiles —hay casos donde producen valor real y significativo— sino porque la brecha entre lo que pueden hacer en condiciones ideales y lo que hacen en entornos reales con toda su complejidad y variabilidad es todavía grande.
Este capítulo es pragmático: cuándo tiene sentido usar agentes, cuándo no, y cómo diseñarlos para que fallen de forma manejable en lugar de catastrófica.
La promesa y la realidad
La promesa de los agentes: “dile a la IA qué resultado quieres y encárgate de otra cosa. Cuando vuelvas, estará hecho.”
La realidad en 2025-2026: los agentes funcionan bien en tareas estructuradas con herramientas fiables y objetivos claros. Fallan con más frecuencia de lo aceptable en tareas abiertas, entornos variables o con herramientas que producen outputs inesperados.
Un estudio de evaluación de agentes (SWE-bench) sobre tareas de resolución de bugs en código real muestra que los mejores agentes resuelven el 40-50% de las tareas. Para el resto —la mayoría— el agente fracasa, se queda atascado o produce resultados incorrectos. En un entorno de producción, el 50% de éxito puede ser suficiente si el 50% de fracaso es detectable y manejable. Puede ser catastrófico si no lo es.
Cuándo los agentes funcionan bien
Tareas repetitivas con estructura predecible. El agente de atención al cliente que clasifica tickets, extrae información y los enruta según criterios definidos funciona bien porque el proceso es siempre el mismo y los errores son detectables rápidamente.
Pipelines de procesamiento de datos. Descargar datos de una API, limpiarlos, transformarlos, cargarlos en una base de datos, generar un informe. Cada paso es determinista, los errores son claros y el proceso puede reiniciarse desde el punto de fallo.
Investigación web automatizada. Buscar en múltiples fuentes, comparar información, sintetizar. La imprecisión ocasional es aceptable porque el humano puede revisar el output antes de usarlo.
Asistencia en desarrollo de software. Los agentes de código (Cursor, Devin, SWE-agent) funcionan relativamente bien para tareas bien definidas: “añade tests unitarios a esta función”, “corrige este bug”, “refactoriza este módulo para cumplir este estándar”. Son menos fiables para tareas de diseño de arquitectura.
Monitorización y alertas. El agente que revisa periódicamente una fuente de datos, detecta condiciones especificadas y envía una alerta funciona bien porque la tarea es simple y repetible.
Cuándo los agentes fallan
Objetivos ambiguos o mal definidos. “Mejora nuestro proceso de ventas” es un objetivo que un agente no puede abordar de forma útil. No tiene suficiente contexto sobre qué está fallando, qué recursos están disponibles o qué restricciones existen. Comenzará a hacer algo, pero probablemente no lo correcto.
Entornos con muchas dependencias externas. Si el agente depende de diez APIs distintas y cualquiera puede fallar o cambiar su comportamiento, la confiabilidad del sistema completo es el producto de las confiabilidades individuales —y colapsa rápidamente.
Tareas que requieren juicio contextual profundo. Negociar con un proveedor, decidir si contratar a un candidato, gestionar una crisis de comunicación. Estas tareas requieren comprensión del contexto organizacional, las relaciones existentes y los matices humanos que el agente no tiene.
Cuando el coste del error es alto. Un agente que puede eliminar archivos, enviar emails o ejecutar transacciones financieras tiene un perfil de riesgo muy diferente a uno que solo lee y analiza. Los errores son irreversibles.
Tareas largas con muchos pasos. Cuantos más pasos tiene una tarea, mayor es la probabilidad acumulada de que algún paso falle o produzca un resultado inesperado que descarrile el resto.
Diseño para la supervisión
El diseño más fiable de agentes no es el que falla menos: es el que falla de forma manejable. Eso implica construir supervisión y puntos de control desde el principio.
Principio de mínimo privilegio. El agente solo debe tener acceso a las herramientas que necesita para completar la tarea. No le des acceso de escritura si solo necesita leer. No le des acceso a producción si puede hacer su trabajo en un entorno de prueba.
Human-in-the-loop en puntos críticos. Diseña puntos explícitos donde el agente pausa y espera confirmación humana antes de continuar. “He identificado estos tres archivos para eliminar. ¿Confirmas?” es mucho más seguro que eliminar automáticamente.
Límite de pasos y presupuesto. Define un número máximo de pasos o un presupuesto de llamadas a API. Un agente que lleva 50 pasos en una tarea que debería tomar 10 probablemente está atascado —mejor detenerlo que dejarlo seguir indefinidamente.
Logging de todas las acciones. Cada decisión y cada acción del agente debe quedar registrada de forma que puedas reconstruir qué pasó y por qué. Sin logging, depurar fallos es casi imposible.
Testing con casos límite. Antes de desplegar un agente en producción, pruébalo con inputs malformados, APIs que fallan, resultados inesperados. Los fallos en producción son caros; los fallos en testing son lecciones.
El futuro próximo: sistemas multi-agente
El área de mayor crecimiento en el ecosistema de agentes son los sistemas donde múltiples agentes colaboran, cada uno con un rol especializado.
En lugar de un único agente que intenta hacer todo, un sistema multi-agente puede tener: un agente investigador que recopila información, un agente analista que la procesa, un agente redactor que produce el output, y un agente revisor que verifica la calidad antes de entregar al humano.
La ventaja es la especialización: cada agente puede estar optimizado para su tarea específica. La desventaja es la complejidad: la coordinación entre agentes introduce nuevos puntos de fallo y hace el sistema más difícil de depurar.
Frameworks como AutoGen (Microsoft), CrewAI y el propio Claude con sus capacidades de uso de herramientas están haciendo más accesible la construcción de estos sistemas. Pero la madurez es todavía limitada: la mayoría de los sistemas multi-agente funcionan bien en demos y fallan con cierta frecuencia en producción.
La recomendación práctica para 2025-2026: empieza con agentes simples y de un solo rol. Mide la fiabilidad antes de aumentar la complejidad. El valor de los agentes está en la automatización de trabajo tedioso con supervisión humana adecuada, no en la autonomía total.
