Seu Agente funciona com 20 conversas. E quando entram 500 ao mesmo tempo?

Um Agente de IA pode funcionar perfeitamente durante semanas de desenvolvimento. Você envia uma mensagem, ele consulta a base de conhecimento, interpreta o contexto, executa alguma ferramenta e responde corretamente. Depois testa com cinco pessoas ao mesmo tempo. Tudo certo. Coloca em produção e continua funcionando.

Até chegar o lançamento.

Uma campanha começa às 20h. Um anúncio viraliza. Um influenciador publica um link. Uma promoção é enviada para milhares de contatos. Em poucos minutos, dezenas ou centenas de pessoas iniciam uma conversa.

E o Agente que parecia pronto começa a demorar. Algumas mensagens falham, outras são processadas duas vezes e parte dos clientes simplesmente fica sem resposta.

O problema talvez não esteja na inteligência do Agente. Pode estar na capacidade da operação.

Testar se uma IA sabe responder e testar se o sistema consegue responder quando todo mundo fala ao mesmo tempo são problemas diferentes.

Qualidade e capacidade são problemas diferentes

Imagine que uma empresa tenha treinado seu Agente com cuidado. A base de conhecimento está organizada, as instruções estão bem definidas e os testes mostram respostas consistentes.

Isso demonstra qualidade.

Mas uma conversa com um Agente raramente depende apenas de uma chamada para um modelo de IA.

Dependendo da arquitetura, uma única mensagem pode iniciar várias operações:

1. receber a mensagem do canal;

2. identificar cliente e conversa;

3. recuperar histórico;

4. consultar banco de dados;

5. buscar informações na base de conhecimento;

6. chamar um modelo de IA;

7. executar alguma ferramenta;

8. consultar uma API externa;

9. chamar novamente o modelo;

10. registrar o resultado;

11. enviar a resposta ao cliente.

Cada etapa possui sua própria capacidade, latência e possibilidade de falha.

Por isso, quando 500 pessoas enviam mensagens praticamente ao mesmo tempo, a pergunta não deveria ser apenas:

A IA aguenta 500 conversas?

A pergunta mais útil é:

A operação inteira consegue absorver 500 eventos chegando quase simultaneamente e processá-los de forma controlada?

Esse é um problema de capacidade de ponta a ponta.

O problema dos limites de requisições

APIs de modelos de IA possuem limites de utilização.

A documentação de rate limits da OpenAI, por exemplo, descreve métricas como RPM, requests per minute, e TPM, tokens per minute. Dependendo da utilização, qualquer uma delas pode se tornar o primeiro limite atingido.

Isso cria uma situação que nem sempre é intuitiva.

Uma operação pode utilizar, em média, muito menos do que sua capacidade disponível e ainda assim sofrer com limites durante um pico.

A OpenAI também explica que os limites podem ser aplicados em períodos menores. Um limite apresentado como 60 requisições por minuto, por exemplo, pode equivaler a uma distribuição próxima de uma requisição por segundo. Uma rajada concentrada ainda pode provocar erros mesmo quando a média do minuto parece aceitável.

É a diferença entre média e pico.

Receber 300 mensagens distribuídas ao longo de uma hora é muito diferente de receber 300 mensagens em cinco segundos.

Para o negócio, continuam sendo 300 conversas.

Para a infraestrutura, são dois cenários completamente diferentes.

Aumentar o limite da API não resolve tudo

A primeira reação diante de problemas de capacidade pode ser procurar uma API com limites maiores ou solicitar aumento da capacidade disponível.

Isso pode ser necessário, mas não elimina o problema arquitetural.

Além dos limites contratados, serviços externos também podem enfrentar sobrecarga temporária. A documentação de erros da OpenAI prevê respostas `503` em períodos de alto tráfego e uma condição de "Slow Down" quando um aumento repentino na taxa de requisições afeta a estabilidade do serviço.

E o modelo é apenas uma das dependências.

Um Agente comercial pode utilizar:

• gateway de WhatsApp;
• banco de dados;
• busca vetorial;
• CRM;
• ERP;
• sistema de pagamentos;
• agenda;
• APIs de logística;
• ferramentas de automação;
• armazenamento de arquivos.

O limite operacional do Agente é determinado pelo conjunto.

Se nove componentes suportam o volume e o décimo começa a falhar, esse componente pode se transformar no gargalo da operação inteira.

É por isso que como o Agente deve agir quando uma integração sai do ar precisa ser definido antes do incidente, e não depois que centenas de atendimentos já estão presos esperando uma resposta.

A fila separa a chegada da mensagem do processamento

Uma das formas mais importantes de lidar com picos é não exigir que tudo seja processado no exato momento em que chega.

É aqui que entram as filas.

Sem uma fila, 500 mensagens podem tentar iniciar 500 processamentos praticamente ao mesmo tempo.

Com uma fila, cada evento é registrado e os workers responsáveis pelo Agente retiram esses eventos conforme existe capacidade para processá-los.

A Microsoft descreve esse padrão como Queue-Based Load Leveling. A fila funciona como um amortecedor entre uma demanda que chega em ritmo variável e um serviço que precisa processá-la em um ritmo controlado.

Isso muda a natureza do problema.

Sem fila:

Chegaram 500 mensagens. Precisamos processar 500 agora.

Com fila:

Chegaram 500 mensagens. Precisamos garantir que nenhuma seja perdida e processá-las na maior velocidade segura possível.

A fila não cria capacidade infinita.

Ela cria controle.

Esse princípio também aparece quando pensamos em execução assíncrona. Nem todo trabalho precisa permanecer preso ao ciclo imediato da conversa. Algumas tarefas podem ser registradas, executadas separadamente e retomadas quando existe resultado.

Uma fila também pode ficar congestionada

Adicionar uma fila não significa que o problema de capacidade desapareceu.

Imagine que o sistema consiga processar 50 mensagens por minuto, mas esteja recebendo 100.

Depois de um minuto, aproximadamente 50 continuarão esperando.

Se essa diferença permanecer por dez minutos, o backlog já terá crescido para aproximadamente 500 mensagens.

Enquanto a taxa de entrada for superior à taxa de processamento, a fila continuará aumentando.

Por isso, acompanhar apenas se os servidores estão "online" diz pouco sobre a saúde real do atendimento.

Uma operação precisa observar métricas como:

• quantidade de mensagens aguardando processamento;
• idade da mensagem mais antiga na fila;
• mensagens recebidas por minuto;
• mensagens processadas por minuto;
• tempo médio de processamento;
• percentis de latência;
• quantidade de erros;
• ocorrência de `429`, `500` e `503`;
• número de retries;
• tarefas enviadas para tratamento de falha;
• utilização dos serviços que compõem a operação.

Um Agente pode estar tecnicamente disponível e, ao mesmo tempo, acumulando uma fila que fará alguns clientes esperarem vários minutos.

Essa é uma das razões pelas quais observabilidade de Agentes IA não serve apenas para investigar uma resposta errada. Ela também precisa mostrar o que está acontecendo com a operação enquanto milhares de pequenas execuções atravessam bancos, APIs, filas e ferramentas.

Nem toda tarefa precisa ter a mesma prioridade

Existe outro detalhe importante durante um pico: talvez não faça sentido processar todas as tarefas exatamente na ordem em que chegaram.

Imagine uma operação comercial.

Um cliente acabou de dizer:

Quero comprar. Como faço o pagamento?

Outro iniciou a conversa dizendo:

Oi.

Um terceiro está aguardando uma mensagem automática de follow-up.

Um quarto solicitou atendimento humano.

Se a infraestrutura estiver temporariamente operando no limite, essas ações têm impactos comerciais diferentes.

Arquiteturas baseadas em filas podem trabalhar com prioridades. A documentação de arquiteturas críticas da Microsoft discute o uso de filas e priorização como parte do controle de cargas e tarefas.

Em uma operação comercial, uma política poderia separar atividades assim:

1. Clientes próximos da conversão

Pagamento, fechamento, agendamento e confirmação de compra.

2. Conversas ativas

Clientes que estão interagindo naquele momento.

3. Novos atendimentos

Primeiros contatos ainda não classificados.

4. Atividades assíncronas

Follow-ups, classificações secundárias, atualizações internas e outras rotinas que podem esperar alguns minutos.

A ordem correta depende da operação.

O ponto é outro: escala não significa apenas processar mais. Também significa decidir o que processar primeiro quando não é possível executar tudo imediatamente.

Retry ajuda. Retry mal implementado aumenta a sobrecarga

Uma API não respondeu. O modelo retornou um erro temporário. Uma integração ficou indisponível por alguns segundos.

Tentar novamente pode fazer sentido.

O problema começa quando centenas de processos falham juntos e todos tentam novamente imediatamente.

Imagine 300 chamadas falhando às 20:00:00.

Se todas forem repetidas às 20:00:01, o serviço recebe outra rajada de 300 chamadas justamente enquanto ainda pode estar se recuperando.

Ele falha novamente.

Os processos tentam outra vez.

Esse comportamento é conhecido como retry storm. A Microsoft documenta esse antipadrão e alerta que retries frequentes durante a recuperação podem piorar a indisponibilidade original.

Uma abordagem comum é utilizar exponential backoff.

Em vez de repetir a chamada imediatamente, a aplicação espera um intervalo. Se a chamada falhar novamente, espera um intervalo maior.

A OpenAI recomenda exponential backoff para erros de rate limit e também alerta que requisições malsucedidas podem continuar contribuindo para os limites. Reenviar continuamente a mesma chamada não resolve o problema.

Também pode ser utilizado jitter, adicionando aleatoriedade ao intervalo.

A AWS utiliza exponential backoff com jitter em estratégias de retry. O objetivo é impedir que centenas de clientes que falharam juntos façam a próxima tentativa exatamente no mesmo instante.

Em vez de criar outra rajada, as novas tentativas são distribuídas ao longo do tempo.

Retry também exige idempotência

Existe outro risco escondido nas novas tentativas.

Imagine que o Agente execute uma cobrança.

A requisição chega ao sistema de pagamento e a operação acontece. Porém, a resposta demora demais e ocorre um timeout.

Para a aplicação, a situação é ambígua.

A cobrança falhou ou apenas a resposta não voltou?

Se o sistema simplesmente repetir a operação, o cliente pode ser cobrado novamente.

O mesmo problema pode ocorrer com:

• criação de pedidos;
• agendamentos;
• envio de mensagens;
• geração de cupons;
• atualização de CRM;
• movimentações financeiras;
• criação de registros.

Por isso, uma arquitetura preparada para retries também precisa pensar em idempotência.

O padrão de retry documentado pela Microsoft chama atenção para esse ponto: uma operação não idempotente pode ser executada novamente quando o cliente não sabe se a primeira tentativa realmente terminou.

Na prática, a aplicação precisa conseguir reconhecer que determinada ação já aconteceu e impedir duplicações quando necessário.

Resolver escala não é apenas conseguir tentar novamente.

É conseguir tentar novamente sem transformar uma falha temporária em cobrança duplicada, pedido repetido ou mensagem enviada duas vezes.

Um teste com 20 conversas não responde à pergunta das 500

É comum testar Agentes abrindo várias conversas manualmente e verificando se tudo continua funcionando.

Esse tipo de teste é útil. Mas responde principalmente a perguntas funcionais.

O Agente entendeu?

Consultou a ferramenta certa?

Respondeu corretamente?

Transferiu para um humano quando deveria?

Esses testes continuam necessários. Um guia de como testar um Agente IA antes do atendimento real ajuda a validar justamente essas condições.

Mas capacidade exige outra camada de teste.

Uma operação que espera campanhas, lançamentos ou grandes picos deveria testar situações como:

Carga constante

O sistema consegue manter determinado volume durante uma hora sem aumentar progressivamente a fila ou a latência?

Pico repentino

O que acontece se centenas de mensagens chegarem em poucos segundos?

Dependência lenta

O que acontece se uma API que normalmente responde em 300 milissegundos começar a levar cinco segundos?

Rate limit

Como a operação reage quando uma integração começa a retornar `429`?

Falha temporária

O que acontece se um serviço necessário ficar indisponível por dois minutos?

Recuperação

Quando o serviço volta, o sistema consegue consumir o backlog sem gerar imediatamente outro pico?

Retry

As operações são retomadas corretamente ou começam a aparecer mensagens, cobranças e registros duplicados?

Degradação

Existe alguma funcionalidade secundária que pode ser temporariamente reduzida para preservar o atendimento principal?

Responder a essas perguntas é diferente de verificar se o texto produzido pela IA está bom.

É testar a operação.

O gargalo nem sempre está onde existe mais processamento

Suponha que a empresa perceba uma fila crescendo e decida dobrar a quantidade de workers.

Agora existem duas vezes mais processos retirando tarefas da fila.

Isso pode resolver o problema se o gargalo estiver na capacidade computacional desses workers.

Mas imagine que todos dependam de uma API externa limitada a determinada quantidade de chamadas.

Dobrar os workers apenas fará a aplicação atingir esse limite mais rapidamente.

A fila pode até diminuir por alguns segundos, enquanto erros `429` e retries começam a crescer logo depois.

O mesmo vale para banco de dados, busca vetorial, CRM, gateway de mensagens ou qualquer outro serviço compartilhado.

Escalar uma parte da arquitetura não significa automaticamente aumentar a capacidade do sistema inteiro.

A capacidade final é condicionada pelo gargalo.

A pergunta mais importante é quanto tempo a operação leva para se recuperar

Sistemas assíncronos mudam a forma de pensar sobre picos.

Talvez o objetivo não precise ser responder todas as 500 mensagens no mesmo segundo.

Isso pode ser caro, desnecessário ou inviável dependendo das integrações utilizadas.

Uma pergunta mais útil é:

Quanto tempo o sistema leva para absorver o pico, sem perder nenhuma conversa, e voltar ao estado normal?

Se entram 500 mensagens e o backlog é consumido rapidamente, a operação pode estar saudável.

Se entram 500 e, uma hora depois, centenas continuam aguardando, existe um problema de capacidade.

Se o sistema aumenta workers conforme a fila cresce, existe alguma elasticidade.

Se aumentar workers apenas gera mais chamadas simultâneas contra uma API limitada, o gargalo está em outro lugar.

Também vale acompanhar a idade do item mais antigo. Uma fila de 300 mensagens que está sendo consumida rapidamente conta uma história diferente de uma fila com o mesmo tamanho em que existem clientes esperando há 25 minutos.

Capacidade precisa ser analisada de ponta a ponta.

O horário de maior movimento é justamente quando o Agente mais vale

Existe uma ironia nesse problema.

Em períodos tranquilos, uma equipe humana talvez consiga atender boa parte das conversas sem grandes dificuldades.

O valor da automação aparece com mais força quando isso deixa de ser verdade.

No lançamento.

Na promoção.

No anúncio que performou acima do esperado.

No começo das inscrições.

Na abertura das vendas.

No horário em que dezenas ou centenas de clientes decidem falar com a empresa ao mesmo tempo.

É exatamente nesse momento que a automação deveria proteger a operação da explosão de demanda.

Por isso, antes de considerar um Agente pronto para escala, não basta perguntar:

O Agente responde bem?

Também é preciso saber:

• quantas conversas chegam durante o pico;
• quantas tarefas podem ser processadas por minuto;
• qual componente se torna o primeiro gargalo;
• o que acontece com o restante das mensagens;
• se existe fila;
• como as prioridades são definidas;
• como falhas temporárias são tratadas;
• como funcionam os retries;
• como duplicações são evitadas;
• quanto tempo o sistema leva para eliminar o backlog.

Um Agente comercial não é apenas um modelo de IA respondendo mensagens.

É uma operação distribuída entre modelos, APIs, bancos, filas, canais e integrações. Todos esses componentes possuem limites.

Se o maior valor do Agente aparece justamente quando chegam muitas mensagens, o sistema precisa ser projetado para continuar funcionando nesse momento.