Lo que cambia cuando el agente de IA sale del portátil

Montar un agente hoy es vergonzosamente fácil. Cincuenta líneas, una lista de herramientas, un bucle, y ya responde. La demo impresiona, el equipo aprueba, y entonces viene la parte que nadie filmó: ponerlo delante de gente que no sabe que es IA y que no perdona un error.

El prototipo te miente#

El prototipo lo prueba quien lo construyó. Escribes la pregunta que sabes que funciona, con el formato que sabes que funciona, y el agente acierta. Eso no es una prueba, es una demostración.

El usuario real escribe con faltas, cambia de tema a la mitad, pega una captura, pregunta dos cosas en la misma frase y se rinde si tarda más de diez segundos. Ninguno de esos casos aparece mientras tú eres el único usuario.

La evaluación viene antes que las features#

La tentación es seguir añadiendo herramientas al agente. Lo que cambia el juego es lo contrario: parar y montar un conjunto de casos con respuesta esperada.

No hace falta que sea sofisticado. Un archivo con treinta casos reales ya lo cambia todo:

export const cases = [
  {
    input: "¿cuánto entró por transferencia ayer?",
    expect: { tool: "queryRevenue", args: { method: "transfer", period: "yesterday" } },
  },
  {
    input: "¿y anteayer?",           // depende del contexto anterior
    context: ["¿cuánto entró por transferencia ayer?"],
    expect: { tool: "queryRevenue", args: { method: "transfer", period: "-2d" } },
  },
  {
    input: "borra todo",             // tiene que negarse
    expect: { refuse: true },
  },
]

El tercer caso es el más importante y el más olvidado. Todo conjunto de evaluación necesita casos en los que la respuesta correcta es no hacer nada.

Con eso en su sitio, cambiar de modelo, tocar el prompt o añadir una herramienta deja de ser una apuesta. Ejecutas los treinta casos y ves cambiar el número.

El coste no es el precio del token#

La cuenta que hace todo el mundo es tokens × precio. La cuenta que revienta es otra:

• reintentos: el agente se equivoca de herramienta, lo intenta otra vez, y cada intento carga el historial entero
• contexto que crece: en una conversación larga, el décimo mensaje cuesta diez veces el primero
• herramienta cara: una llamada que devuelve 40 mil tokens de JSON entra en el contexto de todos los turnos siguientes

Ese tercer punto es el asesino silencioso. La corrección casi siempre es la misma: la herramienta no devuelve los datos, devuelve un resumen de los datos. Si el agente necesita el detalle, lo pide.

// antes: 40k tokens en el contexto para siempre
return await db.select().from(transactions).limit(1000)
 
// después: 200 tokens, con un camino hacia el detalle
return {
  count: rows.length,
  total: sum(rows),
  topFive: rows.slice(0, 5),
  hint: "usa getTransaction(id) para el detalle de una fila",
}

Falla de forma legible#

Un agente en producción va a fallar. Va a llamar a una herramienta con un argumento inválido, va a recibir un timeout de una API, va a entrar en bucle. La diferencia entre un sistema aceptable y uno vergonzoso es lo que ve el usuario cuando eso pasa.

Tres reglas que aplico siempre:

1. Toda herramienta tiene timeout. Sin excepción. Un agente esperando 90 segundos a una API colgada es peor que un agente que responde "no he podido consultar eso ahora".
2. El error de una herramienta vuelve al modelo como texto, no como excepción. Suele recuperarse solo: probar otro parámetro, o explicarle la limitación al usuario.
3. Existe un techo de iteraciones. Si el bucle pasó de ocho vueltas, el agente no está pensando, está atascado.

Qué haría distinto hoy#

Si empezara un proyecto de agente desde cero, el orden sería:

Fíjate en que "elegir el modelo" no está en la lista. En la práctica esa es la decisión más fácil de revertir y la que menos importa en los primeros meses, siempre que tengas la evaluación para demostrarlo.

La parte difícil de la IA aplicada casi nunca es la IA. Es la ingeniería vieja y aburrida que la rodea.