Agentes de IA: cómo diseñar uno que no falle en producción

La mayoría de los agentes que fallan en producción no fallan por el modelo. Fallan porque nadie definió dónde termina su alcance, qué devuelve cada herramienta cuando algo sale mal y cuánto puede gastar antes de rendirse. Esto es una guía de diseño, no una lista de frameworks.

Qué es un agente y qué no

Un agente es un bucle: el modelo elige una acción, la ejecuta, observa el resultado y decide el siguiente paso. Además del bucle necesita dos cosas que casi nadie documenta: herramientas con contrato y un estado explícito.

Si la secuencia de pasos ya la conoces de antemano, no tienes un agente. Tienes un flujo. Clasificar un ticket, extraer datos de una factura o generar un resumen semanal se resuelven mejor con un pipeline fijo: entrada, transformación, salida. Es más barato, más rápido y más fácil de probar.

El sello "agente" se aplica hoy a cadenas de prompts que no deciden nada. Un flujo disfrazado solo añade variabilidad.

El estado es el componente olvidado

Sin un objeto de estado explícito, el historial de la conversación se convierte en el estado. Eso funciona en una demo y se rompe cuando la sesión dura veinte turnos: el agente repite pasos, pierde el hilo o arrastra un error antiguo.

Define el estado como un contrato: qué datos necesita, qué ha intentado ya, qué herramientas fallaron y en qué punto está. Si puedes serializarlo, puedes reanudar una ejecución, comparar dos versiones y depurar sin adivinar.

Cuándo no usar un agente

Un agente se justifica cuando se cumplen tres condiciones: el camino no se conoce de antemano, las herramientas devuelven resultados variables y un error intermedio se puede detectar y corregir.

Si falta una de las tres, usa algo más simple. En soporte, la mayoría de los casos son clasificación y respuesta con plantilla. En ventas, calificación con reglas y un resumen. En operaciones, validación de datos contra un esquema. Ninguno necesita un bucle abierto.

El coste real de un agente no son los tokens. Es la superficie de depuración. Cada decisión libre añade ramas que debes probar, y las ramas que no pruebas son las que aparecen en producción un viernes.

Señales de que no lo necesitas:

• ¿Puedes enumerar los pasos de antemano? Entonces es un flujo.
• ¿La respuesta ya está en un documento o en una tabla? Entonces es búsqueda o consulta.
• ¿Un error intermedio es irreversible? Entonces necesitas confirmación humana, no más autonomía.

Diseñar herramientas, no prompts

El modelo elige herramientas leyendo su nombre y su descripción. En la práctica, esa descripción pesa más que el prompt del sistema cuando hay dudas. Trátala como parte del producto.

Una herramienta debe tener una sola intención, un esquema de entrada cerrado y una salida que quepa en el contexto. gestionar_cliente no es una herramienta: son cuatro herramientas con permisos distintos.

• Separa lectura de escritura. Las lecturas se pueden paralelizar y reintentar; las escrituras necesitan clave de idempotencia.
• Devuelve éxito parcial. "Encontré la orden pero no el envío" es más útil que un error genérico.
• Escribe errores que indiquen el siguiente paso: "sin resultados con ese correo, prueba con el número de pedido".
• Limita el tamaño de la respuesta. Una herramienta que devuelve cuarenta páginas de JSON contamina el contexto y esconde lo importante.

Si una persona nueva no podría usar la herramienta solo con su descripción, el modelo tampoco.

Errores, reintentos y estados muertos

No todos los errores merecen un reintento. Mezclarlos es la causa más común de bucles caros.

• Transitorios: timeout, límite de peticiones, servicio caído. Reintenta con espera creciente y un máximo de dos o tres intentos.
• Deterministas: datos inválidos, permiso denegado, recurso inexistente. Reintentar con la misma entrada da el mismo resultado. Corrige la entrada o escala.
• Semánticos: la herramienta responde bien pero con el dato equivocado. Ningún reintento lo arregla; hace falta una verificación cruzada o una persona.

Detecta bucles con una regla simple: misma herramienta y mismos argumentos dos veces seguidas, se detiene. Y define estados terminales desde el primer día: resuelto, escalado, abandonado. Un agente sin final definido no termina: consume presupuesto hasta que alguien lo apaga.

Cuando escales a una persona, entrega el contexto, no la transcripción: qué intentó, qué falló y qué decisión falta. Un escalado con resumen se resuelve en un minuto; uno con veinte turnos de historial, en diez.

Coste y latencia como restricciones de diseño

El presupuesto se define por tarea, no por mes. Pasos máximos, tiempo máximo, llamadas a herramientas y coste por ejecución. Si el agente lo supera, se detiene y escala. Ese límite no es un detalle de infraestructura: es parte del comportamiento.

La latencia también es una decisión de producto. En un chat de soporte, cuarenta segundos es peor que una respuesta incompleta en cuatro, porque el usuario se va. Diseña primero el camino rápido: respuesta directa para los casos frecuentes, agente solo para el residuo que no encaja.

Para el coste, mide por caso resuelto, no por llamada. Un agente que gasta el triple pero resuelve sin intervención puede ser más barato que uno barato que escala la mitad de los tickets. Esa comparación, contra el coste humano actual, es la única que importa.

Evaluar con casos reales

Una demo se evalúa con cinco ejemplos que eligió quien la construyó. Un agente se evalúa con cincuenta casos que eligió el negocio, incluidos los feos: solicitud ambigua, cliente duplicado, dato que falta, usuario enfadado.

Cada caso necesita tres cosas: entrada real, resultado esperado y margen de trayectoria aceptable. No solo si acertó, también cómo llegó.

Métrica | Qué mide | Cuándo mirarla
Éxito de tarea | Si resolvió sin intervención | Cada cambio de prompt o herramienta
Precisión de herramientas | Si llamó a la correcta con los argumentos correctos | Al añadir o renombrar herramientas
Pasos por caso | Si el camino es razonable o da vueltas | Semanal
Tasa de escalado | Cuánto trabajo devuelve a personas | Diario
Coste por resuelto | Viabilidad económica | Mensual
p95 de latencia | Experiencia real, no promedio | Semanal

Guarda los casos como suite de regresión. Antes de cambiar una descripción de herramienta, córrela. La mayoría de las regresiones no vienen de un modelo nuevo: vienen de una herramienta que alguien "mejoró" sin avisar. Incluye también casos donde lo correcto es no responder o escalar.

Observabilidad: trazas antes que dashboards

El log de la respuesta final no sirve para depurar. Necesitas la traza completa: entrada, plan, cada llamada con sus argumentos, el resultado, los tokens, la latencia y el estado final.

Ata la traza a un identificador de negocio: ticket, pedido, cliente. Así, cuando alguien pregunte por qué se respondió eso, no buscas por hora.

• Redacta datos personales antes de guardar. La traza no es una excusa para acumular conversaciones.
• Muestrea trazas completas y agrega métricas. Guardar todo sin muestreo se vuelve caro y lento de consultar.
• Alerta sobre escalados, bucles detectados, tasa de error de herramientas y coste por caso resuelto.
• Reproducir una traza contra una versión nueva es la herramienta de depuración más rentable que puedes construir.

Un agente no se define por lo que puede hacer, sino por lo que se niega a hacer.

Checklist de 8 puntos antes de desplegar

1. Alcance en una frase, con una lista de casos fuera de alcance y qué responder en cada uno.
2. Herramientas con esquema cerrado, permisos mínimos y errores que indiquen el siguiente paso.
3. Estado serializable y estados terminales definidos: resuelto, escalado, abandonado.
4. Presupuesto máximo de pasos, tiempo y coste por ejecución, con corte automático.
5. Reintentos solo para errores transitorios, con tope, espera creciente y detección de bucles.
6. Al menos cincuenta casos reales con criterio de éxito y suite de regresión ejecutable.
7. Trazas con identificador de negocio, redacción de datos personales y capacidad de reproducción.
8. Métrica de negocio por caso resuelto: coste, latencia y tasa de escalado comparados con el proceso actual.

Si no puedes completar seis de estos ocho puntos, no tienes un agente listo para producción. Tienes una demo con buenos modales.