O agente que não sabia parar
Um agente de IA travado num loop não avisa ninguém. Ele só continua chamando ferramenta, lendo resultado, decidindo chamar de novo, e cada chamada tem custo de token. Se ninguém colocou um limite explícito nesse ciclo, o primeiro sinal do problema é a fatura, não um alerta.
Uma pesquisa da VentureBeat Pulse divulgada em agosto de 2026 mostra que 21% das empresas não conseguem interromper o gasto de um agente descontrolado em tempo real. O motivo não é falta de ferramenta de monitoramento: é que 21% dessas empresas dependem só de monitoramento reativo, olhando log depois que o gasto já aconteceu. Sem botão de emergência, sem corte automático. Elas descobrem o problema, não impedem.
A gente trata isso como decisão de arquitetura, não como configuração de última hora. Todo agente que sai do laptop e vai pra produção carrega um teto de gasto por execução antes de qualquer outra coisa: antes do prompt bonito, antes da ferramenta nova, antes da integração com o sistema do cliente.
Por que não dá pra confiar só no bom senso do modelo
O argumento contra o teto é sempre o mesmo: "mas o modelo é bom, ele sabe quando parar". Não sabe. Um agente com acesso a ferramenta de busca, ferramenta de leitura de banco e ferramenta de escrita de arquivo pode entrar num ciclo onde cada resposta parece justificar mais uma chamada. Ele não tem noção de orçamento, só tem noção de tarefa incompleta. E tarefa incompleta, pra um agente, é sempre motivo pra tentar de novo.
O teto resolve um problema que nenhuma engenharia de prompt resolve sozinha: o pior caso. Você pode escrever a instrução mais cuidadosa do mundo dizendo "pare depois de três tentativas", e ainda assim o modelo vai ignorar em algum percentual dos casos, porque instrução em linguagem natural não é contrato. Contrato é código que corta a execução.
class OrcamentoExecucao:
def __init__(self, limite_usd):
self.limite_usd = limite_usd
self.gasto_acumulado = 0.0
def registrar(self, custo_chamada):
self.gasto_acumulado += custo_chamada
if self.gasto_acumulado > self.limite_usd:
raise OrcamentoEstourado(
f"Execução interrompida em {self.gasto_acumulado:.2f} USD, "
f"limite era {self.limite_usd:.2f} USD"
)
Simples assim. O corte acontece no meio da execução, não no fim do mês.
O trade-off que ninguém gosta de admitir
Aqui entra a parte desconfortável: um teto de gasto vai, em algum momento, interromper uma execução que estava perto de terminar direito. O agente estava a duas chamadas de resolver o problema, bateu no limite, morreu com a tarefa pela metade. Isso acontece. E a resposta certa não é tirar o teto, é decidir o que fazer quando ele bate.
A gente separa em dois comportamentos possíveis:
| Situação | O que a gente faz |
|---|---|
| Tarefa crítica, erro custa caro (financeiro, contrato, dado sensível) | Corta e escala pra humano, sem retomar sozinho |
| Tarefa de baixo risco (rascunho, classificação, busca interna) | Corta, registra onde parou, deixa reiniciar com contexto reduzido |
A diferença entre as duas colunas não é técnica, é de produto. Alguém precisa decidir, antes do deploy, quanto custa errado custa mais do que quanto custa devagar. Essa conversa costuma ficar de fora do planejamento porque parece detalhe de infraestrutura. Não é. É a diferença entre um agente que erra baixo e um que erra caro.
Onde o teto mora, e por que isso importa
Teto de gasto configurado dentro do próprio agente, no mesmo processo que decide as chamadas, não segura nada: se o processo travar ou o loop for rápido o suficiente, o contador nunca chega a rodar antes do estrago. O corte tem que estar num lugar que o agente não controla, um gateway, um proxy de chamadas, ou um serviço separado que sabe quanto cada execução já gastou e pode simplesmente recusar a próxima chamada.
Isso também resolve outro problema: dá visibilidade por execução, não só por dia ou por projeto. Um agente que gasta 40 centavos em 30 segundos é sintoma de alguma coisa errada, mesmo que o orçamento mensal do cliente ainda esteja tranquilo. Sem granularidade por execução, esse sintoma se perde dentro da média.
O que fazer na segunda de manhã
Se você já tem agente rodando em produção sem teto de gasto por execução, pare de ler isso e vá conferir o gateway de chamadas. Pergunte três coisas: existe um limite numérico por execução, ou só um limite mensal? Se o limite estourar, alguém é avisado em tempo real ou só no relatório da semana? E o corte acontece antes da próxima chamada de API ou depois que ela já foi paga?
Se a resposta pra qualquer uma delas for "não sei", esse é o buraco. E ele não aparece em teste, porque teste roda o caminho que dá certo. Aparece na primeira vez que alguém real usa o sistema de um jeito que você não previu, que é exatamente quando você não quer estar sem rede de proteção.
A Overflow trata isso como parte do que chama de implementação IA-first: guardrail de produção não é item de checklist final, é decisão que entra junto com a arquitetura.
