Agentes de IA en produccion: lecciones aprendidas tras 18 meses

Por que los agentes fallan en produccion

La distancia entre una demo de agente de IA funcionando en un notebook y un agente estable en produccion es enorme. Lo hemos comprobado desplegando agentes en entornos reales durante los ultimos 18 meses, y la primera leccion es clara: la mayoria de los fallos no vienen del modelo, vienen de la ingenieria que lo rodea.

Los tres patrones de fallo mas comunes que hemos observado son:

Cadenas fragiles. Un agente que encadena 6 llamadas a herramientas funciona bien el 90% del tiempo. Pero en produccion, ese 10% restante se traduce en decenas de fallos diarios. Cada paso de la cadena tiene una probabilidad de fallo, y esas probabilidades se multiplican. Una cadena de 6 pasos con 95% de fiabilidad individual tiene una fiabilidad combinada del 73%. En produccion, eso no es aceptable.

Falta de observabilidad. Cuando un agente falla, necesitas saber exactamente donde y por que. Sin trazabilidad de cada paso, cada decision del modelo y cada llamada a herramienta, diagnosticar un fallo es como depurar codigo sin logs. Hemos visto equipos que despliegan agentes sin ningun sistema de tracing y luego pasan dias intentando reproducir un bug que ocurre una vez de cada veinte ejecuciones.

Costes descontrolados. Un agente que decide hacer 15 llamadas a la API de un LLM cuando deberia hacer 3 puede multiplicar tus costes por cinco sin que lo notes hasta que llega la factura. Sin limites explicitos de tokens, de pasos, y de coste por ejecucion, un agente en produccion es una tarjeta de credito abierta.

Patrones de arquitectura que funcionan

Despues de iterar sobre multiples arquitecturas, hay patrones que hemos validado como estables para produccion.

Patron supervisor. En lugar de un unico agente monolitico que intenta resolver todo, usamos un supervisor que orquesta agentes especializados. El supervisor recibe la tarea, decide que agente la ejecuta, valida el resultado, y decide si hace falta otro paso. Esto es lo que frameworks como LangGraph implementan con su concepto de grafos dirigidos. El supervisor mantiene el estado global y cada agente especializado tiene un scope limitado, herramientas especificas, y un system prompt enfocado.

Human-in-the-loop obligatorio para acciones destructivas. Cualquier agente que pueda modificar datos, enviar comunicaciones, o ejecutar transacciones debe tener un punto de aprobacion humana antes de la accion final. En nuestro caso, esto se implementa con un sistema de colas: el agente prepara la accion, la encola con toda la informacion contextual, y un operador la aprueba o la rechaza. Las acciones de solo lectura pueden ejecutarse sin aprobacion, pero cualquier escritura pasa por el filtro.

Degradacion controlada. Cuando un paso falla, el agente no debe reintentar indefinidamente ni quedarse bloqueado. Implementamos circuitos de corte (circuit breakers) a tres niveles: por herramienta (si una API externa falla 3 veces, se desactiva temporalmente), por agente (si un agente especializado falla, el supervisor redirige a un fallback), y por sesion (si la ejecucion supera un umbral de pasos o coste, se escala a un humano). Este patron viene directamente de la ingenieria de microservicios, y aplica exactamente igual a los agentes.

Structured outputs siempre. Nunca dejamos que un agente devuelva texto libre cuando necesitamos datos estructurados. Usamos los modos de output estructurado de los modelos (JSON mode, function calling con schemas Zod/Pydantic) para garantizar que la salida es parseable. Esto elimina una categoria entera de fallos en produccion: el agente que devuelve “algo parecido” a lo esperado pero que rompe el parser downstream.

Observabilidad para agentes

La observabilidad de agentes tiene requisitos especificos que van mas alla del logging tradicional.

Tracing de cadenas completas. Cada ejecucion de un agente genera un trace que incluye: el input original, cada decision del modelo (con el reasoning si esta disponible), cada llamada a herramienta con sus parametros y resultados, cada transicion entre agentes (en arquitecturas multi-agente), y el output final. Usamos OpenTelemetry con spans personalizados para cada tipo de paso. Esto nos permite reconstruir cualquier ejecucion paso a paso.

Monitorizacion de uso de tokens. Cada llamada al LLM registra tokens de entrada, tokens de salida, modelo utilizado, y coste estimado. Agregamos estos datos por agente, por tipo de tarea, y por periodo. Esto nos da visibilidad sobre tendencias: si un agente empieza a consumir un 30% mas de tokens de media, es una senal de que algo ha cambiado, ya sea en los datos de entrada o en el comportamiento del modelo.

Metricas de calidad. Mas alla de si el agente “funciono” o “fallo”, medimos calidad. Para agentes que generan respuestas, usamos evaluaciones automaticas con un segundo modelo (LLM-as-judge) sobre una muestra. Para agentes que ejecutan acciones, medimos la tasa de acciones que requirieron correccion humana posterior. Estas metricas son las que realmente te dicen si tu agente esta aportando valor o generando trabajo adicional.

Control de costes

El coste de un agente en produccion tiene tres componentes: llamadas al LLM, llamadas a herramientas externas, y coste de infraestructura de ejecucion. El primero es el mas variable y el mas peligroso.

Presupuestos por ejecucion. Cada tipo de tarea tiene un presupuesto maximo de tokens. Si el agente alcanza el 80% del presupuesto, recibe una instruccion de comprimir su razonamiento y finalizar. Si alcanza el 100%, se corta la ejecucion y se escala. Esto previene las espirales de coste donde un agente entra en un bucle de razonamiento.

Seleccion dinamica de modelo. No todas las tareas necesitan el modelo mas potente. Usamos un router que selecciona el modelo en funcion de la complejidad estimada de la tarea. Tareas de clasificacion sencilla van a modelos rapidos y baratos. Tareas de razonamiento complejo van a modelos frontier. Esta estrategia nos ha reducido el coste medio por ejecucion un 60% sin impacto medible en calidad.

Cache de herramientas. Muchas llamadas a herramientas son repetitivas. Si un agente consulta el estado de un pedido, y otro agente consulta el mismo pedido 30 segundos despues, la segunda llamada deberia servirse de cache. Implementamos un cache con TTL configurable por tipo de herramienta. Las consultas a datos que cambian lentamente (catalogo, configuracion) tienen TTLs largos. Las consultas a datos volatiles (stock, estado de envio) tienen TTLs cortos.

Lecciones condensadas

Tras 18 meses, estas son las lecciones que nos habria gustado saber desde el dia uno:

Empieza con herramientas, no con agentes. Antes de construir un agente autonomo, implementa las herramientas individuales como funciones llamables con tests, documentacion y manejo de errores robusto. Un agente es tan bueno como sus herramientas. Si la herramienta de busqueda devuelve basura, el agente mas sofisticado del mundo producira basura.

Los prompts son codigo. Gestionalos como tal: versionados en git, con tests de regresion, con revisiones de PR. Un cambio de una linea en un system prompt puede alterar dramaticamente el comportamiento de un agente. Hemos tenido incidentes en produccion causados por cambios de prompt que parecian inocuos.

Mide antes de optimizar. La intuicion sobre donde estan los cuellos de botella de un agente casi siempre es incorrecta. El paso que crees que es lento probablemente no lo es. El paso que crees que es barato probablemente esta consumiendo la mitad de tus tokens. Sin datos, optimizas a ciegas.

Los agentes no sustituyen procesos, los ejecutan. Un agente que opera sobre un proceso roto automatiza el caos. Antes de poner un agente, asegurate de que el proceso subyacente funciona manualmente. Si un humano no puede ejecutar el proceso de forma consistente con instrucciones escritas, un agente tampoco podra.

El testing en produccion es inevitable. Por mucho que testees en staging, el comportamiento de un agente en produccion sera diferente. Los datos reales son mas ruidosos, los casos extremos son mas extremos, y los usuarios son mas creativos. Despliega con feature flags, empieza con un porcentaje bajo de trafico, y escala gradualmente. No hay atajos.

La IA agentica en produccion no es un problema de modelos. Es un problema de ingenieria. Y las soluciones son las mismas que llevamos aplicando decadas en ingenieria de software: observabilidad, testing, degradacion controlada, y respeto por la complejidad del mundo real.