La era de los agentes de IA: estado del arte en 2025
Tres cifras para enmarcar 2025
El 72% de las empresas Fortune 500 tienen al menos un proyecto de agentes de IA en marcha. Solo el 14% ha llegado a producción. Y de ese 14%, la mitad reconoce que sus agentes operan con restricciones tan severas que apenas califican como “autónomos.”
Esas tres cifras, extraídas del informe de McKinsey sobre IA generativa de diciembre de 2024, resumen el estado del arte mejor que cualquier párrafo introductorio. La tecnología está lista. La ingeniería para ponerla en producción, no tanto.
Este whitepaper documenta dónde estamos realmente. No dónde nos gustaría estar, no dónde los keynotes dicen que estamos, sino dónde están los sistemas que procesan transacciones, atienden clientes y toman decisiones de negocio todos los días. Incluye patrones de despliegue que hemos validado, estructuras de costes de proyectos reales, y las métricas que separan un agente útil de un generador de incidencias.
Definiendo “agente” sin ambigüedad
La palabra “agente” se ha inflado tanto que ha perdido significado. Un chatbot con acceso a una base de datos no es un agente. Un pipeline de RAG con un paso de decisión tampoco. Necesitamos una definición operativa.
Un agente de IA, en el contexto de este whitepaper, cumple cuatro criterios:
- Recibe un objetivo, no una instrucción paso a paso. Le dices “procesa esta factura” o “resuelve esta incidencia,” no “extrae el campo X del documento Y y escribe Z en la base de datos.”
- Planifica su propia secuencia de acciones. El agente decide qué herramientas usar, en qué orden, y cómo interpretar los resultados intermedios.
- Ejecuta acciones con efectos reales. No solo genera texto. Llama a APIs, modifica registros, envía comunicaciones.
- Reacciona a resultados inesperados. Si una herramienta falla o devuelve algo inesperado, el agente adapta su plan.
Si tu sistema no cumple los cuatro, probablemente tienes un pipeline sofisticado, no un agente. Y eso no es un insulto. Los pipelines son predecibles, testeables y baratos. A veces son la respuesta correcta.
El espectro de autonomía
No todos los agentes necesitan el mismo nivel de autonomía. De hecho, la mayoría no deberían tenerlo. Hemos identificado cuatro niveles que vemos en producción:
Nivel 1: Asistente supervisado. El agente propone acciones y un humano las aprueba. Es el modelo más común y el más seguro. Lo vemos en triaje de soporte, clasificación de documentos y redacción de respuestas. La tasa de adopción es alta porque el riesgo es bajo.
Nivel 2: Autónomo con guardrails. El agente ejecuta acciones dentro de límites estrictos. Puede procesar facturas de menos de 5.000 euros, responder preguntas sobre políticas internas, o reclasificar tickets de prioridad baja. Cualquier cosa fuera de esos límites se escala. Este es el nivel donde la mayoría de las empresas quieren estar en 2025.
Nivel 3: Autónomo con auditoría. El agente opera sin supervisión en tiempo real, pero todas sus decisiones se registran y se auditan periódicamente. Es adecuado para tareas de alto volumen y bajo riesgo: enriquecimiento de datos, monitorización de precios, generación de informes. La revisión humana ocurre después, no antes.
Nivel 4: Totalmente autónomo. El agente opera sin intervención humana en ningún punto. En producción real, esto casi no existe. Los únicos ejemplos que hemos visto son agentes de trading de alta frecuencia y sistemas de recomendación que, técnicamente, cumplen los cuatro criterios de nuestra definición pero operan en dominios donde el coste de un error individual es bajo.
La pregunta que toda empresa debería hacerse no es “cómo llego al nivel 4” sino “qué nivel necesito para cada caso de uso?”
Patrones de despliegue que funcionan en producción
Después de analizar más de 30 implementaciones (propias y de clientes), hay cuatro patrones arquitectónicos que aparecen una y otra vez en los despliegues exitosos.
Patrón 1: Orquestador-Trabajadores
El patrón más robusto. Un agente orquestador recibe la tarea, la descompone, y la delega a agentes trabajadores especializados. Cada trabajador tiene un scope limitado: uno lee documentos, otro consulta APIs, otro genera salidas estructuradas. El orquestador mantiene el estado, gestiona errores y decide cuándo la tarea está completa.
Dónde funciona: procesamiento de documentos complejos, flujos de trabajo con múltiples sistemas, tareas que combinan análisis y acción.
Dónde falla: tareas simples donde la orquestación introduce latencia innecesaria. Si tu tarea es “clasifica este email,” no necesitas tres agentes para hacerlo.
Coste típico: 2-5x más caro en tokens que un agente monolítico, pero significativamente más fiable. En una implementación de procesamiento de facturas, pasamos de un 76% de tasa de éxito con un agente único a un 94% con orquestador-trabajadores. El coste por factura subió de 0.03 a 0.08 euros, pero los 18 puntos de fiabilidad compensaron con creces.
Patrón 2: Router + Especialistas
Similar al anterior, pero el componente de enrutamiento no es un agente completo. Es un clasificador ligero (a menudo un modelo pequeño o incluso reglas heurísticas) que determina qué tipo de tarea es y la envía al especialista adecuado. Cada especialista es un agente completo, pero solo sabe hacer una cosa.
La ventaja es el coste. El router consume tokens mínimos, y cada especialista está optimizado para su dominio. Hemos visto empresas que combinan un router basado en embeddings (coste casi cero) con especialistas que usan modelos distintos según la complejidad. El especialista de clasificación usa Claude Haiku. El de razonamiento legal usa Claude Opus. El de generación de documentos usa GPT-4o.
Dónde funciona: empresas con múltiples casos de uso que quieren una interfaz unificada. Un ejemplo: una empresa de logística que usa un único punto de entrada para consultas de clientes, reclamaciones, y seguimiento de envíos, con tres especialistas detrás.
Patrón 3: Agente con Estado Persistente
La mayoría de los agentes son stateless. Reciben una tarea, la ejecutan, devuelven un resultado. Pero hay casos donde el agente necesita recordar contexto entre ejecuciones. Un agente que gestiona la relación con un cliente necesita saber qué se habló la semana pasada. Un agente que monitoriza un proceso necesita saber qué alertas ya envió.
La implementación típica usa una base de datos vectorial o un key-value store para el estado del agente, combinado con un mecanismo de resumen para comprimir el contexto histórico. Pinecone, Weaviate y pgvector son las opciones más comunes.
El riesgo: el estado acumulado puede degradar la calidad del agente si no se gestiona activamente. Hemos visto agentes que acumulaban tanto contexto histórico que el modelo se confundía y mezclaba información de clientes distintos. La solución fue implementar una ventana de contexto deslizante con resumen periódico: cada 20 interacciones, un segundo modelo genera un resumen del contexto relevante y descarta el detalle.
Patrón 4: Agente Reactivo con Event-Driven Architecture
En lugar de que un usuario o un cron dispare al agente, el agente se activa con eventos del sistema. Un nuevo email llega, se dispara el agente de clasificación. Una factura se carga en Drive, se activa el agente de procesamiento. Un ticket cambia de estado, el agente de follow-up evalúa si necesita actuar.
Este patrón encaja naturalmente con arquitecturas de microservicios que ya usan colas de mensajes. Kafka, RabbitMQ o incluso las Cloud Functions de Google como triggers. El agente se convierte en un consumer más del sistema de eventos.
Lo que hemos aprendido: el mayor riesgo es la tormenta de eventos. Un fallo upstream que genera 500 eventos repetidos puede disparar 500 ejecuciones del agente, cada una con su coste en tokens. La solución es obligatoria: deduplicación de eventos, rate limiting por fuente, y circuit breakers que paran la ejecución si la tasa de eventos supera un umbral.
Estructura de costes real
Hablemos de dinero. Los costes de un agente en producción tienen cuatro componentes, y la mayoría de las estimaciones que circulan solo consideran uno.
Componente 1: Inferencia LLM
El más visible y el que más varía. Los precios han caído dramáticamente en 2024. Claude 3.5 Sonnet cuesta $3/millón de tokens de entrada y $15/millón de salida. GPT-4o está en $2.50/$10. Los modelos pequeños (Haiku, GPT-4o-mini) cuestan 10-20x menos.
Pero el coste por token es solo la mitad de la ecuación. Lo que importa es el coste por tarea completada, y eso depende de cuántos tokens consume tu agente por ejecución.
Datos reales de tres implementaciones nuestras:
| Caso de uso | Modelo | Tokens/ejecución | Coste/ejecución | Volumen mensual | Coste mensual |
|---|---|---|---|---|---|
| Clasificación de emails | Haiku | 2.800 | 0.002 EUR | 15.000 | 30 EUR |
| Procesamiento de facturas | Sonnet | 12.000 | 0.05 EUR | 3.000 | 150 EUR |
| Análisis de contratos | Opus | 45.000 | 0.90 EUR | 200 | 180 EUR |
La varianza entre casos de uso es de 450x. Generalizar costes de IA es tan útil como decir que “un coche cuesta 30.000 euros.”
Componente 2: Herramientas y APIs externas
Cada llamada que el agente hace a una API externa tiene un coste. Google Maps, bases de datos de empresas, servicios de verificación, parseo de documentos. En nuestro agente de procesamiento de facturas, el coste de OCR (Document AI de Google, $1.50 por cada 1.000 páginas) supera al coste del LLM en volumen alto.
Componente 3: Infraestructura
El agente necesita ejecutarse en algún sitio. Si usas un framework como LangGraph Cloud o CrewAI+, pagas por ejecución. Si lo despliegas tú, pagas por compute. En Railway, un servicio que ejecuta agentes con un worker cuesta entre 5 y 20 euros al mes dependiendo del volumen. En AWS Lambda, pagas por invocación.
Componente 4: Coste humano de supervisión
El más ignorado y a menudo el más alto. Alguien tiene que revisar las acciones escaladas, analizar los errores, ajustar los prompts, y monitorizar el rendimiento. En una implementación típica de nivel 2 (autónomo con guardrails), estimamos entre 2 y 5 horas semanales de un perfil técnico para mantener un agente estable. Eso son 400-1.000 euros al mes en coste de personal.
El coste total real de un agente en producción para una pyme española está entre 600 y 2.500 euros al mes, dependiendo del caso de uso y el volumen. Eso incluye los cuatro componentes. Si alguien te dice que puedes tener un agente en producción por 50 euros al mes, no está incluyendo supervisión, infraestructura ni herramientas.
Métricas de fiabilidad: qué medir y qué ignorar
Hay métricas que importan y métricas que parecen impresionantes en un dashboard pero no te dicen nada útil.
Las que importan
Tasa de completación de tarea (TCR). Porcentaje de tareas que el agente completa sin intervención humana. Esta es la métrica reina. Si tu TCR es del 85%, significa que de cada 100 tareas, 15 necesitan un humano. Eso determina directamente el ahorro de tiempo que el agente genera.
Tasa de error crítico. Porcentaje de tareas donde el agente produce un resultado incorrecto que no se detecta automáticamente. Un agente que clasifica un email como “urgente” cuando no lo es genera ruido. Uno que procesa una factura con el importe incorrecto genera un problema contable. La primera es molesta. La segunda es costosa. Necesitas medir ambas por separado.
Tiempo medio de ejecución. No solo por eficiencia, sino porque correlaciona con coste y con experiencia de usuario. Un agente que tarda 45 segundos en responder a un cliente no es aceptable en soporte en vivo. Uno que tarda 3 minutos en procesar un documento complejo puede ser perfectamente viable.
Coste por tarea completada con éxito. No coste por ejecución. Coste por tarea que se completa correctamente. Si tu agente cuesta 0.05 euros por ejecución pero falla el 30% de las veces, tu coste real por tarea completada es 0.07 euros más el coste del humano que resuelve los fallos.
Las que no importan (tanto como crees)
Tokens por ejecución. Es útil para optimización interna, pero como métrica de negocio no dice nada. Un agente que usa muchos tokens pero completa correctamente el 98% de las tareas es mejor que uno que usa pocos pero falla el 25%.
Tiempo de primera respuesta. Relevante para chatbots, irrelevante para agentes de back-office. No optimices la métrica equivocada.
Puntuación de “helpfulness” del LLM. Las evaluaciones automáticas de calidad con LLM-as-judge son útiles para detectar regresiones, pero no son una métrica de negocio. Un agente puede ser “muy útil” según GPT-4 y seguir equivocándose en el 20% de las facturas.
Frameworks y herramientas: el mapa de 2025
El ecosistema de herramientas para construir agentes se ha consolidado significativamente en el último año. Ya no estamos en la fase de “cada semana sale un framework nuevo” (bueno, sí, pero los que importan se han estabilizado).
Frameworks de orquestación
LangGraph (LangChain) se ha convertido en el estándar de facto para agentes con estado. Su modelo de grafos dirigidos encaja bien con el patrón orquestador-trabajadores. La versión cloud añade persistencia y trazabilidad out of the box. Lo usamos en el 60% de nuestros proyectos.
CrewAI ha ganado tracción para agentes multi-rol. La metáfora de “equipo de agentes” es intuitiva para perfiles no técnicos, lo que facilita la adopción. Pero su modelo de ejecución es menos flexible que LangGraph para flujos complejos.
AutoGen (Microsoft) está bien para investigación y prototipos, pero su modelo de conversación multi-agente no escala bien para producción. Demasiada charla entre agentes, demasiados tokens consumidos en coordinación.
Agentes nativos de Anthropic y OpenAI. Ambos proveedores han lanzado SDKs de agentes propios. El Agents SDK de OpenAI y el de Anthropic con tool use avanzado. La ventaja: integración nativa con el modelo, structured outputs garantizados, y menor latencia. La desventaja: lock-in con un proveedor.
Modelos
La tabla de modelos relevantes para agentes en enero de 2025:
| Modelo | Mejor para | Coste relativo | Latencia |
|---|---|---|---|
| Claude 3.5 Opus | Razonamiento complejo, decisiones | Alto | Media |
| Claude 3.5 Sonnet | Equilibrio calidad/coste | Medio | Baja |
| Claude 3.5 Haiku | Clasificación, routing | Bajo | Muy baja |
| GPT-4o | Multimodal, generación | Medio-alto | Media |
| GPT-4o-mini | Tareas sencillas | Bajo | Baja |
| Gemini 1.5 Pro | Contexto largo, documentos | Medio | Media |
| Mixtral/Llama 3 | Self-hosted, privacidad | Infra propia | Variable |
La tendencia clara: los modelos “pequeños” de hoy son mejores que los modelos “grandes” de hace 12 meses. Claude Haiku resolviendo tareas que hace un año necesitaban GPT-4.
Observabilidad
LangSmith es el complemento natural de LangGraph. Trazabilidad completa de cadenas, evaluaciones, y datasets de prueba. Es nuestra herramienta principal.
Langfuse como alternativa open-source. Menos pulido, pero con la ventaja de que tus datos se quedan en tu infra. Para empresas con requisitos de privacidad, es la opción obvia.
OpenTelemetry con exportadores custom. Para equipos que ya tienen un stack de observabilidad (Datadog, Grafana), extender OTEL para trazas de agentes es el camino de menor fricción.
Lo que viene: tendencias para el primer semestre de 2025
Tres tendencias que estamos observando y que creemos que definirán el primer semestre.
Computer use y browser agents. Claude y otros modelos ya pueden interactuar con interfaces gráficas. Esto abre la puerta a agentes que operan aplicaciones legacy que no tienen API. Hemos prototipado un agente que navega el portal de la AEAT para descargar notificaciones. Funciona el 80% de las veces. Ese 20% restante es el motivo por el que no está en producción.
Agentes con memoria a largo plazo. Los avances en arquitecturas de memoria (MemGPT, RAG avanzado con reranking) están permitiendo agentes que mantienen contexto útil durante semanas o meses. Esto es crítico para casos como gestión de clientes, donde el agente necesita recordar interacciones previas.
Especialización vertical. Los agentes genéricos están dando paso a agentes diseñados para verticales específicas. Agentes para contabilidad española que entienden el Plan General Contable. Agentes para logística que conocen los Incoterms y la documentación de aduanas. Agentes para legal que manejan la LEC y los plazos procesales. La especialización vertical es donde está el valor real, no en el agente que sabe un poco de todo.
Recomendaciones prácticas
Si estás considerando implementar agentes de IA en tu empresa en 2025, estas son nuestras recomendaciones basadas en lo que hemos visto funcionar.
Empieza por el nivel 1. Un asistente supervisado que propone acciones. La inversión es baja, el riesgo es mínimo, y te da datos reales sobre qué casos de uso aportan valor. Tres meses con un asistente supervisado te ensenan más que seis meses planificando un agente autónomo.
Elige un caso de uso con alto volumen y bajo riesgo. Clasificación de emails, triaje de tickets, extracción de datos de documentos. No empieces por el agente que toma decisiones financieras. Empieza por el que ahorra 20 minutos diarios a un equipo de cinco personas.
Mide antes de automatizar. Antes de construir el agente, mide el proceso manual. Cuántas tareas al día. Cuánto tiempo por tarea. Cuántos errores. Sin esa baseline, no puedes demostrar ROI.
Presupuesta para los cuatro componentes de coste. No solo inferencia. Herramientas, infraestructura y supervisión humana. Si tu presupuesto solo cubre tokens de LLM, tu proyecto va a fracasar.
Invierte en observabilidad desde el día uno. No es algo que se añade después. Si no puedes ver qué hace tu agente paso a paso, no puedes diagnosticar fallos, optimizar costes ni demostrar que funciona.
Estamos en la fase donde la tecnología de agentes ya no es el cuello de botella. Lo es la ingeniería de producción, la integración con procesos existentes, y la gestión del cambio organizativo. Las empresas que lo entienden y actúan en consecuencia van a tener una ventaja competitiva real. Las que esperan a que sea “fácil” van a esperar mucho.
Si quieres explorar cómo los agentes de IA pueden encajar en tu operativa, nuestro equipo de IA y Machine Learning puede ayudarte a identificar los casos de uso con mayor impacto. También puedes revisar nuestro artículo sobre agentes de IA en producción para un análisis más técnico de las lecciones aprendidas, y nuestro artículo sobre patrones de orquestación y fallo para profundizar en los modos de fallo de agentes en producción.
Para empresas que buscan una evaluación completa de su madurez tecnológica, ofrecemos consultoría estratégica que incluye un roadmap de implementación de IA adaptado a tu sector y tamaño.
