Control de presupuesto para agentes de IA: cómo limitar costos en runtime

Idea en 30 segundos

Budget controls son límites de runtime que detienen un run cuando el agente supera límites de pasos, tiempo, llamadas de herramienta o dinero.

Cuándo se necesita: cuando el agente llama herramientas externas, puede reintentar acciones y trabaja con presupuesto real en producción.

Problema

Sin presupuestos, un agente en producción entra fácilmente en un bucle: más pasos, más llamadas de herramienta, más costo. En demo no se ve porque la carga es baja. En producción, este comportamiento se convierte rápido en incidente.

Una respuesta inestable de herramienta suele iniciar una cadena: retry -> nueva llamada de herramienta -> más tokens -> otro retry. Si no hay un límite estricto en runtime, el run sigue más tiempo y cuesta más de lo planificado.

Analogía: es como un viaje sin límite en la cuenta de taxi de la empresa. Mientras el viaje es corto, todo parece normal. Cuando la ruta se alarga, los costos suben en silencio hasta el cobro.

Solución

La solución es mover las verificaciones de presupuesto a la capa de policy en runtime. Cada paso del agente se valida con cuatro límites: max_steps, max_seconds, max_tool_calls, max_usd.

La capa de policy devuelve una decisión técnica: allow o stop con razón explícita (max_steps, max_seconds, max_tool_calls, max_usd). Esta decisión se toma en cada paso, no solo al final del run. Es una capa separada del sistema, no parte del prompt ni de la lógica del modelo.

Budget Controls != Rate Limiting

Son niveles de control diferentes:

• Rate limiting limita la frecuencia de solicitudes a un sistema o herramienta.
• Budget controls limitan el gasto total de un run.

Uno sin el otro no funciona:

• sin budget controls, un solo run puede salir demasiado caro
• sin rate limiting, muchos runs pueden saturar dependencias

Ejemplo:

• rate limit: no más de 10 solicitudes por minuto a search_api
• budget controls: no más de max_tool_calls=12 y max_usd=1.00 por run

Métricas de control presupuestario

Estas métricas y señales trabajan juntas en cada paso del agente.

Ejemplo de alert:

Slack: 🛑 Agent Support-Bot hit max_usd limit ($100). Run stopped at step 12.

Cómo se ve en la arquitectura

La capa de policy de presupuesto se ubica entre runtime y ejecución de acciones, y valida límites antes de cada paso. Cada decisión (allow o stop) se registra en audit log.

Cada paso del agente pasa por este flow antes de ejecutarse: runtime no ejecuta acciones directamente — primero validación de presupuesto, luego ejecución.

Resumen del flow:

• Runtime actualiza usage (pasos, tiempo, llamadas de herramienta, gasto)
• la capa de policy de presupuesto valida límites
• allow -> se ejecuta el siguiente paso
• stop -> se devuelve stop reason y partial response
• ambas decisiones se escriben en audit log

Ejemplo

Un agente de soporte procesa una solicitud y llama muchas veces a refund.lookup por una API inestable.

Con budget controls:

• max_tool_calls = 8
• max_seconds = 45
• max_usd = 1.00

-> el run se detiene al alcanzar el límite, no después de un crecimiento descontrolado de costo.

Budget controls detienen el incidente en el nivel de ejecución, en vez de depender de que el modelo se detenga solo.

En código se ve así

En el esquema simplificado de arriba se muestra el control flow principal. En la práctica, el budget check suele ejecutarse dos veces: antes de ejecutar el paso y después de actualizar el usage real. El contador de pasos se actualiza antes de validar para incluir el paso actual dentro del presupuesto.

usage.update(step=1)

decision = budget.check(usage, limits)
if not decision.allowed:
    audit.log(run_id, decision.outcome, reason=decision.reason, usage=usage.snapshot())
    alerts.notify_if_needed(run_id, decision.reason, usage.snapshot())
    return stop(decision.reason)

result = tool.execute(args)
usage.update(tool_call=1, usd=result.cost_usd)

decision = budget.check(usage, limits)
if not decision.allowed:
    audit.log(run_id, decision.outcome, reason=decision.reason, usage=usage.snapshot())
    alerts.notify_if_needed(run_id, decision.reason, usage.snapshot())
    return stop(decision.reason)

audit.log(run_id, decision.outcome, reason=decision.reason, usage=usage.snapshot(), result=result.status)
return result

Cómo se ve durante la ejecución

Escenario 1: límite alcanzado (stop)

1. Runtime termina el paso 9 y actualiza el usage real.
2. Budget policy detecta que se superó max_usd.
3. Decisión: stop (max_usd).
4. Audit: decision=stop, reason=max_usd, step=9.
5. El usuario recibe partial response con stop reason.

---

Escenario 2: límite no alcanzado (allow)

1. Runtime inicia el paso 4 y actualiza usage.
2. Budget policy valida límites: todo dentro del umbral.
3. Decisión: allow.
4. Se ejecuta llamada de herramienta.
5. Audit: decision=allow, usage actualizado, resultado devuelto.

Errores típicos

• limitar solo tokens e ignorar max_seconds, max_tool_calls y max_usd
• revisar presupuestos solo "al final", no antes de cada paso
• no devolver stop reason explícito al usuario
• repartir la lógica de presupuesto entre runtime, tools y UI
• no registrar budget decisions (allow / stop) en audit trail
• no tener alerting sobre max_usd y max_tool_calls

Como resultado, el sistema parece estable, pero bajo carga pierde rápido la previsibilidad.

Autoevaluación

Chequeo rápido de budget controls antes de lanzar en producción:

FAQ

Q: ¿Alcanza solo con token budget?
A: No. Las herramientas pueden costar más que los tokens. Mínimo: max_steps, max_seconds, max_tool_calls, max_usd.

Q: ¿Qué implementar primero: max_steps o max_usd?
A: Empieza con max_steps y max_tool_calls para frenar bucles de inmediato. Después agrega max_usd como límite financiero.

Q: ¿Qué devolver al usuario en budget stop?
A: Partial response + stop reason explícito + breve guía de siguiente paso (acotar solicitud o reintentar con más presupuesto).

Q: ¿Se necesitan presupuestos por tenant?
A: Sí. Distintos planes o equipos necesitan límites distintos, pero la mecánica de validación debe ser la misma.

Q: ¿Budget controls reemplaza rate limiting?
A: No. Rate limiting protege dependencias ante picos; budget controls protege cada run ante gasto runaway.

Dónde encaja Budget Controls en el sistema general

Budget controls es una de las capas de Agent Governance. Junto con RBAC, execution limits, approval y audit, forma un sistema unificado de control de ejecución.

Páginas relacionadas

Siguiente en este tema:

• Resumen de Agent Governance — modelo general de control de agentes en producción.
• Control de acceso (RBAC) — cómo limitar quién puede invocar qué.
• Rate Limiting para agentes — cómo proteger herramientas y APIs de picos de tráfico.
• Step Limits — cómo frenar bucles infinitos por número de pasos.
• Audit logs para agentes — cómo analizar incidentes con stop reasons y decisiones del policy layer.