Planejamento de capacidade de agentes de IA: e se o uso dobrar?

Planejamento de capacidade de agentes de IA é descobrir qual limite você vai atingir primeiro quando o uso crescer e combinar a resposta antes de chegar lá. Para a maioria das empresas, o primeiro limite não é o modelo. É a revisão humana, o teto de requisições de uma ferramenta conectada ou a carga de suporte. Meça o custo e o esforço de uma unidade de trabalho, localize o elo mais apertado da cadeia e decida com antecedência o que o agente faz quando esse elo estiver cheio.

Principais pontos

• O uso raramente cresce de forma uniforme ao longo da cadeia. Tetos de API, revisão humana e suporte escalam cada um no seu ritmo, e o mais apertado define o seu teto real.
• Meça as chamadas, o tempo e o esforço de revisão de uma unidade de trabalho concluída antes de projetar qualquer coisa. Uma previsão baseada no uso médio falha na primeira semana movimentada.
• Decida o que o agente faz quando um limite é atingido: enfileirar, desacelerar, passar para uma pessoa ou pausar. Um limite sem plano vira uma falha silenciosa.
• A carga de revisão é o limite que mais passa despercebido. Se toda ação exige aprovação, dobrar o uso dobra o tempo dos revisores, a menos que a fronteira de aprovação seja redesenhada com evidências.
• Dê um responsável nomeado à capacidade, com limiares de alerta que abram a conversa bem antes do teto.

O que muda de fato quando o uso dobra?

Dobrar o uso parece uma mudança só, mas são várias. Mais pessoas enviam pedidos, cada pessoa envia mais pedidos e eles chegam em blocos, não distribuídos de forma regular ao longo do dia. O agente também toca mais sistemas, guarda mais memória e produz mais resultado que alguém precisa ler.

Pense no agente como uma cadeia: um pedido chega, o agente reúne contexto, chama um modelo, usa ferramentas nos seus sistemas, produz um resultado e uma pessoa o revisa ou recebe. Cada elo tem o seu próprio teto. Dobrar a taxa de chegada pressiona todos os elos ao mesmo tempo, mas só o mais apertado aparece como problema. Os outros ficam invisíveis até que o primeiro seja resolvido.

Por isso o planejamento de capacidade de um agente é diferente de contar licenças. O número de licenças não diz quantas requisições por minuto chegam ao provedor do modelo, quantas gravações o seu CRM aceita ou quantos rascunhos um gestor consegue aprovar antes do almoço. A pergunta útil não é quanto uso você espera. É qual elo quebra primeiro e o que você quer que aconteça quando isso ocorrer.

Se o papel do agente ainda estiver vago, resolva isso primeiro. A capacidade depende do trabalho, e o trabalho depende de um escopo claro, com fronteiras de aprovação definidas.

Quais limites você vai atingir primeiro?

Quatro tipos de limite costumam aparecer, geralmente nesta ordem de surpresa.

• Tetos do provedor do modelo: os provedores definem limites de requisições, tokens e chamadas simultâneas dentro de uma janela de tempo. Conversas longas e documentos grandes consomem tokens mais rápido do que perguntas curtas, então uma mudança no que as pessoas perguntam pode pesar mais do que uma mudança em quantas perguntam.
• Tetos de ferramentas e integrações: os sistemas aos quais o agente se conecta, como CRM, caixa de e-mail, ferramenta de chamados ou agenda, têm limites próprios de requisições e, às vezes, cotas diárias. Muitas vezes são mais apertados do que os do modelo e raramente aparecem nas anotações do projeto.
• Concorrência e latência: quando muitos pedidos se sobrepõem, cada um espera mais. Os usuários leem respostas lentas como respostas quebradas e começam a repetir o pedido, o que aumenta a carga.
• Capacidade humana: revisores, aprovadores e as pessoas que respondem dúvidas sobre o agente. Esse limite não aparece em nenhum painel, a menos que você o construa.

Um comportamento merece atenção especial: as novas tentativas. Quando uma chamada é recusada porque um teto foi atingido, um agente ingênuo tenta de novo imediatamente, o que soma à carga que causou a recusa. Um agente bem construído espera com intervalos crescentes, distribui as tentativas ao longo do tempo, enfileira o trabalho não urgente e garante que uma ação repetida, como enviar uma mensagem ou criar um registro, não aconteça duas vezes. Pergunte a quem constrói o seu agente como ele se comporta quando um limite é atingido, e não só quando tudo funciona.

Como medir uma unidade de trabalho?

Comece definindo a unidade em termos de negócio: uma dúvida de cliente resolvida, uma proposta redigida, uma fatura conciliada. Depois registre o que uma unidade consome. Conte chamadas ao modelo, tokens de entrada e saída, ações em ferramentas, tempo decorrido, minutos de revisão e com que frequência uma pessoa corrige o resultado. Capture um caso típico e um caso pesado, porque a capacidade é decidida pelos pesados.

É a mesma disciplina que a FinOps Foundation descreve como economia por unidade (unit economics): ligar o consumo a uma unidade de valor de negócio, em vez de olhar um total que só diz que a conta se mexeu. Quando você conhece o custo e o esforço por unidade, a previsão vira multiplicação, não palpite.

Para coletar esses números você precisa de observabilidade. O material introdutório do OpenTelemetry sobre observabilidade explica traces, métricas e logs, e as convenções semânticas para IA generativa mostram o que vale registrar nas chamadas ao modelo. Você não precisa de um sistema perfeito no primeiro dia. Precisa de um registro que permita responder, para qualquer semana, quanto trabalho o agente fez e quanto cada parte custou em chamadas e atenção.

A medição também revela economias que adiam limites. Agentes costumam reenviar as mesmas instruções longas e o mesmo material de referência a cada requisição. Quando o provedor oferece, o cache de prompt permite reaproveitar o contexto repetido, o que pode reduzir custo e latência. Combine isso com limites de gasto e alertas para que o crescimento dispare uma mensagem para uma pessoa, e não uma surpresa.

Como a carga de revisão e de suporte cresce com o uso?

A revisão é onde dobrar o uso costuma doer primeiro. Se o agente redige e uma pessoa aprova, cada pedido a mais acrescenta minutos de revisão. O modelo escala em uma tarde. Um revisor não. Acompanhe dois sinais: a idade do item mais antigo esperando aprovação e a frequência com que os revisores aprovam sem alterações. Uma fila crescente com alta taxa de aprovação sugere que a fronteira está apertada demais para o trabalho de baixo risco. Uma fila crescente com correções frequentes sugere que o agente precisa melhorar, não que a fronteira deva ser afrouxada.

O que você não deve fazer é deixar revisores cansados aprovarem tudo por hábito. Isso elimina o controle e mantém só a aparência dele. Em vez disso, escalone o trabalho:

• Mantenha a aprovação completa para ações difíceis de desfazer, que envolvam dinheiro ou que cheguem a clientes em situações sensíveis.
• Mova ações bem compreendidas e de baixo risco para revisão por amostragem, em que uma pessoa confere uma parte e os resultados são acompanhados.
• Agrupe itens parecidos para que o revisor os trate de uma vez, sem ser interrompido o dia todo.
• Nomeie um segundo revisor para que uma ausência não pare o trabalho.

Qualquer mudança em uma fronteira de aprovação deve seguir o mesmo caminho das outras mudanças: um pedido registrado, com evidências, e a aprovação do cliente. Isso evita que o esforço de revisão mude por deriva em vez de por decisão.

O suporte cresce de outro jeito. Ele escala com o número de usuários e a variedade das tarefas, não só com o volume. Usuários novos perguntam como formular pedidos, relatam resultados que parecem errados e encontram casos de borda que o primeiro grupo nunca tocou. Decida quem responde, como um problema é escalado e o que conta como incidente. Ao expandir para outras equipes, um plano de implantação em fases, com uma equipe de cada vez, mantém a carga de suporte visível antes que ela vire uma fila própria.

Um plano de capacidade passo a passo

Use este plano antes de um aumento previsto de usuários e de novo sempre que o agente ganhar uma tarefa ou ferramenta nova.

• Escreva a cadeia. Liste cada elo, do pedido ao resultado revisado, incluindo o provedor do modelo, cada ferramenta conectada e cada pessoa que toca o resultado.
• Encontre os limites publicados. Registre cada teto de provedor e de ferramenta e anote quais podem ser ampliados mediante pedido e quais são fixos.
• Meça uma unidade de trabalho. Capture chamadas, tokens, ações em ferramentas, tempo decorrido e minutos de revisão para um caso típico e um caso pesado.
• Calcule a folga por elo. Estime quanta carga a mais cada elo suporta antes que os usuários percebam e ordene os elos do mais apertado ao mais folgado.
• Defina dois limiares por elo: um nível de alerta que abre a conversa e um nível rígido em que o agente muda de comportamento.
• Escolha o comportamento no nível rígido: enfileirar o trabalho, reduzir o escopo, encaminhar a uma pessoa ou pausar as tarefas de menor prioridade.
• Atribua responsáveis. Uma pessoa responde pelo alerta de cada elo e sabe quem pode aprovar um aumento de limite ou uma mudança de equipe.
• Ensaie. Reproduza um dia movimentado em um ambiente de teste, ou simule o volume dobrado, e confirme que os alertas disparam e que o plano de contingência funciona.
• Revise em intervalos regulares e depois de qualquer mudança em usuários, ferramentas ou tarefas.

O quinto e o sexto passos são os mais ignorados. Um limiar sem comportamento combinado é só um número na tela.

Como isso fica na prática? Um cenário ilustrativo

Cenário ilustrativo: uma distribuidora usa um agente para redigir respostas a e-mails de fornecedores e atualizar pedidos no sistema de pedidos. Uma única equipe o opera sem dificuldade. Depois uma segunda equipe entra e a primeira acrescenta uma tarefa nova, de modo que o número de pedidos praticamente dobra em poucas semanas.

O problema não é o provedor do modelo. É a integração com a caixa de e-mail. Ela aceita um número limitado de leituras e envios por janela de tempo, e as manhãs de segunda-feira geram um pico que passa disso. O agente tenta de novo na hora, as recusas se multiplicam e algumas mensagens são processadas com atraso. Enquanto isso, uma gerente que aprova todos os rascunhos enfrenta uma fila que cresce mais rápido do que ela consegue esvaziar. A equipe começa a perguntar ao líder da segunda equipe por que as respostas estão lentas, e ninguém sabe ao certo quem deve responder.

As correções seguem o plano acima. O agente passa a esperar entre tentativas, agrupar as leituras da caixa de e-mail e colocar as mensagens de rotina atrás das urgentes. Confirmações de baixo risco passam para revisão por amostragem, por meio de um pedido de mudança documentado, enquanto os rascunhos ligados a pagamentos mantêm a aprovação completa. Um segundo revisor é nomeado e um pequeno canal de suporte ganha um responsável. A capacidade nunca foi um número único. Eram três limites separados, e cada um pedia uma resposta diferente.

Como a Be Human trata a capacidade na operação gerenciada?

A Be Human trata a capacidade como trabalho operacional contínuo, e não como uma estimativa feita uma vez. O primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, as fronteiras de aprovação e um critério de sucesso observável, e os limiares de capacidade são escritos junto com eles. A operação gerenciada pode então incluir o monitoramento do uso frente aos limites de provedores e integrações, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas. Mudanças nas fronteiras de aprovação são propostas com evidências e aprovadas pelo cliente, de modo que o esforço de revisão seja ajustado por uma decisão e não por deriva. O que é AgentOps e como operar um agente de IA no dia a dia explica o trabalho recorrente com mais detalhe.

Perguntas frequentes

Com que frequência devemos revisar a capacidade do agente de IA? Revise em intervalos regulares e também antes de qualquer aumento previsto de usuários, tarefa nova ou ferramenta nova conectada. Uma olhada mensal nos limiares de alerta é um bom ponto de partida para um agente em crescimento, e o ritmo pode diminuir quando o uso se estabilizar. O calendário importa menos do que ter um.

Devemos simplesmente comprar limites maiores quando chegarmos a um teto? Às vezes, mas verifique antes. Muitos limites podem ser ampliados com um pedido ao provedor ou ao fornecedor da ferramenta, mas a causa costuma ser comportamento desperdiçado, como contexto repetido, novas tentativas agressivas ou chamadas desnecessárias. Aumentar o teto sem corrigir a causa só empurra o limite um pouco para frente e mantém a mesma fraqueza.

Podemos retirar aprovações quando a fila de revisão fica longa demais? Só para ações específicas e só com evidência de que o risco é baixo. Analise os resultados recentes, mova essa categoria para revisão por amostragem por meio de uma mudança registrada e mantenha a aprovação completa para tudo que seja difícil de desfazer ou sensível. Retirar aprovações em bloco para limpar a fila esconde o problema e o risco ao mesmo tempo.

Quando o planejamento de capacidade deve começar? Comece no piloto, enquanto os volumes são pequenos e os números são baratos de coletar. Medir uma unidade de trabalho e nomear a cadeia de limites custa pouco nessa fase. Fazer o mesmo trabalho depois que os usuários já dependem do agente é mais lento, porque cada mudança corre o risco de atrapalhá-los.

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