El error de US$50 en 20 minutos: por que los controles de presupuesto no son opcionales para agentes de IA

En la tercera semana de operación de nuestro pipeline de investigación legal, un agente analista entró en un ciclo de revisión con el agente revisor. El analista enviaba un borrador. El revisor sugería cambios. El analista revisaba. El revisor encontraba nuevos problemas en la revisión. El analista revisaba de nuevo.

Doce iteraciones después, el output era peor que el borrador original. Y el costo acumulado de las llamadas de API era 40x el presupuesto previsto para esa tarea.

No hubo bug. Ningún agente fallo. El sistema hizo exactamente lo que se le instruyó: revisar hasta que la calidad fuera satisfactoria. El problema es que “satisfactorio” nunca llegó, porque cada revisión introducía nuevos elementos que el revisor cuestionaba.

Este tipo de falla no aparece en demos. Aparece en producción, cuando los agentes operan sin supervisión continua y la única señal de que algo salió mal es la factura de API al final del día.

El costo real de agentes sin control

Estamos construyendo sistemas multi-agente para operaciones empresariales. 10 agentes especializados cubriendo investigación legal, análisis de mercado, compliance, ingeniería de datos y estrategia comercial. El sistema corre como un daemon, ejecutando sprints autónomos contra un backlog de tareas.

El costo operativo objetivo es US$20/día. Con ese presupuesto, el sistema completa entre 4 y 8 tareas por sprint, usando Claude Sonnet 4 (US$3,00/US$15,00 por millón de tokens) para tareas de razonamiento pesado y Claude Haiku 4 (US$0,80/US$4,00 por millón de tokens) para tareas rutinarias.

Sin controles, este costo puede escalar de forma impredecible por tres razones:

Loops de revisión sin límite. Un agente genera output, otro evalúa, el primero revisa. Si no hay límite de iteraciones, el ciclo continua indefinidamente. Cada iteración consume tokens de input (el contexto acumulado crece con cada ronda) y tokens de output (la revisión completa se regenera).

Cascadas entre agentes. En sistemas donde los agentes disparan acciones de otros agentes, una falla upstream puede generar reintentos en cascada. El agente A falla, el agente B intenta compensar, el agente C recibe datos inconsistentes y reintenta, cada uno consumiendo llamadas de API.

Tareas ambiguas sin condición de parada. Cuando la instrucción es “investiga hasta encontrar datos suficientes” y los datos no existen, el agente sigue investigando. Cada intento consume tokens. Sin un cap explícito, el agente opera hasta que la API retorne un error de rate limit o el saldo de la cuenta se agote.

Control 1: Cap diario con corte automático

El primer control que implementamos es el más simple: un techo diario de gasto en dólares.

En nuestro sistema, el BudgetGate rastrea cada llamada de API en un banco SQLite. Toda llamada registra el agente que la hizo, el modelo usado, los tokens de input y output, y el costo calculado. Antes de cada sprint, el sistema consulta el total gastado en el día.

Cap diario: US$20,00
Gastado hasta ahora: US$14,32
Disponible: US$5,68
Estado: dentro del presupuesto

Cuando el gasto del día alcanza el cap, el proximo sprint se cancela. El mensaje es directo: “Sprint skipped: daily budget exhausted ($20.00 cap reached)”. El sistema no intenta negociar, no ejecuta “solo una tarea más”, no hace excepciones. Para.

Este corte duro ya evito al menos tres incidentes en los primeros 30 días de operación. En todos los casos, el patrón era el mismo: una secuencia de tareas genero output de baja calidad, el sistema intento reprocesar, y el reprocesamiento consumió más tokens que la ejecución original.

US$20/día puede parecer conservador para un sistema con 10 agentes. Es intencional. En un sistema en validación, el objetivo no es maximizar throughput. Es entender el costo por tarea y calibrar los controles antes de aumentar el volumen.

Control 2: Costo por tarea y por agente

El cap diario impide que el costo total se descontrole. El rastreo por tarea muestra adonde va el dinero.

El sistema genera reportes con desglose por agente:

Budget Report (2025-08-11)
Spent: $16.2340 / $20.00 ($3.7660 remaining)

Per-agent breakdown:
  legal-orchestrator: 12 calls, 45200 in / 8900 out, $7.4820
  corpus-engineer: 6 calls, 22100 in / 5400 out, $3.8730
  market-researcher: 4 calls, 18300 in / 3200 out, $2.9340
  compliance-specialist: 3 calls, 9800 in / 2100 out, $1.9450

Este nivel de visibilidad revela patrones que un cap agregado esconde. En el ejemplo de arriba, el orquestador consume el 46% del presupuesto diario. Eso es esperado: planifica sprints, coordina equipos y genera reportes. Pero si el orquestador empieza a consumir el 70% del presupuesto, sabemos que hay un problema de diseño en el sistema de planificación.

Estamos probando asignaciones de presupuesto por departamento. La idea es que cada equipo (validación de mercado, técnica, funding, compliance) tenga una porción del presupuesto diario. Si el equipo de mercado consume toda su porción, los demás equipos siguen operando. Un problema localizado no tumba el sistema entero.

Control 3: Límite de reintentos con bloqueo permanente

El control que resolvio el problema del loop de revisión fue el más simple de implementar: un límite de 3 intentos por tarea.

El flujo funciona así:

1. El agente intenta ejecutar la tarea.
2. El output pasa por un gate de calidad (50+ patrones de detección de basura + puntuación de contenido de 0 a 1).
3. Si el output se rechaza (puntuación por debajo de 0,4 o patrón de basura detectado), la tarea vuelve a la cola.
4. En la siguiente ejecución, el sistema verifica el contador de reintentos.
5. Si el contador llegó a 3, la tarea se marca como “blocked” y se retira de la cola activa.

Las tareas bloqueadas escalan a revisión humana. El sistema no intenta resolver lo que no pudo resolver en 3 intentos. Esta regla existe porque observamos que, si un agente falla 3 veces en la misma tarea, el cuarto intento casi nunca produce un resultado diferente. El problema generalmente esta en la tarea (ambigua, dependiente de datos externos no disponibles o mal definida), no en la ejecución.

En las primeras 37 tareas del backlog legal, 33 se completaron exitosamente. De las 4 bloqueadas, todas fallaron por dependencia de financiamiento externo. El límite de reintentos no bloqueo ninguna tarea viable. Solo bloqueo las que realmente no podían completarse con los recursos disponibles.

Control 4: Detección de output basura

Antes de contar reintentos, el sistema necesita identificar cuando el output es basura. Construimos dos capas de detección.

La primera capa es una lista de 50+ patrones textuales. Cada patrón se agregó después de una falla real. Ejemplos:

• “as an AI, I cannot” (rechazo del modelo)
• “let me search for” (agente planificando en vez de ejecutando)
• “no results found” (búsqueda vacia presentada como resultado)
• “I don’t have access to” (queja de permisos)
• “the next step would be” (planificación sin ejecución)
• “function_call” (agente intentando invocar tools cuando esta en modo synthesis-only)

La segunda capa es una puntuación de calidad de 0 a 1. La función analiza:

• Longitud: output con menos de 30 palabras recibe 0,1. Con más de 100 palabras, +0,1. Con más de 300, +0,1.
• Marcadores de sustancia: presencia de valores en dólares, porcentajes, URLs, fechas, tablas formateadas y headers estructurados. Cada marcador suma 0,05, hasta un bonus máximo de 0,3.
• Penalidad por planificación: si el output contiene 3 o más frases como “we should”, “the plan is”, “steps to take”, la puntuación se reduce en 0,15.

Cualquier output con puntuación por debajo de 0,4 se rechaza. En la práctica, este umbral elimina output que parece plausible en la superficie pero no contiene información concreta. Un agente que produce 500 palabras de análisis de mercado sin un solo número, fecha o fuente específica recibe una puntuación de 0,3 y vuelve a reprocesamiento.

Control 5: Circuit breaker entre sprints

Cada sprint consume entre 2 y 4 tracks de ejecución. Entre cada track, el sistema verifica el presupuesto restante. Si el cap se alcanzó durante el track anterior, el siguiente track se cancela con estado “skipped_budget”.

Este es el circuit breaker: la capacidad de parar a mitad de un sprint cuando los números no cuadran. Sin el, un sprint con 4 tracks ejecutaria los 4 aunque el primero haya consumido el 80% del presupuesto diario.

El sistema también resetea automáticamente tareas que quedaron trabadas en “in_progress” de sprints anteriores que fallaron. Si el daemon cae a mitad de un sprint (crash, timeout de API, reinicio del servidor), las tareas trabadas vuelven a “pending” en el siguiente ciclo. Sin este mecanismo, tareas fantasma ocuparian slots en el backlog indefinidamente.

Lo que muestran los números

Resultados iniciales de los primeros 30 días de operación con todos los controles activos:

Métrica	Valor
Tareas completadas	33 de 37
Tareas bloqueadas (límite de reintentos)	4
Tareas bloqueadas por output basura	0 (todos los rechazos se resolvieron dentro de 3 intentos)
Costo promedio por día	US$14-18
Costo promedio por tarea completada	US$6-9
Sprints cancelados por presupuesto	3
Incidentes de costo descontrolado	0 (después de implementar los controles)

El costo de US$6-9 por tarea completada sustituye trabajo que costaría US$50-200 si lo hiciera un analista junior (considerando salario, gestión, infraestructura). El ROI es claro. Pero solo existe porque los controles mantienen el costo predecible.

Sin los controles, el incidente de los 40x hubiera ocurrido repetidamente. No por mala intención del sistema. Por ausencia de límites explícitos.

Implementando controles en la práctica

Para quien esta construyendo sistemas multi-agente en producción, los controles minimos que estamos validando:

Día 1: Cap diario en dólares. Cualquier monto. El número exacto importa menos que la existencia del límite. Ajusta después de observar el patrón real de consumo.

Semana 1: Rastreo por agente y por tarea. Registra cada llamada de API con el nombre del agente, el modelo, los tokens y el costo. Sin esta visibilidad, optimizar costo es imposible.

Semana 2: Límite de reintentos. 3 es un número razonable. Las tareas que fallan 3 veces necesitan intervención humana, no un cuarto intento.

Semana 3: Detección de output basura. Empieza con 10-15 patrones basados en las fallas reales de tu sistema. La lista va a crecer organicamente. La nuestra tiene 50+ y sigue aumentando.

Semana 4: Circuit breakers entre etapas de ejecución. Verifica presupuesto antes de cada etapa. Para a mitad si es necesario.

Ninguno de estos controles es sofisticado. Son verificaciones simples con lógica condicional básica. La sofisticación esta en tener todos operando simultáneamente, con logging suficiente para diagnosticar problemas después del hecho.

Lo que viene después

Estamos trabajando en tres extensiones de los controles actuales:

Detección de anomalía de gasto. Hoy, el sistema solo reacciona cuando se alcanza el cap. Estamos construyendo alertas para cuando el costo por tarea se desvie más de 2x del promedio histórico. Si una tarea que normalmente cuesta US$5 esta en US$12 después del segundo intento, el sistema debería senalarlo antes del tercero.

Presupuesto por departamento. En vez de un único cap diario, cada equipo de agentes recibe una asignación proporcional. El equipo de mercado recibe 30%, el técnico recibe 35%, funding recibe 20%, compliance recibe 15%. Una falla en un equipo no compromete a los demás.

Pronostico de costo pre-ejecución. Antes de iniciar un sprint, estimar el costo probable basado en el historial de tareas similares. Si el pronostico excede el presupuesto disponible, reducir el número de tracks o postergar tareas más caras.

El punto central es que el control de costos para agentes de IA no es una feature “nice to have” que agregas cuando el sistema esta maduro. Es infraestructura básica que necesita existir antes de la primera ejecución autónoma. El costo de no tener controles no es una factura alta al final del mes. Es la imposibilidad de confiar en el sistema para operar sin supervisión constante. Y si necesitas supervisión constante, el sistema no es realmente autónomo.

---

Synaptic transforma empresas en organizaciones AI-native. Empezamos donde la demo termina. synaptic.so