Quem coloca o primeiro agente em produção liga direto na API do provedor. Funciona. O problema aparece no terceiro agente, no primeiro incidente do provedor e no primeiro fechamento de mês com fatura três vezes maior que a projeção.
Os três sintomas têm a mesma solução estrutural: uma camada de proxy entre os seus agentes e os provedores de IA.
O que o proxy resolve
Um proxy de LLM é um serviço interno que expõe uma API compatível com a dos provedores e, atrás dela, decide para onde a chamada vai. Ele centraliza quatro decisões que, sem ele, ficam espalhadas por dezenas de lugares:
- Qual modelo atende esta chamada — e com que chave.
- O que fazer quando o provedor falha — repetir, cair para outro modelo, degradar.
- Quanto cada agente pode gastar — cota, limite, corte.
- O que aconteceu — tokens, latência, erro, custo, por agente e por conversa.
Sem essa camada, trocar de modelo significa mexer no código de todos os agentes; e responder "quanto o agente de cobrança gastou em julho?" vira uma tarde de investigação.
Fallback: o requisito que todo mundo descobre tarde
Provedores de IA caem. Têm limite de taxa, janelas de degradação e picos de latência — geralmente no horário em que você mais precisa. Sem fallback, isso vira atendimento parado.
Uma política de fallback razoável tem três degraus:
- Repetir com backoff — erros transitórios (429, 5xx) merecem duas tentativas rápidas, com espera crescente.
- Trocar de modelo — persistindo a falha, cai para o próximo modelo da lista, possivelmente de outro provedor.
- Degradar com honestidade — se todos falharem, o agente responde que está com dificuldade técnica, registra o caso e retoma depois. Nunca invente resposta para "salvar" o atendimento.
Dois cuidados: o fallback precisa ser funcionalmente equivalente — se o modelo alternativo não suporta chamada de ferramenta, ele não é fallback para um agente com ferramentas. E toda queda para o plano B deve ficar registrada; um sistema que degrada em silêncio esconde o problema até virar padrão.
Roteamento por tarefa: onde está a economia
O maior desperdício em operações de IA é rodar o modelo mais caro para tarefas mecânicas. Um agente de atendimento faz muito mais que redigir resposta:
| Tarefa | Exigência | Modelo |
|---|---|---|
| Classificar intenção | baixa | pequeno/barato |
| Extrair dado (CPF, número do pedido) | baixa | pequeno/barato |
| Resumir conversa para escalonamento | média | intermediário |
| Redigir resposta ao cliente | alta | forte |
| Decidir negociação / exceção | alta | forte |
Roteando por tarefa em vez de usar um único modelo para tudo, a fatura cai de forma expressiva sem que o cliente perceba diferença — porque a parte que ele lê continua vindo do modelo bom. É a alavanca mais direta na conta que abrimos em quanto custa manter um agente de IA.
Cota e corte: proteger o orçamento
Um agente com bug pode consumir num dia o orçamento do mês — loop de ferramenta, histórico crescendo sem truncar, uma integração devolvendo 200 KB de JSON. O proxy é o lugar certo para o freio:
- Cota por agente e por período (dia/mês), com alerta antes do teto.
- Limite por chamada — máximo de tokens de entrada e de saída, para que nenhuma chamada isolada saia da curva.
- Corte progressivo — ao atingir 80%, notifica; ao atingir 100%, rebaixa para o modelo barato ou bloqueia, conforme a criticidade do agente.
Essa é a diferença entre descobrir o problema no dia 3 ou na fatura do dia 30.
Observabilidade: o que registrar
Para cada chamada, o mínimo que serve para operar:
- agente, conversa e cliente (identificador, não conteúdo sensível);
- modelo pedido e modelo efetivamente usado (revela quanto o fallback está sendo acionado);
- tokens de entrada e de saída, e custo calculado;
- latência e resultado (sucesso, erro, tentativa);
- ferramentas chamadas na rodada.
Com isso, três perguntas passam a ter resposta em segundos: onde está indo o dinheiro, onde está a lentidão e qual agente regrediu depois da última mudança.
Troca de modelo sem drama
Modelos novos saem a cada poucos meses, mais baratos e melhores. Sem proxy, migrar é um projeto. Com proxy e um conjunto de casos-teste, migrar é um procedimento:
- Rodar o conjunto de avaliação no modelo novo e comparar com o atual — acerto, tom, uso correto de ferramenta.
- Espelhar tráfego de uma fatia pequena (5–10%) e comparar em produção.
- Aumentar gradualmente, observando escalonamento e satisfação.
- Manter o anterior como fallback por um ciclo.
O conjunto de avaliação é pré-requisito — como montá-lo está em como impedir que o agente invente resposta.
Uma armadilha específica que vale registrar: trocar o modelo pode zerar configurações do agente que eram específicas do modelo anterior (formato de saída estruturada, formato de definição de ferramenta). Sempre confira, depois da migração, se o agente continua com o mesmo comportamento de ferramenta e de formato — não só se a resposta "parece boa".
Segurança: um bônus que costuma decidir a compra
Com proxy, as chaves dos provedores ficam em um lugar só, nunca nos agentes. Isso significa rotação de chave sem redeploy, revogação instantânea de um agente comprometido, e um ponto único para aplicar filtro de dado sensível antes que ele saia da sua rede.
Para quem tem time de TI avaliando o projeto, essa costuma ser a parte que destrava a aprovação.
Quando você precisa disso
Não é no primeiro dia. Um único agente, baixo volume, chamada direta ao provedor — está ótimo.
Passa a valer quando qualquer destes for verdade: mais de dois agentes, cliente final na ponta (indisponibilidade tem custo), mais de um provedor ou necessidade de responder quanto custou cada área. Na prática, isso chega mais cedo do que se imagina.
Para ver como isso se encaixa numa operação com vários agentes, comece por agente de IA no WhatsApp ou agende 40 minutos.