Un agente autónomo quebró a su operador mientras escaneaba la red DN42. No falló, no alucinó, no se colgó. Simplemente siguió ejecutando un bucle, obteniendo resultados, ajustando y repitiendo. Nada en su mundo le dijo que seguir adelante costaba dinero. El costo vivía en un dashboard, y los dashboards son para humanos. Los agentes no miran dashboards, y aunque pegues un número en el prompt del sistema, eso es una sugerencia, no una restricción.
La lección es contundente para cualquiera que despliegue agentes en producción, especialmente en América Latina, donde los presupuestos de nube y API son ajustados y un error de este tipo puede liquidar el proyecto. La solución no es un panel de control más sofisticado, sino un límite de gasto duro dentro del wrapper de herramientas que el agente llama, implementado como una precondición que hace fallar la llamada tal como lo haría un error HTTP 403.
El problema: el costo no es una restricción para el agente
El caso del agente que escaneaba DN42 es paradigmático. El agente ejecutaba un bucle de escaneo, probablemente con llamadas HTTP y comandos de shell, y cada iteración generaba un costo. Pero el agente no tenía forma de saberlo. El presupuesto estaba en un dashboard, una herramienta pasiva que requiere interpretación humana. Los agentes no leen dashboards; ejecutan acciones basadas en su prompt y en las respuestas de las herramientas.
Incluso si se incluye una frase como “tienes $3.40 restantes” en el prompt, el modelo puede ignorarla o malinterpretarla. El modelo no conoce los precios de egreso, no sabe que un endpoint cobra por solicitud en lugar de por token, y no tiene idea de que un escaneo es barato por llamada pero catastrófico por mil llamadas. La estimación del modelo será siempre optimista y subestimará el gasto real.
La solución: un límite duro en el wrapper de herramientas
El lugar obvio para poner una verificación de presupuesto es el bucle del agente: antes de cada paso, verificar el presupuesto restante y detenerse si se agotó. Eso funciona hasta que aparecen subagentes, llamadas paralelas a herramientas o políticas de reintento, y entonces deja de funcionar de maneras difíciles de detectar.
El wrapper es mejor porque es el único punto de estrangulamiento por el que pasan todos los efectos secundarios: cada solicitud HTTP, cada comando de shell, cada llamada al modelo. Si puede gastar dinero, pasa por el wrapper. Si no pasa por el wrapper, no debería existir en la lista de herramientas.
Tres claves para un límite efectivo
- La verificación se ejecuta antes del despacho. La contabilidad posterior solo te dice cuánto ya perdiste; es una autopsia, no una barandilla.
- Reserva y luego liquida. Si diez subagentes paralelos leen “restante > 0” y todos pasan, has reventado el límite por 10x. Reserva la estimación por adelantado y liquida al valor real después. La reserva es lo que hace real el límite bajo concurrencia.
- El error tiene forma de 403, no de 500. La lógica de reintento del agente casi con seguridad trata los errores de herramientas como transitorios, lo cual es sensato para fallos de red. Pero un error de presupuesto no es transitorio. Si parece reintentable, se produce una tormenta de reintentos que quema tokens discutiendo con una pared. Márcalo como terminal, dilo en el mensaje y dale al modelo una salida legal: resumir y detenerse. Un agente sin parada elegante se agitará, y agitarse también cuesta dinero.
La estimación debe venir de una tabla, no del modelo
El modelo subestimará. No conoce los precios de egreso, no sabe que un endpoint factura por solicitud en lugar de por token, y no tiene idea de que un escaneo es barato por llamada y catastrófico por mil llamadas. Por eso la estimación debe provenir de una tabla escrita por el desarrollador, indexada por nombre de herramienta y forma de los argumentos. Una estimación aproximada es suficiente: solicitudes × precio unitario, tokens × precio por 1k, segundos × costo por hora de GPU. Lo importante no es la precisión, sino que el número exista antes de la llamada en lugar de después.
Esto también explica por qué un único medidor global de “tokens gastados” es la abstracción incorrecta. El caso DN42 era una tarea de escaneo; el costo probablemente lo impulsaban las solicitudes y el ancho de banda, no los tokens de finalización. Diferentes herramientas gastan diferentes unidades. Un solo medidor no puede verlos todos.
El número en el prompt es el volante, no el freno
La verificación dura es la barandilla. El número en el prompt es el volante. Ambos, no uno u otro. Incluye el presupuesto restante en el contexto de la tarea en cada turno: “Te quedan $3.40 para esta tarea”. Un agente que puede ver el número a veces elegirá el camino más barato por sí mismo: menos páginas, un modelo más pequeño, un resultado en caché. Un agente que no puede verlo siempre elegirá el camino exhaustivo, porque desde su perspectiva lo exhaustivo es gratis. Pero nunca dejes que la aritmética del modelo sea la verificación. Es una entrada para su planificación, no un hecho sobre tu cuenta.
Configuración práctica y registro
Si alcanzar tu techo de gasto es un incidente, el techo está demasiado alto. Configúralo en el nivel en el que te encogerías de hombros. Un techo por tarea, no solo por día: un presupuesto diario permite que una tarea descontrolada se coma todo antes de las 9 a.m. y luego estarás depurando una “caída misteriosa” que en realidad es tu propia barandilla funcionando correctamente.
Registra cada llamada a herramienta con argumentos y costo, antes de que lo necesites. El informe de error que recibirás será “hizo algo raro ayer”, y lo único que te salvará es una fila por llamada con el precio adjunto.
Conclusión: menos libertad, más fiabilidad
El agente de DN42 no necesitaba mejor razonamiento. Necesitaba un número con el que no pudiera discutir. Cada problema de fiabilidad que he corregido este año se reduce a eliminar libertad, no a añadir inteligencia, y el control de costos es solo otro de esos problemas. No estás haciendo que el agente sea más inteligente con el dinero. Estás haciendo imposible que gaste dinero que no tiene, y se lo dices en un lenguaje que ya entiende: una llamada fallida. Dale una entrada de costo. Haz que falle como un 403. Luego ve a mirar tu dashboard, que ahora es decoración.