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 produccion. Y de ese 14%, la mitad reconoce que sus agentes operan con restricciones tan severas que apenas califican como “autonomos.”

Esas tres cifras, extraidas del informe de McKinsey sobre IA generativa de diciembre de 2024, resumen el estado del arte mejor que cualquier parrafo introductorio. La tecnologia esta lista. La ingenieria para ponerla en produccion, no tanto.

Este whitepaper documenta donde estamos realmente. No donde nos gustaria estar, no donde los keynotes dicen que estamos, sino donde estan los sistemas que procesan transacciones, atienden clientes y toman decisiones de negocio todos los dias. Incluye patrones de despliegue que hemos validado, estructuras de costes de proyectos reales, y las metricas que separan un agente util de un generador de incidencias.

Definiendo “agente” sin ambiguedad

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 decision tampoco. Necesitamos una definicion operativa.

Un agente de IA, en el contexto de este whitepaper, cumple cuatro criterios:

1. Recibe un objetivo, no una instruccion 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.”
2. Planifica su propia secuencia de acciones. El agente decide que herramientas usar, en que orden, y como interpretar los resultados intermedios.
3. Ejecuta acciones con efectos reales. No solo genera texto. Llama a APIs, modifica registros, envia comunicaciones.
4. 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 autonomia

No todos los agentes necesitan el mismo nivel de autonomia. De hecho, la mayoria no deberian tenerlo. Hemos identificado cuatro niveles que vemos en produccion:

Nivel 1: Asistente supervisado. El agente propone acciones y un humano las aprueba. Es el modelo mas comun y el mas seguro. Lo vemos en triaje de soporte, clasificacion de documentos y redaccion de respuestas. La tasa de adopcion es alta porque el riesgo es bajo.

Nivel 2: Autonomo con guardrails. El agente ejecuta acciones dentro de limites estrictos. Puede procesar facturas de menos de 5.000 euros, responder preguntas sobre politicas internas, o reclasificar tickets de prioridad baja. Cualquier cosa fuera de esos limites se escala. Este es el nivel donde la mayoria de las empresas quieren estar en 2025.

Nivel 3: Autonomo con auditoria. El agente opera sin supervision en tiempo real, pero todas sus decisiones se registran y se auditan periodicamente. Es adecuado para tareas de alto volumen y bajo riesgo: enriquecimiento de datos, monitorizacion de precios, generacion de informes. La revision humana ocurre despues, no antes.

Nivel 4: Totalmente autonomo. El agente opera sin intervencion humana en ningun punto. En produccion real, esto casi no existe. Los unicos ejemplos que hemos visto son agentes de trading de alta frecuencia y sistemas de recomendacion que, tecnicamente, cumplen los cuatro criterios de nuestra definicion pero operan en dominios donde el coste de un error individual es bajo.

La pregunta que toda empresa deberia hacerse no es “como llego al nivel 4” sino “que nivel necesito para cada caso de uso?”

Patrones de despliegue que funcionan en produccion

Despues de analizar mas de 30 implementaciones (propias y de clientes), hay cuatro patrones arquitectonicos que aparecen una y otra vez en los despliegues exitosos.

Patron 1: Orquestador-Trabajadores

El patron mas 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 cuando la tarea esta completa.

Donde funciona: procesamiento de documentos complejos, flujos de trabajo con multiples sistemas, tareas que combinan analisis y accion.

Donde falla: tareas simples donde la orquestacion introduce latencia innecesaria. Si tu tarea es “clasifica este email,” no necesitas tres agentes para hacerlo.

Coste tipico: 2-5x mas caro en tokens que un agente monolitico, pero significativamente mas fiable. En una implementacion de procesamiento de facturas, pasamos de un 76% de tasa de exito con un agente unico a un 94% con orquestador-trabajadores. El coste por factura subio de 0.03 a 0.08 euros, pero los 18 puntos de fiabilidad compensaron con creces.

Patron 2: Router + Especialistas

Similar al anterior, pero el componente de enrutamiento no es un agente completo. Es un clasificador ligero (a menudo un modelo pequeno o incluso reglas heuristicas) que determina que tipo de tarea es y la envia al especialista adecuado. Cada especialista es un agente completo, pero solo sabe hacer una cosa.

La ventaja es el coste. El router consume tokens minimos, y cada especialista esta optimizado para su dominio. Hemos visto empresas que combinan un router basado en embeddings (coste casi cero) con especialistas que usan modelos distintos segun la complejidad. El especialista de clasificacion usa Claude Haiku. El de razonamiento legal usa Claude Opus. El de generacion de documentos usa GPT-4o.

Donde funciona: empresas con multiples casos de uso que quieren una interfaz unificada. Un ejemplo: una empresa de logistica que usa un unico punto de entrada para consultas de clientes, reclamaciones, y seguimiento de envios, con tres especialistas detras.

Patron 3: Agente con Estado Persistente

La mayoria 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 relacion con un cliente necesita saber que se hablo la semana pasada. Un agente que monitoriza un proceso necesita saber que alertas ya envio.

La implementacion tipica 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 historico. Pinecone, Weaviate y pgvector son las opciones mas comunes.

El riesgo: el estado acumulado puede degradar la calidad del agente si no se gestiona activamente. Hemos visto agentes que acumulaban tanto contexto historico que el modelo se confundia y mezclaba informacion de clientes distintos. La solucion fue implementar una ventana de contexto deslizante con resumen periodico: cada 20 interacciones, un segundo modelo genera un resumen del contexto relevante y descarta el detalle.

Patron 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 clasificacion. Una factura se carga en Drive, se activa el agente de procesamiento. Un ticket cambia de estado, el agente de follow-up evalua si necesita actuar.

Este patron 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 mas 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 solucion es obligatoria: deduplicacion de eventos, rate limiting por fuente, y circuit breakers que paran la ejecucion si la tasa de eventos supera un umbral.

Estructura de costes real

Hablemos de dinero. Los costes de un agente en produccion tienen cuatro componentes, y la mayoria de las estimaciones que circulan solo consideran uno.

Componente 1: Inferencia LLM

El mas visible y el que mas varia. Los precios han caido dramaticamente en 2024. Claude 3.5 Sonnet cuesta $3/millon de tokens de entrada y $15/millon de salida. GPT-4o esta en $2.50/$10. Los modelos pequenos (Haiku, GPT-4o-mini) cuestan 10-20x menos.

Pero el coste por token es solo la mitad de la ecuacion. Lo que importa es el coste por tarea completada, y eso depende de cuantos tokens consume tu agente por ejecucion.

Datos reales de tres implementaciones nuestras:

Caso de uso	Modelo	Tokens/ejecucion	Coste/ejecucion	Volumen mensual	Coste mensual
Clasificacion 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
Analisis 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 util 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 verificacion, parseo de documentos. En nuestro agente de procesamiento de facturas, el coste de OCR (Document AI de Google, $1.50 por cada 1.000 paginas) supera al coste del LLM en volumen alto.

Componente 3: Infraestructura

El agente necesita ejecutarse en algun sitio. Si usas un framework como LangGraph Cloud o CrewAI+, pagas por ejecucion. Si lo despliegas tu, 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 invocacion.

Componente 4: Coste humano de supervision

El mas ignorado y a menudo el mas alto. Alguien tiene que revisar las acciones escaladas, analizar los errores, ajustar los prompts, y monitorizar el rendimiento. En una implementacion tipica de nivel 2 (autonomo con guardrails), estimamos entre 2 y 5 horas semanales de un perfil tecnico 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 produccion para una pyme espanola esta 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 produccion por 50 euros al mes, no esta incluyendo supervision, infraestructura ni herramientas.

Metricas de fiabilidad: que medir y que ignorar

Hay metricas que importan y metricas que parecen impresionantes en un dashboard pero no te dicen nada util.

Las que importan

Tasa de completacion de tarea (TCR). Porcentaje de tareas que el agente completa sin intervencion humana. Esta es la metrica 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 critico. Porcentaje de tareas donde el agente produce un resultado incorrecto que no se detecta automaticamente. 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 ejecucion. 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 exito. No coste por ejecucion. Coste por tarea que se completa correctamente. Si tu agente cuesta 0.05 euros por ejecucion pero falla el 30% de las veces, tu coste real por tarea completada es 0.07 euros mas el coste del humano que resuelve los fallos.

Las que no importan (tanto como crees)

Tokens por ejecucion. Es util para optimizacion interna, pero como metrica 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 metrica equivocada.

Puntuacion de “helpfulness” del LLM. Las evaluaciones automaticas de calidad con LLM-as-judge son utiles para detectar regresiones, pero no son una metrica de negocio. Un agente puede ser “muy util” segun GPT-4 y seguir equivocandose 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 ultimo ano. Ya no estamos en la fase de “cada semana sale un framework nuevo” (bueno, si, pero los que importan se han estabilizado).

Frameworks de orquestacion

LangGraph (LangChain) se ha convertido en el estandar de facto para agentes con estado. Su modelo de grafos dirigidos encaja bien con el patron orquestador-trabajadores. La version cloud anade persistencia y trazabilidad out of the box. Lo usamos en el 60% de nuestros proyectos.

CrewAI ha ganado traccion para agentes multi-rol. La metafora de “equipo de agentes” es intuitiva para perfiles no tecnicos, lo que facilita la adopcion. Pero su modelo de ejecucion es menos flexible que LangGraph para flujos complejos.

AutoGen (Microsoft) esta bien para investigacion y prototipos, pero su modelo de conversacion multi-agente no escala bien para produccion. Demasiada charla entre agentes, demasiados tokens consumidos en coordinacion.

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: integracion 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	Clasificacion, routing	Bajo	Muy baja
GPT-4o	Multimodal, generacion	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 “pequenos” de hoy son mejores que los modelos “grandes” de hace 12 meses. Claude Haiku resolviendo tareas que hace un ano 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 opcion 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 friccion.

Lo que viene: tendencias para el primer semestre de 2025

Tres tendencias que estamos observando y que creemos que definiran el primer semestre.

Computer use y browser agents. Claude y otros modelos ya pueden interactuar con interfaces graficas. 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 esta en produccion.

Agentes con memoria a largo plazo. Los avances en arquitecturas de memoria (MemGPT, RAG avanzado con reranking) estan permitiendo agentes que mantienen contexto util durante semanas o meses. Esto es critico para casos como gestion de clientes, donde el agente necesita recordar interacciones previas.

Especializacion vertical. Los agentes genericos estan dando paso a agentes disenados para verticales especificas. Agentes para contabilidad espanola que entienden el Plan General Contable. Agentes para logistica que conocen los Incoterms y la documentacion de aduanas. Agentes para legal que manejan la LEC y los plazos procesales. La especializacion vertical es donde esta el valor real, no en el agente que sabe un poco de todo.

Recomendaciones practicas

Si estas 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 inversion es baja, el riesgo es minimo, y te da datos reales sobre que casos de uso aportan valor. Tres meses con un asistente supervisado te ensenan mas que seis meses planificando un agente autonomo.

Elige un caso de uso con alto volumen y bajo riesgo. Clasificacion de emails, triaje de tickets, extraccion 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. Cuantas tareas al dia. Cuanto tiempo por tarea. Cuantos errores. Sin esa baseline, no puedes demostrar ROI.

Presupuesta para los cuatro componentes de coste. No solo inferencia. Herramientas, infraestructura y supervision humana. Si tu presupuesto solo cubre tokens de LLM, tu proyecto va a fracasar.

Invierte en observabilidad desde el dia uno. No es algo que se anade despues. Si no puedes ver que hace tu agente paso a paso, no puedes diagnosticar fallos, optimizar costes ni demostrar que funciona.

Estamos en la fase donde la tecnologia de agentes ya no es el cuello de botella. Lo es la ingenieria de produccion, la integracion con procesos existentes, y la gestion del cambio organizativo. Las empresas que lo entienden y actuan en consecuencia van a tener una ventaja competitiva real. Las que esperan a que sea “facil” van a esperar mucho.

Si quieres explorar como 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. Tambien puedes revisar nuestro articulo sobre agentes de IA en produccion para un analisis mas tecnico de las lecciones aprendidas, y nuestro articulo sobre patrones de orquestacion y fallo para profundizar en los modos de fallo de agentes en produccion.

Para empresas que buscan una evaluacion completa de su madurez tecnologica, ofrecemos consultoria estrategica que incluye un roadmap de implementacion de IA adaptado a tu sector y tamano.