La parte aburrida de los agentes IA que nadie construye

La parte aburrida de los agentes IA que casi nadie construye es la infraestructura de agentes IA: observabilidad, persistencia de estado, idempotencia y manejo de errores. Sin eso, un agente que brilla en la demo se cae en producción sin avisar. No es glamoroso, pero es lo que separa un proyecto que sobrevive de uno que termina archivado a los tres meses.

La infraestructura de agentes IA es el conjunto de sistemas que mantienen vivo y observable a un agente cuando deja de ser un experimento: trazas de cada llamada al modelo y a las herramientas, estado persistido fuera del context window, reintentos seguros y validaciones antes de acciones irreversibles. Es la plomería que nadie muestra en los lanzamientos pero que decide si el agente aguanta tráfico real.

¿Por qué un agente que anda en la demo se rompe en producción?

Ponele que armás un agente que resuelve tickets de soporte. En tu máquina contesta perfecto. Lo subís, entran cien usuarios a la vez y empieza a contestar cualquier cosa, repetir acciones o quedarse colgado. ¿Qué cambió? No el modelo. Cambió que ahora hay concurrencia, latencia variable, reintentos y sesiones largas, y tu agente no tiene cómo manejar nada de eso. Tema relacionado: aspectos de seguridad en agentes.

La demo es un caso ideal de una sola pasada. Producción es el mundo real, donde las cosas fallan a la mitad.

Acá viene lo incómodo: buena parte de los proyectos de agentes que arrancan nunca llegan a producción estable, y rara vez es por culpa del modelo. Es por la “última milla” de infraestructura que nadie quiso construir porque no se luce en una keynote. Observabilidad, logging estructurado y manejo de errores son tareas poco vistosas, y justamente por eso quedan para el final (o para nunca).

¿Cuáles son los 5 patrones de infraestructura que separan ganadores de fracasos?

Hay cinco patrones que aparecen una y otra vez en las guías de producción, como las de RoboRhythms. Ninguno es complejo. El problema es que se omiten.

• Claves de idempotencia en cada tool call: si el agente reintenta una acción, no debe ejecutarla dos veces. Un hash de run_id + tool_name alcanza para detectar el duplicado.
• Estado en base de datos, no en el context window: el contexto es finito, caro y no sobrevive a un reinicio. La memoria del agente va en una BD.
• Retroceso exponencial con jitter: ante un error, esperás cada vez más antes de reintentar, con algo de aleatoriedad para que no reintenten todos al mismo tiempo.
• Validación antes de lo irreversible: borrar un registro o mandar un pago necesita un chequeo previo. Un modelo equivocado no debería poder destruir datos solo.
• Rate limits por usuario: un usuario (o un loop mal hecho) no puede consumir toda tu cuota de API y dejar al resto sin servicio.

¿En qué se diferencia la observabilidad de agentes del logging tradicional?

El logging tradicional te tira líneas sueltas: “request recibido”, “error 500”. Sirve para una app web normal. Para un agente no alcanza, porque una sola tarea puede encadenar diez llamadas al modelo y veinte a herramientas, y vos necesitás ver el flujo completo, no fragmentos. Sobre eso hablamos en plataformas como ChatGPT.

La observabilidad de agentes usa trazas. La práctica que recomienda OpenTelemetry es wrappear cada llamada al LLM en un span y tagearlo con el modelo, los tokens y el costo. Después wrappeás cada tool call con su timestamp y su resultado. Todo lleva un workflow_id y un user_id para poder reconstruir la sesión entera.

¿La diferencia práctica? Cuando algo falla, en vez de adivinar mirando logs sueltos, abrís la traza y ves exactamente en qué paso se rompió, qué prompt entró y qué devolvió el modelo. Eso es lo que convierte un misterio de dos horas en un fix de cinco minutos.

¿Qué herramientas de observabilidad de agentes conviene usar en 2026?

El ecosistema maduró bastante. Langfuse es open source y se puede autoalojar, lo que te saca de encima el costo por asiento. LangSmith encaja si ya trabajás con LangChain o LangGraph. Arize Phoenix viene fuerte en evaluaciones, y Helicone es liviano para empezar. Acá una comparación rápida.

Herramienta	Qué captura	Cuándo usarla	Costo relativo
Langfuse	Trazas, prompts, evaluaciones, costos	Querés open source o autoalojado	Gratis (self-host) / pago gestionado
LangSmith	Trazas nodo por nodo, debugging	Stack LangChain / LangGraph	Medio
Arize Phoenix	Evaluaciones, detección de drift	Te importa medir calidad, no solo loguear	Gratis / pago empresarial
Helicone	Proxy de llamadas, costos, caché	Setup rápido con poco código	Bajo

Eso sí: la herramienta no te salva si no instrumentás bien. Cualquiera de estas te da trazas hermosas solo si vos pusiste los spans donde van.

¿Cuáles son los patrones de error silencioso más comunes en agentes IA?

Los errores ruidosos son fáciles: revientan, los ves, los arreglás. Los silenciosos son los que te arruinan el fin de semana. Estos son los clásicos. Para más detalles técnicos, mirá en los modelos de lenguaje.

• JSON inválido sin logear: el modelo devuelve algo que no parsea, el parser falla en silencio y el agente sigue como si nada con datos vacíos.
• Timeout a mitad de camino: una tool call se corta pero el estado quedó intermedio. Para el agente “no pasó”, para tu base de datos sí pasó.
• Degradación de contexto: en sesiones de dos horas o más, el agente empieza a perder el hilo y a contestar cosas viejas o incoherentes.
• Retroceso exponencial ingenuo: reintentar sin jitter hace que todos los clientes golpeen la API al mismo tiempo y empeoren el rate limit que querías evitar.
• Deriva de orquestación bajo latencia: cuando los pasos se demoran, el orden de ejecución se desordena y el agente toma decisiones sobre estado desactualizado.

¿Cómo los detectás? Con las trazas. Si cada llamada y cada parseo tiene su span, el JSON roto deja rastro en vez de desaparecer. La guía de Sentry sobre monitoreo de agentes insiste en este punto: lo que no instrumentás, no existe cuando falla.

¿Por qué el estado del agente no puede vivir en el context window?

El context window es finito, cuesta plata por token y se evapora cuando hay un reintento o un reinicio. Apoyar la memoria del agente ahí es como guardar tu base de datos en la RAM y rezar para que no se corte la luz.

La arquitectura que funciona separa el estado en tres capas. El estado conversacional (lo último que se dijo) va en algo rápido como Redis. El estado de tarea (qué pasos se completaron) va en una base relacional. El estado de herramientas (resultados cacheados, archivos) va en caché o almacenamiento. Si manejás infraestructura web propia para esto, en Argentina podés montar esa capa de servidores y bases sobre donweb.com sin depender de proveedores afuera.

El ejemplo concreto: un agente de soporte que atiende un caso durante horas. Sin persistencia, cada reintento pierde la historia y el usuario tiene que repetir todo. Con persistencia, la sesión se retoma transparente al día siguiente como si nada se hubiera cortado.

Errores comunes al construir infraestructura de agentes

• Dejar la observabilidad para “después”: después nunca llega, y cuando el agente falla en producción no tenés con qué debuggear. Instrumentá desde el primer día, aunque el agente sea mínimo.
• Confundir logging con trazas: tirar print por todos lados no es observabilidad. Necesitás spans correlacionados por workflow_id, no líneas sueltas.
• Reintentar sin idempotencia: meter retry logic sin claves de idempotencia es peor que no reintentar, porque duplicás acciones. Stripe, por ejemplo, usa claves de idempotencia justamente para que un pago reintentado no se cobre dos veces.
• Validar después de actuar: chequear si la acción estuvo bien una vez que ya borraste el registro no sirve. La validación va antes de lo irreversible, siempre.

Preguntas Frecuentes

¿Cuál es la parte aburrida que nadie construye en agentes IA?

La infraestructura: observabilidad, persistencia de estado, idempotencia y manejo de errores. Son tareas poco vistosas que no aparecen en las demos, pero sin ellas el agente falla en silencio apenas toca tráfico real. Relacionado: las APIs de Google.

¿Qué diferencia hay entre monitoreo tradicional y observabilidad de agentes?

El monitoreo tradicional registra eventos sueltos como errores y latencia. La observabilidad de agentes usa trazas que siguen el flujo completo de una tarea, encadenando cada llamada al modelo y a las herramientas bajo un mismo identificador para reconstruir la sesión entera.

¿Cómo evito que mi agente falle en silencio en producción?

Instrumentá cada llamada con spans de OpenTelemetry, logueá los parseos de JSON y los timeouts, y persistí el estado en una base de datos. Lo que no instrumentás no deja rastro cuando se rompe, así que la regla es trazar todo desde el inicio.

¿Qué es una clave de idempotencia en un agente?

Es un identificador único, por ejemplo un hash de run_id + tool_name, que permite reintentar una acción sin ejecutarla dos veces. Garantiza que un retry no duplique un pago, un envío o un borrado.

¿Cuál es la mejor herramienta de observabilidad open source para agentes?

Langfuse es la opción open source más usada en 2026: captura trazas, prompts, evaluaciones y costos, y se puede autoalojar para evitar el cobro por asiento. Para stacks LangChain o LangGraph, LangSmith integra mejor.

Conclusión

El modelo dejó de ser el problema. En 2026, lo que decide si un agente vive o muere en producción es la infraestructura de agentes IA que armás alrededor: si trazás cada paso, si el estado vive fuera del contexto, si los reintentos son seguros y si validás antes de romper datos. Nada de eso es glamoroso y por eso casi nadie lo construye.

El consejo concreto: antes de sumar una herramienta o un modelo más potente, instrumentá lo que ya tenés. Poné spans, persistí el estado en una base, agregá claves de idempotencia. Es la diferencia entre un agente que zafa en la demo y uno que aguanta el lunes a la mañana con todos los usuarios encima.

Fuentes

• OpenTelemetry – Observabilidad de agentes IA con trazas y spans
• IBM Think – Por qué importa la observabilidad de agentes
• RoboRhythms – Patrones de infraestructura para agentes en producción
• Sentry – Guía de monitoreo de agentes para desarrolladores
• Langfuse – Plataforma open source de observabilidad LLM