Agentes LLM en producción: del prototipo al sistema fiable

Una demo de agente se construye en una tarde. Un agente LLM en producción que no te despierte de madrugada lleva semanas. La distancia entre ambos no la marca el modelo —da casi igual cuál uses— sino todo lo que rodea a la llamada: cómo orquestas los pasos, qué herramientas dejas invocar, qué recuerda entre turnos, qué pasa cuando el proveedor te devuelve un 429 y cómo sabes si lo que respondió estaba bien. Este artículo es lo que he aprendido construyendo sistemas con LLM que tienen que funcionar cuando no estoy mirando.

Qué cambia al pasar de la demo a producción

En una demo controlas la entrada. Eliges el prompt que luce bien, lo ejecutas tres veces y grabas la que sale perfecta. En producción la entrada la pone un usuario real, a veces con mala fe, y el sistema tiene que responder mil veces seguidas sin degradarse. Ahí afloran cuatro problemas que la demo esconde:

• No determinismo. El mismo prompt da respuestas distintas. Lo que funciona “casi siempre” falla el 5% de las veces, y ese 5% son tickets de soporte.
• Coste y latencia reales. Cada token cuesta dinero y tiempo. Un agente que encadena seis llamadas para una tarea trivial es inviable a escala.
• Fallos del proveedor. Rate limits, timeouts, cortes de servicio. Si tu producto depende de una sola API, su caída es tu caída.
• Acciones con efectos. En la demo el agente “sugiere”. En producción el agente hace: escribe en una base de datos, envía un correo, despliega. Un error deja de ser texto feo y pasa a ser un incidente.

Diseñar para producción es, en esencia, diseñar para estos cuatro fallos desde el primer día.

Orquestación: menos autonomía, más control

La fantasía del agente totalmente autónomo —le das un objetivo y se las apaña— vende muy bien y funciona muy mal. Cuanto más libre dejas el bucle de razonamiento, más se desvía, más cuesta y más difícil es depurar por qué hizo lo que hizo.

En la práctica, los sistemas fiables se parecen más a una máquina de estados con LLM en los nodos que a un agente suelto. Tú defines los pasos posibles y las transiciones; el modelo decide qué rama tomar y rellena los huecos, pero no inventa el flujo. Esto te da algo que la autonomía pura no: trazabilidad. Cuando algo falla, sabes en qué nodo y por qué.

Una heurística que aplico: empieza por el grafo más rígido que resuelva el problema y solo añade libertad donde el rígido se quede corto. Un clasificador que enruta a tres ramas fijas resuelve más casos reales de los que la gente cree, a una fracción del coste de un agente que “razona” en cada turno.

El terminal de IA de este mismo portfolio sigue esa filosofía: no es un agente que pueda hacer cualquier cosa, es un asistente con un contexto acotado (mis proyectos y mi stack, vía RAG) y un único trabajo bien definido. Menos superficie, menos formas de romperse.

Function-calling: el contrato con el mundo real

Las herramientas (function-calling) son lo que convierte un chatbot en un agente: le dan la capacidad de leer datos frescos y ejecutar acciones. También son la principal fuente de bugs sutiles.

Tres reglas que me ahorran problemas:

1. Esquemas estrictos y validados. El modelo te devolverá argumentos que casi cumplen el esquema. Valida con Zod (o Pydantic en el backend Python) antes de ejecutar nada, y devuelve el error de validación al modelo para que se corrija. No confíes en que el JSON venga bien formado.
2. Idempotencia y permisos por herramienta. Leer es barato y reversible; escribir, ejecutar comandos o tocar la red, no. Separa las herramientas por nivel de riesgo y haz que las peligrosas pasen por una confirmación, al menos hasta que tengas confianza estadística en el comportamiento.
3. Descripciones como interfaz. La descripción de cada herramienta es su documentación para el modelo. Una descripción ambigua provoca que el agente llame a la función equivocada. Trátalas como parte del código, no como un comentario.

El principio de fondo es de diseño de software de toda la vida: interfaces pequeñas y específicas. Una herramienta que hace una cosa y la hace clara se invoca bien; una herramienta “navaja suiza” con diez parámetros opcionales confunde al modelo igual que confundiría a un humano.

Memoria: el problema no es recordar, es olvidar lo correcto

“Dale memoria al agente” suena trivial y no lo es. El contexto de un LLM es finito y caro; no puedes meter todo el historial en cada llamada. La memoria útil es selección, no acumulación.

Distingo tres capas:

• Memoria de trabajo: lo que está pasando en esta conversación. Va completa en el prompt mientras quepa; cuando crece, se resume.
• Memoria a largo plazo: hechos que deben persistir entre sesiones (preferencias, decisiones previas). Vive en una base vectorial y se recupera por relevancia.
• Conocimiento del dominio (RAG): los datos sobre los que opera el agente. No es “memoria” del agente, es la fuente de verdad que consulta.

La pieza que más rendimiento da es el RAG bien hecho. En RecruitSecure AI —búsqueda semántica de candidatos que corre 100% en el navegador con Transformers.js— el truco no es el modelo de embeddings, es la búsqueda en dos fases: primero filtros booleanos baratos (ubicación, años de experiencia) y solo después embeddings sobre el subconjunto resultante. Recuperar lo justo, en el momento justo, es lo que hace que una consulta compleja responda rápido en vez de calcular vectores sobre todo el corpus.

El mismo patrón aplica a la memoria de un agente: cada token recuperado que no aporta es señal diluida, más coste y más latencia. La pregunta correcta no es “¿qué puedo recordar?” sino “¿qué es lo mínimo que necesito ahora?”.

Guardarraíles: asume que el agente se va a equivocar

Un LLM expresa la misma seguridad cuando acierta que cuando inventa. Por eso los guardarraíles no son un extra de cumplimiento, son parte de la lógica del sistema. Van en dos direcciones:

• Entrada: sanea lo que llega. Detecta intentos de inyección de prompt, recorta tamaños, rechaza peticiones fuera de dominio antes de gastar un token.
• Salida: valida lo que sale antes de que llegue al usuario o de que dispare una acción. Comprobaciones deterministas, no “que otro LLM lo revise”.

El terminal de IA de este portfolio usa exactamente esto: un filtro determinista a la salida que bloquea respuestas fuera de tono antes de mostrarlas. No le pido al modelo que “se porte bien”; verifico su salida con código que siempre da el mismo resultado. La regla general: la verificación crítica nunca debe depender de otra llamada no determinista. Si la comprobación de seguridad puede alucinar, no es una comprobación de seguridad.

Costes y latencia: el agente más barato es el que no llamas

Cada llamada a un LLM tiene un coste en dinero y en milisegundos, y los agentes encadenan llamadas. Las palancas que mejor funcionan:

• Enruta por dificultad. No todo necesita el modelo grande. Un clasificador pequeño y barato decide qué casos merecen el modelo caro. La mayoría no.
• Cachea lo cacheable. Respuestas a preguntas frecuentes, embeddings ya calculados, resultados de herramientas deterministas. Una cache LRU bien puesta quita un porcentaje enorme de llamadas.
• Haz streaming. No reduce el coste, pero la latencia percibida se desploma cuando el usuario ve tokens aparecer en vez de un spinner.
• Acota el contexto. Menos tokens de entrada es menos dinero y menos latencia en cada turno. La ingeniería de contexto es también ingeniería de costes.

Resiliencia: ningún proveedor es tu única opción

Si tu agente depende de una sola API, su rate limit es tu techo y su caída es tu caída. La solución es una cadena de proveedores con fallback: si el primario falla o te limita, caes al siguiente sin que el usuario lo note.

Esto no es teoría. En DevFlow AI, la suite de herramientas para desarrolladores, la IA corre sobre una cadena gratuita y resiliente —Gemini Flash → Groq → OpenRouter → Pollinations— de modo que el servicio sigue en pie aunque uno de los eslabones se caiga. El terminal de este portfolio usa el mismo patrón con Groq como primario y OpenRouter y Pollinations como red de seguridad. El coste de implementarlo es bajo; el coste de no tenerlo lo pagas el día que tu único proveedor tiene un mal día.

A esto súmale lo básico de cualquier sistema distribuido: timeouts agresivos, reintentos con backoff y circuit breakers. Un agente que se queda esperando 60 segundos a una API caída no es resiliente, es un cuello de botella con buena prensa.

Evaluación: si no lo mides, no está en producción, está en pruebas

Esta es la parte que casi todo el mundo se salta y la que separa un juguete de un sistema. No puedes mejorar lo que no mides, y “lo he probado y va bien” no es una métrica.

Lo mínimo viable:

• Un set de evaluación. Casos reales con su salida esperada. Cada cambio de prompt o de modelo se pasa contra ese set antes de desplegar. Sin esto, cada ajuste es una apuesta a ciegas.
• Trazas de cada ejecución. Qué herramientas llamó, con qué argumentos, cuántos tokens, cuánto tardó. Cuando algo falla en producción, la traza es la diferencia entre arreglarlo en diez minutos o en dos días.
• Métricas de negocio, no solo técnicas. Tasa de resolución, intervención humana, coste por tarea. La perplejidad del modelo no le importa a nadie; el porcentaje de tickets que el agente cierra solo, sí.

Un agente sin forma de verificar su propio trabajo no es autónomo: es un generador de texto plausible al que todavía tienes que revisar línea a línea.

El recorrido completo, no la demo

Llevar un agente LLM a producción es un trabajo de ingeniería de sistemas con un componente de IA, no un trabajo de IA con algo de software alrededor. Orquestación trazable, herramientas con contrato, memoria selectiva, guardarraíles deterministas, costes bajo control, resiliencia multi-proveedor y evaluación continua. Cada una de esas piezas es la diferencia entre un agente que ayuda y uno que estorba.

Es exactamente el tipo de problema en el que disfruto: coger un prototipo que impresiona en una demo y convertirlo en algo que aguanta tráfico real, errores reales y usuarios reales sin romperse.

Si estás llevando agentes LLM a producción —o tienes un prototipo prometedor atascado en el “casi”— hablemos. Te cuento sin compromiso dónde están los baches antes de que te los comas.