Limites de taxa para agentes de IA: regras de retry, backoff e fila

Um agente de IA lida bem com limites de taxa quando trata cada resposta de bloqueio ou timeout como um sinal para desacelerar, e não como motivo para tentar de novo imediatamente. O conjunto prático de regras tem quatro partes: classificar cada erro antes de repetir, repetir com backoff exponencial e jitter sob um teto rígido, colocar chamadas não urgentes em uma fila com limite de concorrência, e parar em um orçamento fixo para passar a tarefa a uma pessoa. Juntas, essas regras evitam que uma ferramenta compartilhada seja sobrecarregada e mantêm o trabalho do agente preciso quando o sistema está lento ou ocupado.

Principais pontos

• Classifique cada erro antes de repetir: limitação de taxa e falhas temporárias podem ser repetidas, enquanto erros de permissão e de validação devem interromper a tarefa.
• Use backoff exponencial com jitter e limite tanto o número de tentativas de uma chamada quanto o tempo total da tarefa.
• Enfileire o trabalho não urgente e defina um limite de concorrência por ferramenta, para que nenhuma combinação de tarefas do agente sobrecarregue um sistema.
• Nunca repita uma ação de escrita antes de saber se a primeira tentativa foi concluída, usando uma chave de idempotência ou a leitura do registro de destino.
• Registre cada repetição, pausa e parada com o seu grupo de erro, para que uma pessoa veja se o problema é capacidade, permissão ou entrada de dados ruim.

O que um limite de taxa significa para um agente

Toda ferramenta de negócio limita quanto ela aceita em uma janela de tempo. Alguns limites contam requisições por minuto, outros restringem conexões simultâneas, e alguns são definidos pela equipe que mantém um sistema interno para proteger o banco de dados. Uma pessoa trabalhando em uma tela raramente chega a esses limites. Um agente pode chegar, porque escolhe a próxima chamada a partir da saída de um modelo, pode se espalhar por várias ferramentas em uma mesma tarefa e pode repetir um passo sem perceber que já o executou.

Os limites também são compartilhados. Uma API de planilha, um CRM, um sistema contábil e um ERP legado podem atender ao agente ao mesmo tempo que a equipe, as rotinas agendadas e outras integrações. Uma regra que parece segura para o agente sozinho ainda pode quebrar a emissão de notas do dia se ele consumir toda a cota disponível.

Cenário ilustrativo: um agente recebe a tarefa de atualizar várias centenas de registros de clientes em um CRM após uma mudança de preço. Sem fila, ele envia o lote inteiro em menos de um minuto, recebe respostas de bloqueio depois da primeira parte e repete na hora cada registro que falhou. O CRM fica bloqueado pelo resto da tarde, e a equipe de vendas não consegue registrar ligações. A tarefa em si estava correta. O erro foi o momento em que ela foi executada.

O conjunto de regras existe para evitar esse padrão. O agente deve desacelerar quando um sistema pedir, esperar na fila quando o trabalho não for urgente e parar quando as regras disserem que uma pessoa precisa decidir.

Classifique cada erro antes de repetir

Repetir toda falha é o erro mais comum. Os erros se dividem em grupos que exigem tratamentos diferentes, e o agente deve identificar o grupo antes de fazer qualquer outra coisa.

• Respostas de limitação, como HTTP 429: aguarde o período indicado pelo serviço e, se nenhum for informado, use as regras de backoff descritas abaixo.
• Falhas temporárias, como HTTP 503, timeouts de gateway e conexões interrompidas: repita com backoff, porque a requisição pode nunca ter chegado ao sistema.
• Falhas de autorização, como HTTP 401 ou 403: não repita em loop. A credencial ou a permissão mudou, e uma pessoa ou um processo de recuperação precisa resolver.
• Falhas de validação, como HTTP 400 ou 422: não reenvie o mesmo conteúdo. Corrija a entrada ou devolva a tarefa ao responsável.
• Conflitos, como HTTP 409: leia o registro atual antes de tentar de novo, porque outro processo pode tê-lo alterado.

Registre o grupo de cada tarefa. Com o tempo, as contagens mostram se o problema é de capacidade, de permissões ou da qualidade da entrada, e cada um pede uma correção diferente. Para falhas de credencial, veja o que um agente deve fazer quando uma conexão expira.

Coloque o trabalho não urgente em fila, em vez de enviar tudo de uma vez

Uma fila transforma uma rajada de trabalho em um fluxo constante. O agente não decide com que velocidade chamar uma ferramenta. Ele coloca o trabalho em uma linha, e um processo libera as chamadas em um ritmo que o responsável por aquela ferramenta aprovou.

Use este plano ao conectar um agente a um sistema compartilhado pela primeira vez:

• Peça ao responsável por cada sistema os limites de concorrência e de requisições, e escreva-os no contrato da ferramenta. O agente não deve descobri-los por meio de erros.
• Defina um teto de concorrência por ferramenta, e não por tarefa, para que duas tarefas do agente não somem mais do que o sistema consegue aceitar.
• Ordene a fila por urgência. Trabalho voltado ao cliente e com prazo vai primeiro, enquanto cargas em massa e limpezas rodam em horários de pouca movimentação.
• Agrupe leituras e escritas quando a ferramenta suportar lotes, já que uma chamada em lote costuma consumir menos capacidade do que muitas chamadas individuais.
• Defina uma idade máxima para cada item da fila. Se uma tarefa esperar além da janela, devolva-a a uma pessoa em vez de executar uma ação que pode já estar desatualizada.
• Defina antecipadamente uma condição de pausa, como o aumento da proporção de respostas de bloqueio, e deixe a fila parar sozinha quando essa condição for atingida.

O contrato da ferramenta é o lugar certo para esses limites, porque ele define o que o agente pode enviar e com que frequência.

Recue com jitter e pare em um orçamento rígido

Backoff exponencial significa que a espera cresce a cada tentativa fracassada: um intervalo curto no início, depois um mais longo, e assim por diante. Cada pausa dá à ferramenta mais tempo para se recuperar, em vez de ser acionada de novo no momento em que menos consegue responder. Os valores iniciais, o fator de crescimento e a espera máxima por tentativa devem ser definidos para cada ferramenta, e não copiados de um exemplo genérico.

O jitter acrescenta uma variação aleatória a cada espera. Sem ele, processos que falharam juntos voltam a tentar juntos, e a ferramenta recebe de novo o mesmo pico. Um pequeno deslocamento aleatório quebra essa sincronização.

O backoff sozinho não basta. Cada tarefa também precisa de um orçamento definido antes de o agente começar: um número máximo de tentativas para uma chamada, um tempo total máximo para a tarefa, um número máximo de chamadas por ferramenta e, quando a ferramenta cobra por requisição, um limite para o gasto que ela pode gerar. O agente não deve conseguir aumentar esses limites por conta própria.

Quando um orçamento se esgota, a tarefa passa para um estado de parada. Esse estado é um registro, não uma falha silenciosa. Ele deve listar o que foi concluído, o que não foi, o último grupo de erro, as chaves de idempotência em uso e a decisão que uma pessoa precisa tomar em seguida. Uma lista curta ajuda nesse momento:

• Confirme quais ações foram concluídas e quais não foram.
• Registre o grupo de erro e a hora da última tentativa.
• Marque qualquer escrita cujo resultado seja desconhecido e não a repita até que alguém tenha verificado.
• Indique quem decide se a tarefa será repetida, redistribuída ou cancelada.
• Mantenha o contexto do agente anexado, para que a próxima execução não comece do zero.

Torne as repetições seguras para ações de escrita

Repetir uma leitura costuma ser inofensivo. Repetir uma escrita pode criar a mesma nota fiscal, a mesma reserva ou a mesma mensagem duas vezes, especialmente quando a primeira requisição deu certo e apenas a resposta se perdeu. As escritas exigem uma regra mais rígida: o agente não deve repetir até saber se a primeira tentativa foi concluída.

O mecanismo habitual é a chave de idempotência. O agente gera uma chave para cada ação pretendida, armazena essa chave junto da tarefa e a envia em todas as repetições. O serviço reconhece a repetição e devolve o resultado original, em vez de executar a ação de novo. A Stripe documenta esse padrão na sua API de pagamentos, e o mesmo desenho pode ser construído em ferramentas internas com um registro das chaves já concluídas. Quando a ferramenta não oferece esse recurso, a opção segura é ler o registro de destino antes e confirmar se a mudança já existe. Os detalhes de projeto estão em idempotência em agentes de IA.

Como a Be Human trata limites de taxa em operações gerenciadas

No modelo gerenciado da Be Human, as regras de repetição e de fila fazem parte da primeira etapa do trabalho, e não são padrões deixados para o agente. A equipe combina os tetos de concorrência, as políticas de repetição e as condições de parada com o responsável por cada sistema conectado, escreve tudo no contrato da ferramenta e define os limites de aprovação para qualquer ação de escrita. Na operação contínua, repetições, profundidade da fila, pausas e estados de parada são monitorados, e revisões periódicas verificam se algum limite precisa de ajuste. Quando uma regra muda, a mudança passa por uma melhoria controlada, com registro do que mudou e do motivo, em vez de uma edição escondida nas instruções do agente.

Teste as regras antes do lançamento e acompanhe depois

Teste a política antes de o agente tocar em um sistema real. Em um ambiente de teste, simule a limitação de taxa ou peça ao responsável pelo sistema que reduza um limite por um curto período. Em seguida, confirme que o agente recua, coloca o restante na fila, para ao atingir o orçamento e registra a parada corretamente. Inclua o caso em que uma escrita é concluída, mas a resposta se perde. Esse único teste mostra se o desenho de idempotência funciona.

Depois do lançamento, registre cada repetição, espera, pausa e parada como um evento, com o identificador da tarefa e o nome da ferramenta. Os conceitos de observabilidade do OpenTelemetry oferecem um vocabulário comum para esse tipo de telemetria, e o detalhe importa: uma contagem de repetições sem o grupo de erro não diz se a causa é capacidade ou permissão. Para uma lista prática do que capturar, veja o que registrar na observabilidade de um agente de IA.

Revise as regras em uma agenda regular e antes disso sempre que houver qualquer mudança nos sistemas conectados. Uma ferramenta que estava tranquila na temporada passada pode estar mais movimentada agora, e limites escritos para uma carga menor podem já não protegê-la. Se você não tem certeza de qual ferramenta de negócio deve ser conectada primeiro, o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Um agente deve repetir imediatamente depois de um erro de limite de taxa? Não. Uma repetição imediata costuma receber a mesma resposta de bloqueio e acrescenta carga a um sistema que já pediu folga. O agente deve esperar o período indicado pelo serviço, ou usar backoff com jitter quando nenhum período for informado, e deve parar assim que atingir o orçamento de tentativas ou de tempo.

O backoff exponencial é suficiente para proteger uma ferramenta de negócio? O backoff é necessário, mas não suficiente. Ele espalha as repetições no tempo, mas não impede que uma rajada de novas tarefas chegue, por isso ainda são necessários um teto de concorrência e uma fila. Combine o backoff com limites por ferramenta definidos pelo responsável do sistema e com uma parada rígida em cada tarefa.

Um agente pode repetir com segurança uma ação de escrita? Só quando consegue saber se a primeira tentativa foi concluída. Use uma chave de idempotência armazenada junto da tarefa ou leia o registro de destino antes de repetir. Se nenhuma das duas opções estiver disponível, trate a escrita como resultado desconhecido e encaminhe a decisão a uma pessoa.

Quando uma tarefa limitada deve voltar para uma pessoa? Devolva a tarefa quando um orçamento se esgotar, quando aparecer um erro de autorização ou de validação, quando uma escrita tiver resultado desconhecido ou quando um item da fila ultrapassar a idade máxima. A passagem deve dizer o que foi concluído, o que não foi e qual decisão a pessoa precisa tomar em seguida.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.