Agentes de IA en producción: lo que nadie te cuenta antes del primer deploy

La demo miente, y miente bien

Todo agente de IA parece genial en los primeros quince minutos. Le das una tarea, encadena tres llamadas a herramientas, devuelve una respuesta redonda y la sala aplaude. El problema es que la demo corre en el caso feliz: entrada limpia, un intento, nadie mirando el costo.

Producción es lo contrario. Entrada sucia, mil ejecuciones por día, y alguien — probablemente tú — de guardia a las dos de la mañana.

Un agente en producción no es un modelo con un prompt. Es un sistema distribuido en el que uno de los nodos es no determinista.

Los cuatro puntos donde se rompe

1. El contexto revienta en el peor momento. Mientras el historial es corto, todo cabe. En la conversación número cuarenta, el agente ya olvidó la instrucción del principio y empieza a inventar con confianza. Trata la ventana de contexto como un presupuesto con dueño: lo que entra, entra por decisión explícita.

2. La herramienta falla y el modelo improvisa. Cuando una API devuelve un 500, el modelo tiende a seguir adelante con una suposición plausible. Devuelve los errores como datos estructurados y di, en el prompt, qué hacer ante cada uno. Un error tratado es un error que no se convierte en alucinación.

3. El costo crece en silencio. Reintentos, el historial entero reenviado en cada paso, herramientas que devuelven un JSON gigante. La factura se triplica sin una sola línea de código nueva. Mide los tokens por ejecución desde el primer día — la métrica que nadie recoge es la que explota.

4. No se puede depurar lo que no se registró. Sin el rastro completo de cada paso — prompt, respuesta, llamada, retorno — no investigas: adivinas.

Lo que de verdad ayuda

• Contrato de salida. Pide JSON con esquema y valida antes de usarlo. La salida libre es deuda técnica con intereses.
• Un agente, un trabajo. Varios agentes pequeños y verificables le ganan a un agente omnisciente.
• Verificación adversarial. Un segundo paso cuya única función es intentar tumbar la respuesta del primero tumba muchas cosas equivocadas antes de que las vea el usuario.
• Techo explícito. Límite de pasos, de tiempo y de costo por ejecución. Un bucle infinito con una tarjeta de crédito acoplada es una categoría de bug nueva.
• Registrarlo todo. Guarda la ejecución entera. Es lo que convierte un incidente en aprendizaje.

tarea → planear → ejecutar herramienta → verificar → responder
                ↑______________ falló ______________|
                        (con techo de intentos)

El criterio que uso antes de publicar

Antes de poner cualquier agente en producción, respondo tres preguntas. Si alguna se queda sin respuesta, no sube.

1. Cuando se equivoque, ¿cómo me entero yo — antes de que me lo diga el usuario?
2. ¿Cuál es el peor caso de costo de una sola ejecución?
3. ¿Existe un camino en el que el agente cause daño irreversible sin confirmación humana?

Un buen agente no es el que acierta en la demo. Es el que falla de forma previsible, barata y visible.

Para el próximo artículo

Voy a desmenuzar el punto más ignorado de esa lista: cómo montar la capa de observabilidad de un agente sin ahogar al equipo en registros. Si quieres seguirlo, los canales están justo abajo, en la firma.