Un agente de IA no es un chatbot con mejor prompt

Casi todos los proyectos de "agente" que revisamos empiezan igual: un modelo, un prompt largo y una lista de instrucciones que crece cada semana. Funciona en la demo y falla en cuanto entra un caso que nadie escribió.

El salto de calidad no viene de escribir mejor el prompt. Viene de tratar al agente como un sistema: entradas, herramientas, estado y una condición de salida verificable.

El bucle, no el prompt

Un chatbot responde una vez. Un agente decide, actúa, observa el resultado y vuelve a decidir. Ese bucle es donde vive el valor y también donde se acumulan los fallos.

while not done and steps < MAX_STEPS:
    action = model.decide(state, tools)
    result = tools.run(action)      # validado
    state  = state.append(result)
    done   = check_exit(state)      # criterio explícito

Tres cosas de este esqueleto importan más que el modelo que elijas: el límite de pasos, la validación de la herramienta y la función de salida. Cambiar de modelo mejora los márgenes; que falte cualquiera de esas tres cosas rompe el sistema.

Herramientas con contrato

Cada herramienta que expones al modelo es una superficie de error. Aplicamos las mismas reglas que a una API pública:

• Esquema estricto. Si el argumento no valida, no se ejecuta y el error vuelve al modelo en texto legible, para que pueda corregirse solo.
• Idempotencia donde se pueda. Reintentar no debería duplicar un pedido ni enviar dos correos.
• Permisos por herramienta. Leer es barato; escribir requiere confirmación explícita.

Si una herramienta puede borrar datos, el agente no debería poder llamarla solo.

Cuándo parar

La pregunta más útil en cualquier revisión de diseño: ¿cómo sabe este agente que ha terminado? Si la respuesta es "cuando el modelo dice que sí", no hay criterio de parada, hay una opinión.

Los criterios que mejor funcionan son verificables fuera del modelo: el fichero existe, la consulta devuelve filas, el total cuadra, el test pasa.

Una regla práctica: si no puedes escribir la condición de éxito en una línea de código, el agente todavía no está listo para producción.

Observabilidad

Guardamos cada paso: entrada, herramienta llamada, argumentos, resultado y coste. Sin esa traza, depurar un agente es adivinar. Con ella, la mayoría de los fallos se identifican leyendo tres líneas.

Lo que medimos:

• Pasos por tarea completada, y su distribución — no la media, que esconde justo los casos que fallan.
• Tasa de llamadas fallidas por esquema inválido.
• Coste por tarea, no por token. El token no le importa a nadie del negocio.

Qué haríamos distinto

Empezar con menos herramientas. En los primeros proyectos dimos al agente doce; con cuatro bien definidas resolvía el mismo trabajo en la mitad de pasos y con bastante menos ruido.

Y escribir las evaluaciones antes que el prompt. Cuesta un día más al principio y ahorra semanas de ajustes a ciegas, porque te deja comparar dos versiones con datos en vez de con sensaciones.

¿Tienes un proceso donde un agente tendría que decidir y actuar? Cuéntanoslo y te decimos si el bucle se sostiene.