Construir agentes de IA listos para producción
Por qué una ejecución de agente pertenece a un trabajo en segundo plano, qué cuesta de verdad un presupuesto de tokens y las cuatro salvaguardas que pongo delante de cada llamada al modelo.
Un agente es un trabajo en segundo plano, no una petición
Lo primero que falla cuando se mete un agente en un producto es la forma de la ejecución. Una sola ejecución de agente tarda minutos. Llama a un modelo, lee archivos, vuelve a llamar al modelo y escribe algo. Eso no es una petición web.
En Lemniscate el agente se ejecuta como un trabajo en un worker de Redis y BullMQ. Lee un repositorio, propone cambios, escribe el código, sube una rama y abre un pull request. El navegador nunca mantiene la conexión abierta esperando el resultado; observa un flujo de logs por server-sent events y se puede cerrar y volver a abrir sin matar la ejecución.
Lo segundo que falla es confiar en una sola pasada. Lemniscate envía opcionalmente su propio diff a una segunda llamada al modelo antes de fusionar nada. El revisor es más barato que el autor y detecta los errores obvios.
El presupuesto de tokens es un presupuesto real
Mi lección más cara vino de un modelo de razonamiento. Factura su cadena de pensamiento contra la misma asignación de salida que la respuesta. En una respuesta larga, el razonamiento consumió todo el presupuesto y el modelo no devolvió nada: ni respuesta, ni error, solo una cadena vacía.
Lo medí en lugar de suponerlo, subí el techo y añadí un manejo de continuación que pide al modelo retomar desde el punto exacto en que se detuvo y le prohíbe repetir lo que ya escribió. Desde entonces, el coste de una respuesta larga es un número que puedo predecir y no una sorpresa.
Cada integración que construyo ahora tiene cuatro cosas delante de la llamada al modelo: un timeout, una comprobación de esquema sobre la salida, un techo estricto de tokens y una ruta de respaldo.
Los respaldos no son paranoia
El médico de IA de este sitio responde preguntas sobre mis datos de salud mediante llamadas a herramientas. Cuando el modelo alojado no está disponible, recurre a un modelo que se ejecuta en el mismo servidor, más lento y menos capaz, pero que está ahí. Cuando la API devuelve una salida mal formada, el asistente responde con lo que puede verificar en lugar de inventarse un número.
Esa es la diferencia entre una funcionalidad y una demo. Una demo da por supuesto que el proveedor está disponible, que la respuesta está bien formada y que el usuario tiene paciencia.
Haz que la ejecución sea auditable
Un agente que cambia código tiene que dejar rastro. En Touchstone la API que usan los agentes devuelve esquemas de informe versionados (report/v1), así que un cliente puede saber qué forma de respuesta recibió. Cada paso queda registrado: qué se pidió, qué devolvió el modelo y qué se aceptó.
Sin ese rastro no puedes responder la única pregunta que importa después de un incidente: qué hizo de verdad.
El resumen honesto
Un agente en producción es, sobre todo, trabajo corriente de sistemas distribuidos: colas, reintentos, idempotencia, presupuestos, logs y respaldos. El modelo es una dependencia dentro de esa máquina, y se comporta como una dependencia con latencia impredecible, coste real y la costumbre de equivocarse con seguridad.
Trátalo así y las funcionalidades aguantan. Trátalo como magia y publicarás algo que funciona exactamente una vez, en tu máquina, durante la demo.