Agentes LLM: presupuesto para cada herramienta

Cada agente basado en un modelo de lenguaje profundo (LLM) puede parecer rápidamente funcional durante una demostración. Sin embargo, en un entorno de producción, la tarea puede requerir llamar a diversas herramientas como APIs, esperar respuestas de correos electrónicos de verificación o pedir una segunda validación. El desafío principal radica en asignar un presupuesto a cada llamada.

En la práctica, los automatismos tienden a tratar el presupuesto como un contrato visible. El agente recibe un límite de tiempo, el número máximo de llamadas a herramientas y un coste estimado máximo. El adaptador de herramientas decide cómo aplicar este presupuesto. Esto asegura que un modelo pueda razonar sobre una tarea sin tener permiso implícito para consumir recursos sin límite.

Sin embargo, el problema surge cuando no se cuantifica el presupuesto para cada herramienta utilizada. Por ejemplo, imagina un agente que crea una cuenta de prueba y espera un mensaje. El proceso podría verse así: modelo → crear identidad → esperar inbox → leer código → confirmar resultado. Si el inbox tarda en responder, el modelo puede volver a enviar la solicitud.

Si el servicio devuelve un error ambiguo, el modelo puede reintentar. Un caso como un correo electrónico falso en entrada de usuario o un dominio mal escrito como temp gamil com no debe aumentar el costo de las llamadas.

Normalmente, tres síntomas indican que falta un presupuesto para cada herramienta: la latencia total aumenta sin que cada llamada individual sea cuesta algo, los reintentos ocultan un fallo de contrato y duplican efectos secundarios, y no se comprende si el coste proviene del modelo, del proveedor externo o del polling.

Para abordar esto, es fundamental asignar un límite global al presupuesto, pero también límites locales para cada llamada a herramientas. Por ejemplo, un tiempo de 60 segundos para toda la tarea no especifica cómo repartir esos segundos entre una consulta y cinco esperas.

Para gestionar los recursos, se puede definir un contrato mínimo con tres elementos clave: el tiempo máximo permitido en milisegundos, el número máximo de llamadas a herramientas y el coste máximo estimado en moneda digital. Además, cada adaptador de herramientas puede decidir rechazar una llamada cuando ya ha sido gastado el presupuesto.

El adaptador también debe devolver un resultado explícito, como 'ok', 'timeout', 'budget_exhausted' o 'unknown'. Esto es crucial para operaciones que tienen efectos secundarios. Por ejemplo, un timeout no prueba que el servidor no haya actuado.

Para facilitar la depuración, es recomendable guardar un recibo por intento, sin copiar toda el prompt. Este recibo puede incluir el run_id, el id de la llamada a herramientas, la herramienta utilizada, el intento, el tiempo restante, el estado, la duración y un hash de la entrada. Con este dato, se pueden responder preguntas operativas como si el tiempo se agotó antes de consultar, cuántos intentos se usaron para polling, qué herramienta consumió el presupuesto, etc.

La implementación del diseño puede dividirse en cuatro checkpoints: el límite para rechazar llamadas cuando el tiempo restante llega a cero, la medición de inicio, fin, intento y presupuesto restante, la clasificación de errores reintentables, terminales y desconocidos, y la prueba simulando diferentes escenarios como latencia, respuestas tardías, entrada inválida o duplicaciones.

En resumen, un agente confiable es el que sabe cuánto puede gastar, qué evidencia dejar y cuándo detenerse. Asignar presupuestos a cada llamada a herramienta hace que el flujo sea más predecible y permite ajustar el modelo sin perder control del sistema.