Nueve agentes de IA, una sola cuota de API: cómo el Rate Governor evita los fallos en cascada

Cuando nueve agentes de IA trabajan en un mismo sistema con una cuota de API compartida, los mecanismos de protección habituales dejan de funcionar. Una sola respuesta 429 Too Many Requests desencadena una reacción en cadena que puede tumbar todo el sistema. Analizamos por qué ocurre y qué hacer al respecto.

Por qué el jitter no basta

En un servicio aislado, el exponential backoff con jitter es una forma fiable de protegerse de la sobrecarga de la API. El agente recibe un 429, espera una pausa aleatoria y repite la solicitud. La carga se reparte en el tiempo y el pico se atenúa. Funciona cuando hay un solo agente.

Pero cuando nueve agentes comparten la cuota y aplican la misma estrategia, las matemáticas cambian. Al saltar el límite, los nueve reciben un 429 casi al mismo tiempo. Todos calculan una pausa aleatoria dentro del mismo rango. El resultado: la mayoría reenvía sus solicitudes en una ventana muy estrecha y, en lugar de suavizar la carga, se forma un nuevo pico, a menudo mayor que el original.

• El agente A espera 1.2 s y repite la solicitud
• Los agentes B, C y D esperan entre 0.8 y 1.5 s y también repiten
• La carga total en el momento de la «ola de reintentos» supera la cuota
• Llega una nueva ola de 429 y el ciclo vuelve a empezar

Cuantos más agentes hay en el sistema, peor funciona el jitter. Este mecanismo se diseñó para servicios independientes con cuotas independientes, no para un grupo de agentes que consumen un límite común.

La arquitectura Rate Governor

La solución es sacar la gestión de la cuota a un componente aparte que vea el estado de todos los agentes a la vez y decida de forma centralizada. El Rate Governor actúa como punto de entrada único: los agentes no llaman a la API directamente, sino que primero piden permiso al coordinador. Solo tras recibir la confirmación, el agente hace la solicitud real.

Elementos clave de la arquitectura:

• Pool común de tokens: un contador único del límite disponible, actualizado en tiempo real para todos los agentes
• Sistema de prioridades: las tareas críticas (responder a un usuario) reciben tokens antes que las de segundo plano (indexación, enriquecimiento de datos)
• Circuit Breaker predictivo: no espera al primer 429, sino que predice el exceso a partir del ritmo actual de solicitudes y reduce la asignación con antelación
• Difusión del estado: el Governor informa a todos los agentes del estado actual de la cuota para que adapten su frecuencia de solicitudes de forma preventiva

Este enfoque rompe el círculo vicioso: los agentes ya no toman decisiones independientes sobre los reintentos, sino que se coordinan a través de un componente común.

El Circuit Breaker predictivo

El Circuit Breaker clásico reacciona solo después de recibir un error. En un sistema multiagente eso llega demasiado tarde: cuando aparece el primer 429, varios agentes ya han puesto reintentos en cola.

La versión predictiva vigila la velocidad de consumo de tokens. Si en los últimos 10 segundos se ha usado el 80% de la cuota, el Governor pasa a modo restrictivo con antelación: reduce el límite de asignación para los agentes de baja prioridad y les avisa del cambio. La curva de carga se suaviza antes de agotar el límite de la API y el 429 ni siquiera aparece.

Un Circuit Breaker predictivo cambia la lógica del sistema: en vez de «esperemos al error», se pasa a «prevengamos el error». Para ello hace falta telemetría constante: el Governor debe saber cuántos tokens ha gastado cada agente en una ventana de tiempo deslizante.

«El problema no es que cada agente haga algo mal.

El problema es que el comportamiento correcto de nueve agentes a la vez se convierte en un comportamiento colectivo incorrecto.»

Qué significa

Un Rate Governor es un elemento imprescindible en cualquier sistema multiagente con un límite de API compartido. Sin él, aumentar el número de agentes no mejora el rendimiento: cada agente nuevo solo hace más caóticos los fallos. Un coordinador centralizado con prioridades y control predictivo lleva al sistema de una lucha constante contra los errores 429 a un funcionamiento estable bajo carga real. Es especialmente importante cuando los agentes ejecutan tareas de distinta criticidad, porque el coordinador garantiza que lo urgente se atiende primero.