Presupuestos de llamadas externas que detienen los bucles de los agentes

Los agentes autónomos no necesitan acceso ilimitado a servicios externos para resultar útiles. Necesitan una cantidad de permiso definida para intentar, esperar, reintentar y gastar antes de devolver el trabajo. Sin ese límite, una pequeña ambigüedad, como un resultado de búsqueda vacío o un trabajo retrasado, puede convertirse en cientos de solicitudes, efectos secundarios duplicados y una factura que nadie esperaba.

Un presupuesto de llamadas externas es un contrato de ejecución para una sola ejecución del agente. Limita los intentos de solicitud, el tiempo transcurrido y la exposición económica, y obliga a detenerse de forma visible cuando se agota cualquiera de esos límites. Trátalo como un límite operativo, no como una sugerencia en el prompt del agente. Los prompts se reinterpretan con facilidad cuando el modelo intenta terminar una tarea; el control debe estar fuera del modelo.

Un presupuesto debe contar por separado los intentos, el tiempo y el dinero

Un único límite no puede cubrir todas las formas en que un agente consume recursos. El número de solicitudes detecta los bucles. El tiempo transcurrido detecta las consultas lentas y las esperas entre reintentos. El límite de gasto detecta un número reducido de acciones caras. Cada medida corresponde a un modo de fallo distinto y cualquiera de ellas puede terminar la ejecución aunque las otras dos todavía tengan margen.

Cuenta los intentos, no las respuestas correctas. Una solicitud intentada que agota el tiempo quizá haya llegado al proveedor. Ha consumido un socket, trabajo del proveedor y, a menudo, una entrada en una API facturada por uso. Si cuentas solo los éxitos, un agente puede hacer infinitas solicitudes fallidas mientras busca una respuesta que le guste.

Registra al menos estos valores en cada ejecución:

• attempts_used y attempts_remaining, incluidos los reintentos y las redirecciones que generan una nueva solicitud externa
• deadline_at, usando un reloj monotónico para medir la duración transcurrida en lugar de la hora de pared
• reserved_spend y settled_spend, en la unidad práctica más pequeña de facturación del proveedor
• side_effect_attempts, un contador separado para acciones que escriben, envían, crean o compran
• budget_stop_reason, que registra el primer límite que impidió continuar

No mezcles el número de solicitudes con el gasto asignando un precio inventado a cada llamada. Una consulta de metadatos y un endpoint de generación de modelos pueden costar una solicitud cada uno, aunque sus facturas sean muy distintas. A la inversa, una API puede no informar de ningún precio y aun así crear un recurso de nube facturable. Usa un límite de solicitudes incluso cuando exista una estimación de coste.

Un presupuesto inicial razonable para un agente que recopila datos de un conjunto conocido de API podría permitir 40 intentos totales, 10 minutos de ejecución y una pequeña reserva fija. Un agente de despliegue quizá necesite menos solicitudes, pero un límite más estricto para los efectos secundarios. Un agente de investigación que sigue URL descubiertas necesita un alcance accesible mucho menor que el que su autor propondrá al principio. Son hipótesis iniciales, no valores universales. Mide las ejecuciones normales y fija límites lo bastante ajustados para interrumpir el comportamiento anómalo antes de que se convierta en un trabajo de limpieza.

El presupuesto pertenece a una ejecución, no al proceso del modelo durante todo el día. Si el agente recibe una tarea nueva, obtiene un identificador de ejecución nuevo y una asignación explícita nueva. Un contador diario compartido oculta la ejecución cara entre el trabajo normal. También permite que una tarea consuma la capacidad destinada a otra.

La asignación debe reservarse antes de la primera llamada costosa

Los límites de gasto fallan cuando el sistema conoce el precio solo después de comprar algo. Reserva el cargo máximo razonable antes de la llamada, reduce de inmediato el presupuesto restante y concilia después cuando el proveedor devuelva el uso real. Si la reserva no cabe, deniega la llamada antes de que salga de tu perímetro.

Imagina un agente que puede crear una compilación alojada. La solicitud del proveedor acepta una clase de máquina, una región, un tiempo de espera y un tamaño de artefacto, pero el cargo exacto aparece al terminar. La pasarela del agente necesita una tabla de precios o una estimación prudente. No necesita una contabilidad perfecta para tomar una decisión segura.

Un registro de reserva podría tener este aspecto:

{
  "run_id": "run_7c1f",
  "budget": {
    "attempts_remaining": 18,
    "deadline_at": "2025-04-21T14:42:00Z",
    "spend_remaining_cents": 1200
  },
  "reservation": {
    "action": "create_build",
    "maximum_cents": 850,
    "provider_reference": "build-request-41"
  },
  "decision": "allow"
}

Después de esa reserva, a la ejecución le quedan 350 centavos para cualquier otra acción. Si el cargo real se liquida en 620 centavos, libera 230. Si se liquida en 910, registra el exceso, deniega los gastos posteriores e investiga por qué falló la estimación. No permitas que un agente tome prestado libremente de un presupuesto futuro porque la cifra final resultó incómoda.

Algunos proveedores muestran un precio en la solicitud o devuelven una estimación de uso antes de comenzar el trabajo. Úsala. Otros no lo hacen. En esos servicios, clasifica las acciones según el riesgo. Permite una lectura barata dentro del presupuesto normal de solicitudes. Exige aprobación explícita para una acción que pueda crear un recurso sin límite, enviar mensajes de pago, realizar un pedido o activar un trabajo cuyo coste no puedas acotar.

Los equipos suelen rechazar las reservas porque las estimaciones son imperfectas. Ese argumento confunde la precisión contable con el control. Una puerta cortafuegos no necesita calcular el calor exacto del incendio antes de cerrarse. Una reserva conservadora puede rechazar una tarea que habría cabido, pero el agente puede solicitar una asignación mayor con contexto. Es preferible a descubrir un cargo sin límite después de que el agente haya desaparecido.

Mantén los créditos del proveedor y las cuotas de toda la organización fuera del presupuesto de la ejecución. Son redes de seguridad, no sustitutos. Una cuota mensual normalmente permite que una sola ejecución consuma mucho más de lo que merece su tarea.

Los reintentos necesitan una asignación menor que los primeros intentos

Los reintentos deben ser poco frecuentes, estar limitados y clasificarse según si repetir la solicitud puede repetir el efecto secundario. Una instrucción genérica para reintentar los errores es la forma en que los agentes convierten una interrupción temporal en un patrón de tráfico costoso.

RFC 9110 define métodos idempotentes como GET, PUT y DELETE según el efecto previsto en el servidor. También indica que un cliente no debería reintentar automáticamente una solicitud no idempotente salvo que sepa que repetirla es seguro. Esta salvedad importa más con los agentes que con el código de aplicación normal: el agente puede modificar los datos entre intentos, decidir que una respuesta anterior estaba incompleta y emitir lo que parece una solicitud nueva.

RFC 6585 define HTTP 429, Too Many Requests, e indica que una respuesta puede incluir Retry-After. Respeta ese encabezado cuando esté presente. No lo interpretes como permiso para dormir hasta que expire y continuar para siempre. El reintento sigue consumiendo el presupuesto de tiempo de la ejecución y quizá la tarea original ya no justifique esperar.

Usa un registro de reintentos que responda a cuatro preguntas antes de cada repetición: qué falló, si la acción remota pudo producirse, cuánto tiempo esperar y qué presupuesto pagará el siguiente intento. Una política práctica sería:

request_classes:
  read:
    max_attempts: 3
    retry_on: [408, 429, 502, 503, 504]
    backoff_seconds: [2, 8]
  idempotent_write:
    max_attempts: 2
    require_idempotency_token: true
    retry_on: [408, 429, 503]
  non_idempotent_write:
    max_attempts: 1
    retry_on: []

Esta política evita un fallo conocido. Un agente envía POST /invoices y pierde la conexión antes de recibir respuesta. Un reintento descuidado puede crear una segunda factura. Un token de idempotencia permite que un proveedor colaborador reconozca el duplicado, pero solo si el agente reutiliza el mismo token y exactamente la misma operación lógica. Si cambia el importe, el cliente o el token en el segundo intento, la protección deja de aplicarse.

Para una acción no idempotente, prefiere una consulta de estado mediante un identificador de operación generado por el cliente. Si el proveedor no admite idempotencia ni recuperación del estado, trata el tiempo de espera ambiguo como un caso que requiere revisión humana. Parece más lento que reintentar automáticamente hasta que alguien tenga que revertir transferencias, pedidos o mensajes duplicados.

La aleatoriedad importa cuando muchos agentes reciben la misma interrupción. Usa esperas de retroceso aleatorias para que no reintenten todos al mismo tiempo. Mantén el calendario lo bastante corto para que el plazo de la ejecución siga teniendo sentido. Un retroceso exponencial de seis horas puede proteger al proveedor y mantener abierta una sesión del agente mucho después de que la tarea haya dejado de importar.

Los bucles de consulta necesitan su propio límite

Un agente que espera trabajo asíncrono debe recibir una asignación explícita para las consultas, porque los límites normales de solicitudes ocultan el patrón hasta que ya resulta costoso. Consultar tiene un uso legítimo, pero debe contar con un intervalo, un número máximo de comprobaciones y un plazo propio de la operación.

La versión problemática se reconoce fácilmente en los registros:

14:00:03 POST /exports                 202 accepted
14:00:04 GET  /exports/ea91            202 running
14:00:05 GET  /exports/ea91            202 running
14:00:06 GET  /exports/ea91            202 running
...
14:11:58 GET  /exports/ea91            202 running

El agente ha interpretado «sigue en ejecución» como una instrucción para preguntar otra vez. Eso no es perseverancia. Es la ausencia de una política.

Parte de las indicaciones documentadas por el proveedor. Si un endpoint devuelve Retry-After, respétalo dentro del plazo restante. Si devuelve una hora estimada de finalización, no consultes antes de ese momento. Si ofrece un webhook o una devolución de llamada, úsalo en lugar de mantener abierta la ejecución del agente. Una devolución de llamada externa puede reanudar más tarde un flujo controlado; no debe resucitar una ejecución caducada con su autoridad anterior.

Un presupuesto de consultas también debe distinguir el estado del trabajo de un fallo de transporte. 202 running indica que el trabajo existe. Un tiempo de espera no dice si la solicitud de estado llegó. No uses la misma asignación de reintentos para ambos casos. El primero puede esperar hasta la próxima comprobación programada. El segundo puede justificar un reintento, sujeto al límite normal.

Define una acción terminal para una asignación de consultas agotada: registra el último estado conocido, conserva el identificador de la operación remota y devuelve una instrucción para reanudar. No canceles automáticamente salvo que la tarea original indique que la cancelación es segura. Algunos trabajos dejan un resultado utilizable aunque el agente deje de esperar, y algunas solicitudes de cancelación tienen sus propios efectos secundarios.

Este diseño hace visible el trabajo retrasado. «La exportación sigue en ejecución después de seis comprobaciones; la operación ea91 puede comprobarse más tarde» es una entrega útil. «Agente completado» después de un bucle oculto en segundo plano no lo es.

El plazo debe incluir esperas, herramientas y tiempo en cola

El plazo de una ejecución debe medir todo el periodo durante el que el agente puede provocar trabajo externo. Debe incluir el razonamiento del modelo entre llamadas, el sueño de los reintentos, la ejecución de herramientas locales, la espera en cola, los bloqueos de DNS y el tiempo de espera de una aprobación. Un temporizador colocado únicamente alrededor del cliente HTTP deja grandes huecos en los que el bucle puede continuar.

Usa un temporizador monotónico transcurrido para aplicar este límite. Los relojes de pared pueden saltar cuando un portátil entra en suspensión, se reanuda o recibe una corrección horaria. Guarda marcas de tiempo de pared para los registros de auditoría, pero calcula la caducidad a partir de una duración transcurrida que no pueda retroceder.

Pasa el tiempo restante a cada operación. Si quedan 40 segundos de ejecución, no debe iniciar una solicitud HTTP con un tiempo de espera de cliente de 90 segundos ni ejecutar un comando SSH sin ningún límite. La operación secundaria recibe el menor valor entre su límite local y la duración restante de la ejecución.

remaining = run_deadline_monotonic - now_monotonic
if remaining \u003c= 0:
    deny("run_deadline_exhausted")
else:
    operation_timeout = min(remaining, endpoint_timeout)
    execute(operation_timeout)

Trata las esperas de aprobación con cuidado. Una persona puede responder en cinco minutos, pero a la ejecución del agente quizá solo le queden 30 segundos. Cuando llegue la aprobación después de la caducidad, deniega la acción y muestra el motivo. Permitir que la aprobación reactive una ejecución caducada crea un agujero: el agente puede poner en cola cualquier cantidad de acciones caras antes de su plazo y ejecutarlas después mientras alguien pulsa las tarjetas.

Las tareas largas necesitan otra estructura. Divídelas en puntos de control con presupuestos nuevos y una transición de estado registrada. Por ejemplo, un agente puede enviar una exportación en una ejecución y, en otra posterior, inspeccionar la exportación terminada y decidir qué hacer con ella. Cada ejecución recibe un propósito, un conjunto pequeño de autoridades y una hora clara de finalización. Es menos mágico que una sesión inmortal de agente y, precisamente por eso, más fácil de auditar.

Los límites de alcance evitan que el agente gaste el presupuesto en el lugar equivocado

Un presupuesto responde a cuánto trabajo externo puede realizar una ejecución. El alcance responde a dónde y qué puede tocar. Sin alcance, un agente puede gastar una asignación perfectamente razonable sondeando hosts no relacionados, siguiendo un enlace envenenado o seleccionando un endpoint costoso que nunca formó parte de la tarea.

Define el alcance en términos concretos: hosts aprobados, identidades de credenciales, métodos HTTP, destinos SSH, rutas o familias de comandos permitidas y tamaño máximo del cuerpo de la solicitud. Mantén la definición lo bastante estrecha para que un revisor pueda entenderla. No intentes escribir un pequeño lenguaje de programación para cada condición posible. Los sistemas de políticas complejos acumulan excepciones hasta que nadie puede predecir su resultado bajo presión.

La diferencia entre un límite de credenciales y un límite presupuestario importa. El límite de credenciales decide si un agente puede usar un secreto para llamar a un servicio. El límite presupuestario decide si esta ejecución puede hacer otra llamada después de obtener ese permiso. Los equipos suelen instalar el primero y asumir que proporciona el segundo. No es así. Un token de API perfectamente protegido todavía puede financiar mil solicitudes innecesarias.

En HTTP, rechaza las redirecciones que salgan del conjunto de hosts aprobados salvo que una persona haya permitido explícitamente el destino. Es fácil pasar por alto las redirecciones porque muchos clientes las siguen automáticamente. Una solicitud que empieza en una URL aprobada puede terminar en otro host, llevar encabezados o consumir presupuesto en un servicio que la tarea nunca nombró.

En SSH, evita dar al agente un shell general solo porque su primer trabajo implique un comando. Restringe el destino y la interfaz de comandos siempre que sea posible. Establece un tiempo de espera y cuenta cada intento de conexión. Un bucle de conexiones fallidas sigue siendo actividad externa aunque nunca llegue a autenticarse.

Separa los alcances de lectura de los de escritura. Una tarea de recopilación de datos puede necesitar muchos endpoints de lectura y ninguna capacidad para crear registros. Una tarea de cambio puede necesitar un endpoint de escritura y una lectura previa estrecha. Esta división hace más útil el presupuesto porque el número de solicitudes por sí solo no distingue la repetición inofensiva de los efectos secundarios repetidos.

Las denegaciones deben dejar pruebas suficientes para reconstruir el bucle

Una detención presupuestaria solo sirve si puedes explicarla después. Registra cada decisión antes de que empiece la llamada externa, registra el resultado cuando termine y registra las denegaciones con el mismo cuidado que las llamadas correctas. De lo contrario, un evento ausente puede parecer una solicitud bloqueada.

Usa un único identificador de ejecución inmutable en los mensajes del modelo, las herramientas locales, las solicitudes HTTP, las conexiones SSH, las aprobaciones y los registros de auditoría. Cada intento externo debe incluir un número de secuencia. Si ocurre un reintento, vincúlalo con la operación lógica original e indica si la acción era idempotente, ambigua o estaba confirmada como ausente.

Un registro de eventos compacto contiene lo necesario para investigar sin almacenar datos sensibles:

{
  "run_id": "run_7c1f",
  "attempt": 17,
  "logical_operation": "fetch_export_status:ea91",
  "channel": "http",
  "destination_class": "approved-export-api",
  "outcome": "denied",
  "reason": "poll_allowance_exhausted",
  "attempts_remaining": 0,
  "elapsed_ms": 598244,
  "reserved_spend_cents": 0
}

No registres por defecto tokens bearer, contraseñas, claves privadas ni cuerpos completos de solicitudes. Una auditoría presupuestaria necesita identificadores, clases, hashes cuando sean útiles y el contexto de la decisión. No necesita otro almacén de secretos lleno de las mismas credenciales que intentabas proteger.

Haz que la secuencia de eventos sea resistente a manipulaciones. Una cadena de hashes da a cada registro una dependencia del anterior, de modo que eliminarlo o modificarlo rompe la verificación. Cuando sea posible, guarda el material de verificación separado del agente activo. Un agente que puede escribir su propio historial no debe poder editar el registro que demuestra que superó el presupuesto.

Sallyport registra tanto las sesiones de los agentes como las llamadas individuales mediante un registro de auditoría cifrado, encadenado mediante hashes y protegido contra escritura. Su comando sp audit verify puede verificar la cadena sin conexión sobre el texto cifrado. Este diseño resulta útil para aplicar presupuestos porque una acción denegada sigue formando parte de las pruebas en lugar de desaparecer como una decisión interna.

La aprobación humana debe reservarse para las excepciones, no para cada lectura

La aprobación humana debe ocuparse de los cambios de consecuencia o alcance que un presupuesto numérico no puede juzgar. No debe convertirse en un sello automático para las llamadas rutinarias. Si una persona ve una tarjeta de aprobación para cada solicitud, aprobará la décima con la misma atención que prestó a la primera.

Pide aprobación cuando una acción cree un nuevo beneficiario, gaste por encima de la reserva, escriba en un sistema de producción, envíe una comunicación visible externamente, cambie el conjunto de destinos aprobados o reanude el trabajo después de un cambio importante en la entrada. La aprobación debe mostrar la acción en lenguaje sencillo, el destino, su impacto presupuestario y la identidad del proceso que la solicita.

No presentes la aprobación como remedio para un presupuesto débil. Una persona distraída puede autorizar una mala acción y una ejecución desatendida quizá nunca reciba respuesta. El presupuesto debe caducar mientras espera la aprobación. La persona puede conceder una asignación nueva para otra ejecución si la tarea sigue mereciendo la pena.

Evita pedir que las personas aprueben «continuar» sin contexto. ¿Continuar qué? ¿Contra qué servicio? ¿Con qué cargo estimado? ¿Cuántas llamadas ha hecho ya la ejecución? Una buena solicitud de aprobación hace visibles esos datos. Una solicitud vaga obliga al revisor a confiar en el resumen del agente, que es precisamente la parte interesada en seguir trabajando.

Existe una división de responsabilidades útil. La pasarela aplica los límites fijos de forma coherente. La persona decide si una acción excepcional tiene suficiente valor para justificar más autoridad. Mantén separadas esas responsabilidades y ninguna tendrá que fingir que resuelve el trabajo de la otra.

El agotamiento del presupuesto debe producir una entrega que pueda reanudarse

Cuando un límite detiene una ejecución, el agente debe devolver un registro breve del estado que permita a una persona o a otra ejecución continuar de forma segura. Un mensaje de error impreciso invita a repetir toda la tarea, lo que repite las llamadas completadas y puede repetir los efectos secundarios.

La entrega necesita el objetivo de la tarea, los identificadores de las operaciones completadas, el trabajo remoto pendiente, el motivo exacto de la detención y una recomendación para la siguiente asignación. Debe indicar si reintentar es seguro. Nunca debe ocultar que una acción terminó en un estado ambiguo.

Por ejemplo:

Detenido: se agotó el presupuesto de tiempo transcurrido.
Completado: se envió el trabajo de exportación ea91; no se descargaron archivos.
Último estado observado: en ejecución a las 14:09:58 UTC.
Intentos externos: 14 de 14; gasto reservado: 0 centavos.
Reanudación segura: comprobar una vez el estado de ea91 después de las 14:20 UTC.
Acción no segura: no enviar otra solicitud de exportación.

Ese mensaje evita la forma más costosa de recuperación: empezar de cero porque nadie sabe qué ocurrió. También permite ajustar los presupuestos. Si muchas ejecuciones normales se detienen después de una sola comprobación de estado, la duración permitida es demasiado corta. Si las ejecuciones suelen gastar toda su asignación en búsquedas sin avanzar, la división de la tarea o el alcance son incorrectos.

No repongas automáticamente un presupuesto agotado. Una regla de reposición no es más que un presupuesto ilimitado escrito en incrementos pequeños, salvo que una autoridad independiente decida cuándo se aplica. Exige una ejecución nueva o una acción humana explícita, conserva el registro anterior y deja que el siguiente intento explique por qué merece más margen.

La primera política que merece aplicarse es sencilla: cada ejecución autónoma recibe un número finito de solicitudes, un plazo estricto y una reserva de gasto antes de llegar a un servicio externo. Añade inmediatamente restricciones de alcance y buenos registros. Cuando un agente aprende que no puede seguir intentándolo para siempre, sus fallos se convierten en tareas contenidas en lugar de incidentes nocturnos.