Nove agentes de IA, uma cota de API: como o Rate Governor evita falhas em cascata

Quando nove agentes de IA operam em um mesmo sistema com uma cota de API compartilhada, os mecanismos de proteção padrão deixam de dar conta. Uma única resposta 429 Too Many Requests dispara uma reação em cadeia que pode derrubar o sistema inteiro. Vamos ver por que isso acontece e o que fazer a respeito.

Por que o jitter não resolve

Em um serviço isolado, o exponential backoff com jitter é uma forma confiável de se proteger da sobrecarga da API. O agente recebe um 429, espera uma pausa aleatória e repete a requisição. A carga se distribui no tempo e o pico é achatado. Isso funciona quando há um único agente.

Mas, quando nove agentes dividem a cota e aplicam a mesma estratégia, a matemática muda. Quando o limite é atingido, os nove recebem o 429 quase ao mesmo tempo. Todos calculam uma pausa aleatória dentro do mesmo intervalo. O resultado: a maioria reenvia as requisições numa janela estreita e, em vez de suavizar a carga, forma-se um novo pico, muitas vezes maior que o original.

• O agente A espera 1.2 s e repete a requisição
• Os agentes B, C e D esperam de 0.8 a 1.5 s e também repetem
• A carga somada no momento da «onda de retentativas» ultrapassa a cota
• Vem uma nova onda de 429 e o ciclo recomeça

Quanto mais agentes no sistema, pior o jitter funciona. Esse mecanismo foi projetado para serviços independentes com cotas independentes, não para um grupo de agentes que consomem um limite comum.

A arquitetura do Rate Governor

A solução é tirar o controle da cota para um componente separado, que enxerga o estado de todos os agentes ao mesmo tempo e decide de forma centralizada. O Rate Governor funciona como ponto de entrada único: os agentes não acessam a API diretamente, mas primeiro pedem permissão ao coordenador. Só depois de receber a confirmação o agente faz a requisição real.

Elementos-chave da arquitetura:

• Pool comum de tokens: um contador único do limite disponível, atualizado em tempo real para todos os agentes
• Sistema de prioridades: tarefas críticas (responder a um usuário) recebem tokens antes das de segundo plano (indexação, enriquecimento de dados)
• Circuit Breaker preditivo: não espera o primeiro 429, mas prevê o estouro pelo ritmo atual de requisições e reduz a liberação com antecedência
• Transmissão de estado: o Governor avisa todos os agentes sobre o status atual da cota, para que ajustem a frequência de requisições de forma preventiva

Essa abordagem quebra o círculo vicioso: os agentes deixam de tomar decisões independentes sobre retentativas e passam a se coordenar por meio de um componente comum.

O Circuit Breaker preditivo

O Circuit Breaker clássico atua de forma reativa, só depois de receber um erro. Em um sistema multiagente, isso é tarde demais: quando o primeiro 429 aparece, vários agentes já colocaram retentativas na fila.

A versão preditiva acompanha a velocidade de consumo de tokens. Se nos últimos 10 segundos foram usados 80% da cota, o Governor entra antecipadamente em modo de restrição: reduz o limite de liberação para os agentes de baixa prioridade e os avisa da mudança. A curva de carga se suaviza antes de o limite da API se esgotar, e o 429 nem chega a aparecer.

Um Circuit Breaker preditivo muda a lógica do sistema: em vez de «vamos esperar o erro», passa a valer «vamos prevenir o erro». Para isso é preciso telemetria constante: o Governor precisa saber quantos tokens cada agente gastou em uma janela de tempo deslizante.

«O problema não é que cada agente faça algo errado.

O problema é que o comportamento correto de nove agentes ao mesmo tempo se transforma em comportamento coletivo incorreto.»

O que isso significa

Um Rate Governor é um elemento obrigatório em qualquer sistema multiagente com limite de API compartilhado. Sem ele, aumentar o número de agentes não traz ganho de desempenho: cada novo agente apenas torna as falhas mais caóticas. Um coordenador centralizado, com prioridades e controle preditivo, tira o sistema da luta constante contra erros 429 e o leva a uma operação estável sob carga real. Isso é especialmente importante quando os agentes executam tarefas de criticidades diferentes, pois o coordenador garante que o urgente seja sempre atendido primeiro.