Un agente autónomo llevó a la quiebra a su operador mientras escaneaba la red DN42. No se averió. No alucinó. No se cayó. Simplemente siguió ejecutando su bucle, obteniendo resultados, ajustando y repitiendo, porque nada en su mundo le dijo que seguir adelante cuesta dinero. Para quienes construyen sistemas de inteligencia artificial en México y América Latina, este caso es una advertencia concreta: el control de gasto no puede vivir en un tablero que solo miran los humanos.
El problema: los agentes no leen paneles de control
El costo de operar un agente suele registrarse en un panel o dashboard. Esos paneles están hechos para personas. Los agentes no los consultan, y aunque se les pegue una cifra en el mensaje de contexto, esa cifra es una sugerencia, no una restricción. Un número en el texto no detiene una llamada; una regla dura sí.
El caso de DN42 es revelador porque el agente no cometió un error de razonamiento. Hizo exactamente lo que se le pidió: escanear, iterar, ajustar. El fallo estaba en el diseño del sistema, que no tenía forma de negarse a gastar cuando ya no había presupuesto.
La solución: el límite dentro del envoltorio de herramientas
La recomendación central es colocar el techo de gasto dentro del envoltorio (wrapper) de herramientas que el agente invoca, como una precondición dura que hace fallar la llamada igual que falla un error 403. No una métrica. No una alerta. Una negativa.
El lugar obvio para poner una verificación de presupuesto es el bucle del agente: antes de cada paso, revisar el saldo 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 formas difíciles de detectar.
El envoltorio es mejor porque es el único punto de estrangulamiento por donde pasan todos los efectos secundarios: cada solicitud HTTP, cada comando de shell, cada llamada al modelo. Si algo puede gastar dinero, pasa por el envoltorio. Si no pasa por ahí, no debería existir en la lista de herramientas.
Tres detalles que hacen la diferencia
- La verificación corre antes del despacho. La contabilidad posterior solo dice cuánto se perdió ya. Es una autopsia, no una barrera de protección.
- Se reserva y luego se liquida. Si diez subagentes paralelos leen cada uno que el saldo es mayor que cero y todos pasan, el techo se rebasa diez veces. Hay que reservar la estimación por adelantado y liquidar contra el costo real después. La reserva es lo que hace real el techo bajo concurrencia.
- El error se modela como un 403, no como un 500. La lógica de reintentos del agente casi siempre trata los errores de herramienta como transitorios, porque las redes fallan. Un error de presupuesto no es transitorio. Si parece reintentable, se produce una tormenta de reintentos que quema tokens discutiendo con una pared. Hay que marcarlo como terminal, decirlo en el mensaje y darle al modelo una salida legal: resumir y detenerse. Un agente sin parada elegante se agita, y agitarse también cuesta dinero.
El modelo subestimará el costo
El modelo no conoce el precio de salida de tu red, no sabe que cierto punto de acceso cobra por solicitud y no por token, y no tiene idea de que un escaneo es barato por llamada y catastrófico por cada mil llamadas. Por eso la estimación debe venir de una tabla escrita por el operador, indexada por nombre de herramienta y forma de los argumentos. Basta con que sea aproximada: solicitudes por precio unitario, tokens por precio por mil, segundos por costo de GPU entre 3600. Lo importante no es la precisión, sino que el número exista antes de la llamada y no después.
Esto también explica por qué un medidor global único de “tokens gastados” es la abstracción equivocada. En el caso DN42, la tarea era de escaneo y el motor de costo era casi seguramente solicitudes y ancho de banda, no tokens de finalización. Distintas herramientas gastan distintas unidades. Un solo medidor no puede verlas todas.
La verificación dura y el volante
La verificación dura es la barrera de protección; el número en el mensaje es el volante. Ambos, no uno u otro. Conviene poner el presupuesto restante en el contexto de la tarea en cada turno: “Te quedan 3.40 dólares para esta tarea”. Un agente que ve la cifra a veces elegirá por su cuenta el camino más barato: menos páginas, un modelo más pequeño, un resultado en caché. Un agente que no la ve siempre elegirá el camino exhaustivo, porque desde su posición lo exhaustivo es gratis.
Pero nunca hay que dejar que la aritmética del propio modelo sea la verificación. Es un insumo para su planeación, no un hecho sobre tu cuenta.
Buenas prácticas de operación
Si tocar el techo de presupuesto se considera un incidente, el techo está demasiado alto. Conviene fijarlo en un nivel que se pueda encogerse de hombros. Y debe haber un techo por tarea, no solo por día: un presupuesto diario permite que una sola tarea desbocada se coma todo a las nueve de la mañana, y luego se depura una “caída misteriosa” que en realidad es tu propia barrera funcionando correctamente.
También hay que registrar cada llamada a herramienta con sus argumentos y su costo antes de necesitarlo. El reporte de error que llegará será “hizo algo raro ayer”, y lo único que salva es tener una fila por llamada con el precio adjunto.
Lo que este caso enseña sobre confiabilidad
El agente de DN42 no necesitaba mejor razonamiento. Necesitaba un número con el que no pudiera discutir. Muchos de los problemas de confiabilidad que se corrigen se reducen a quitar libertad, no a añadir inteligencia. El control de costos es otro de esos casos: no se trata de hacer al agente más inteligente respecto al dinero, sino de hacer imposible que gaste dinero que no tiene, y decírselo en un lenguaje que ya entiende: una llamada fallida.
Para el ecosistema tecnológico de la región, donde los equipos pequeños experimentan con agentes autónomos y presupuestos ajustados, la lección es directa: dale al agente un insumo de costo, haz que falle como un 403 y deja el panel de control como lo que es ahora, decoración.