Autonomia sem orçamento vira cheque em branco: por que Agentes precisam de limites de tempo, custo e chamadas de ferramenta

Quando uma empresa coloca um Agente de IA em produção, uma das primeiras preocupações costuma ser o preço do modelo. Quanto custa um milhão de tokens? Existe uma opção mais barata? Dá para usar um modelo menor em parte do fluxo?

Essas perguntas importam, mas atacam apenas uma parte do problema.

Um Agente não funciona necessariamente como uma API tradicional que recebe uma requisição, processa uma vez e devolve uma resposta. Dependendo da arquitetura, ele pode interpretar um objetivo, planejar ações, consultar ferramentas, analisar resultados, mudar de estratégia, buscar informações na memória, replanejar e continuar trabalhando até considerar a tarefa concluída.

É justamente essa capacidade que torna Agentes úteis. Também é o que faz com que autonomia sem limites possa se transformar em um cheque em branco.

O Agentic AI Lens da AWS, publicado em junho de 2026, trata custo como uma dimensão própria da arquitetura de sistemas agentivos. Entre as recomendações estão orçamentos por ciclo, tarefa e período, limites automáticos de execução e mecanismos específicos para detectar loops, excesso de chamadas de ferramentas e crescimento descontrolado de contexto.

A pergunta deixa de ser apenas “quanto custa o modelo?”.

Ela passa a ser:

Quanto de autonomia financeira e operacional estamos dispostos a conceder para cada tarefa?

O custo de um Agente não está apenas no modelo escolhido

Imagine dois Agentes usando exatamente o mesmo modelo.

O primeiro recebe uma solicitação, raciocina duas vezes, consulta o CRM e conclui a tarefa.

O segundo consulta o CRM, recebe um erro, tenta novamente, procura os dados em outro sistema, reformula o plano, consulta o CRM mais uma vez, chama uma API externa e continua raciocinando porque ainda não conseguiu determinar se a tarefa terminou.

O preço por token é o mesmo.

O custo da tarefa não.

A documentação de arquitetura de Agentes da Microsoft trata custo como uma característica operacional. Ela destaca que soluções capazes de produzir respostas semelhantes podem apresentar diferenças muito grandes de custo porque o resultado depende de fatores como contexto carregado, número de chamadas ao modelo, replanejamento e uso de ferramentas.

O orquestrador tem um papel central nessa conta. É ele que decide quantas vezes o modelo volta a raciocinar, quanto contexto permanece em cada rodada e quando uma tarefa pode ser considerada concluída.

Por isso, escolher um modelo mais barato não resolve sozinho a governança financeira de um sistema agentivo.

Você pode economizar no preço de cada inferência e, ao mesmo tempo, permitir que o Agente execute muito mais inferências do que deveria.

Essa discussão também se conecta ao roteamento de modelos de IA conforme custo, velocidade e risco. A escolha do modelo importa, mas ela precisa ser analisada dentro do custo da tarefa inteira.

O problema dos loops que parecem trabalho

Um dos riscos mais traiçoeiros é que um Agente em loop nem sempre parece quebrado.

Ele continua executando.

Continua chamando ferramentas.

Continua recebendo respostas.

Continua gerando tokens.

Continua tentando avançar.

Do ponto de vista técnico, existe atividade. Do ponto de vista econômico, pode existir apenas consumo.

A AWS identifica padrões como picos de tokens causados por loops de raciocínio, tool invocation storms e crescimento de memória como comportamentos específicos de escalada de custo em sistemas agentivos.

O problema de olhar apenas para a conta de infraestrutura é que uma execução anormal pode desaparecer no meio de milhares de execuções normais.

Você descobre que gastou demais.

Mas talvez descubra tarde demais.

Por isso existe uma diferença importante entre observar e limitar.

Alerta de custo é observabilidade. Limite de custo é controle.

A observabilidade de Agentes IA ajuda a reconstruir o que aconteceu em cada execução. Um orçamento operacional acrescenta outra camada: impede que determinado comportamento continue indefinidamente enquanto a equipe apenas registra o problema.

Um Agente precisa saber até onde pode ir

Em aplicações tradicionais, limites são normais.

Limitamos memória.

Limitamos CPU.

Limitamos requisições por segundo.

Limitamos conexões simultâneas.

Limitamos tempo de execução.

Com Agentes, outra categoria precisa entrar no desenho: o orçamento de autonomia.

Esse orçamento não precisa ser um único número. Ele pode limitar várias dimensões da execução.

Orçamento de etapas

Quantas vezes o Agente pode continuar raciocinando, planejando ou reavaliando a mesma tarefa?

Se determinado processo normalmente termina em quatro ciclos, uma execução que chegou ao décimo quinto provavelmente merece atenção.

Talvez o Agente tenha encontrado uma exceção legítima.

Talvez uma condição de conclusão tenha falhado.

Talvez ele esteja reavaliando a mesma situação sem produzir informação nova.

A documentação de looping do Microsoft Agent Framework recomenda explicitamente que loops autônomos sejam delimitados. Uma condição de conclusão pode falhar, um modelo pode parar de avançar e um avaliador também pode ser probabilístico.

A ideia não é definir que cinco ciclos sempre são corretos e seis sempre são errados.

O limite existe para impedir que uma exceção vire execução indefinida.

Orçamento de ferramentas

Quantas chamadas externas uma tarefa pode fazer?

Essa dimensão merece um limite próprio porque uma ferramenta pode adicionar custo de duas formas.

Primeiro, existe o custo da própria API ou serviço externo.

Depois, existe o custo de processar o resultado retornado.

Uma consulta pode devolver centenas ou milhares de tokens que voltarão ao contexto do modelo.

A AWS recomenda tratar chamadas de ferramentas como uma fonte própria de custo. Entre as práticas propostas estão verificar se a informação já existe no contexto, reutilizar resultados, agrupar chamadas, armazenar respostas em cache e detectar consultas duplicadas.

Esse último ponto merece atenção.

Um Agente pode consultar uma ferramenta, continuar raciocinando e, alguns passos depois, pedir exatamente a mesma informação novamente.

Também pode tentar repetidamente uma integração que está indisponível.

Nesse cenário, um mecanismo de retry mal configurado deixa de ser apenas uma estratégia de recuperação e começa a multiplicar custo.

É por isso que o comportamento do Agente quando uma integração sai do ar precisa incluir limites de tentativas, critérios de interrupção e alternativas previsíveis.

Orçamento de tempo

Uma tarefa também deveria possuir um limite de duração.

Imagine uma operação que costuma terminar em vinte segundos.

Se uma execução está aberta há cinco minutos, alguma coisa mudou.

Pode ser uma API lenta.

Pode ser uma fila externa.

Pode ser uma falha de ferramenta.

Pode ser um ciclo de replanejamento.

Pode ser um processo legítimo que simplesmente demora mais.

A função do limite não é decidir qual dessas hipóteses é verdadeira. É impedir que a infraestrutura trate qualquer duração como aceitável.

A Microsoft inclui tempo total, quantidade de etapas, profundidade de recursão, retries, chamadas de ferramentas e gasto total entre os controles recomendados para delimitar execução autônoma.

Orçamento de tokens e contexto

Também existe um custo que cresce silenciosamente: o contexto acumulado.

Cada nova informação adicionada à execução pode ser carregada novamente nas chamadas seguintes.

Se o Agente acumula histórico, resultados de ferramentas, instruções, documentos e etapas intermediárias sem nenhum mecanismo de redução, o custo pode crescer a cada novo ciclo.

A AWS destaca justamente o crescimento de memória como um dos fatores que precisam de controles próprios. Resumir contexto, descartar informações que já não são necessárias e evitar carregar dados permanentemente são decisões econômicas, não apenas técnicas.

Orçamento financeiro

Por fim, existe o limite que traduz todas essas dimensões para a linguagem do negócio:

Quanto esta tarefa pode custar?

Não o Agente inteiro por mês.

Não a conta de cloud da empresa.

A tarefa.

Se responder a um lead possui determinado valor econômico esperado, não faz sentido permitir que uma exceção operacional consuma recursos indefinidamente em busca da resposta perfeita.

Se uma análise gera R$ 20 de valor esperado, uma execução que já consumiu R$ 50 provavelmente precisa de outro tratamento, mesmo que tecnicamente ainda exista alguma chance de melhorar o resultado.

Essa mudança leva a indicadores mais úteis:

• custo por atendimento;
• custo por tarefa concluída;
• custo por decisão;
• custo por workflow;
• custo por cliente ou tenant;
• custo por resultado produzido.

A AWS recomenda atribuir custos no nível do ciclo de raciocínio, Agente, workflow e tenant, conectando posteriormente esses dados a métricas como custo por decisão e custo por tarefa concluída.

A fatura mostra quanto a infraestrutura consumiu.

Essas métricas mostram o que aquele dinheiro produziu.

Orçamento não significa deixar o Agente menos autônomo

Colocar limites pode parecer uma tentativa de transformar o Agente novamente em um workflow rígido.

Não precisa ser.

Um orçamento não determina cada decisão que o Agente pode tomar dentro de seu espaço de atuação.

Ele determina quanto recurso pode consumir tentando tomar essas decisões.

É uma lógica comum em empresas.

Um gestor pode possuir autonomia para comprar determinados equipamentos até certo valor. Acima dele, precisa de aprovação.

Uma pessoa da equipe comercial pode negociar dentro de determinada faixa. Fora dela, o caso é escalado.

Autonomia empresarial raramente significa autoridade ilimitada.

Com Agentes deveria acontecer o mesmo.

Essa é também uma das diferenças importantes entre Agente de IA e workflow determinístico. Dar liberdade ao modelo pode ser útil quando existe ambiguidade real para resolver. Isso não exige abrir mão de controles determinísticos ao redor dessa liberdade.

A AWS propõe uma abordagem em camadas. Em vez de existir apenas entre os extremos “liberado” e “desligado”, o sistema pode reduzir capacidade conforme se aproxima do orçamento, aplicar throttling, exigir aprovação ou interromper somente a execução problemática.

O limite não deveria estar apenas no prompt

Existe uma diferença importante entre informar um limite e impor um limite.

Uma instrução como:

“Não utilize mais de cinco ferramentas.”

pode influenciar o comportamento do modelo.

Mas continua sendo uma instrução interpretada pelo próprio sistema probabilístico que está sendo limitado.

Se cinco chamadas representam uma regra financeira ou operacional real, o controle mais confiável deve existir fora do ciclo de raciocínio.

A AWS recomenda implementar controles de custo fora do loop do Agente, realizando verificações antes das invocações e aplicando interrupções quando os limites configurados são atingidos.

O princípio é simples:

O Agente pode decidir o que gostaria de fazer. A infraestrutura decide se ele ainda possui orçamento e autorização para fazer.

Isso transforma orçamento em política operacional.

Não em sugestão no prompt.

O que fazer quando o orçamento termina?

Chegar ao limite não precisa significar simplesmente encerrar tudo com um erro.

O comportamento pode depender do tipo de tarefa.

Um Agente de atendimento pode entregar a melhor resposta parcial que conseguiu produzir.

Um Agente comercial pode encaminhar a conversa para uma pessoa.

Uma pesquisa pode informar que chegou ao limite de investigação.

Uma automação administrativa pode solicitar autorização para continuar.

Uma arquitetura com diferentes modelos pode migrar para uma opção mais econômica.

Uma tarefa pode ser colocada em fila para processamento posterior.

Esse desenho cria uma forma de degradação controlada.

A Microsoft recomenda limites antecipados e degradação previsível quando workloads de IA se aproximam de seus thresholds de capacidade ou orçamento.

Isso é muito diferente de deixar o Agente continuar até alguma dependência falhar ou a conta ficar cara demais.

Também permite combinar orçamento com supervisão humana em Agentes IA. O humano não precisa aprovar cada pequena decisão. Pode entrar justamente nos casos em que a autonomia normal já consumiu o orçamento disponível ou encontrou uma exceção relevante.

O componente mais barato pode produzir a arquitetura mais cara

Comparar modelos apenas pelo preço por milhão de tokens pode criar uma falsa sensação de otimização.

Imagine um modelo A que custa menos por chamada, mas precisa de várias tentativas para executar determinada tarefa.

Agora imagine um modelo B mais caro que resolve o mesmo problema com menos etapas, menos replanejamento e menos chamadas externas.

O modelo A continua sendo mais barato por token.

A tarefa pode não ser.

A mesma lógica vale para ferramentas.

Uma API aparentemente cara pode reduzir o custo total se devolver em uma chamada todas as informações necessárias e evitar outras cinco consultas, três replanejamentos e várias novas inferências.

Uma ferramenta barata que responde pouco pode produzir o efeito contrário.

Por isso, a recomendação da AWS para uso de ferramentas inclui interfaces que retornem conjuntos completos de dados e aceitem operações em lote quando possível.

O objetivo econômico não deveria ser minimizar cada componente isoladamente.

É minimizar o custo necessário para produzir um resultado útil com qualidade suficiente.

Essa é uma discussão de unit economics aplicada a sistemas agentivos.

Autonomia precisa caber na margem do negócio

Esse problema fica maior quando Agentes deixam os testes e começam a executar milhares de tarefas.

Uma ineficiência que custa alguns centavos durante uma demonstração pode parecer irrelevante.

Multiplique o mesmo comportamento por 50 mil execuções.

Agora ele faz parte da margem do produto.

Quanto maior a frota de Agentes, menos útil fica depender apenas de métricas agregadas da conta de cloud.

A operação precisa conseguir responder perguntas mais específicas:

Quanto custa uma tarefa normal?

Quantos ciclos ela costuma exigir?

Quantas ferramentas são chamadas?

Qual é o custo mediano?

Quanto custam as execuções do percentil 95?

Quantas tarefas chegaram ao limite?

Quantas foram interrompidas por excesso de retries?

Qual ferramenta concentra mais chamadas repetidas?

Quais Agentes consomem mais sem aumentar a taxa de conclusão?

Quais tarefas ficaram mais caras depois de uma mudança de prompt, modelo ou ferramenta?

Essas perguntas conectam engenharia, operação e resultado financeiro.

É nesse ponto que governança de custos deixa de ser uma preocupação exclusiva da infraestrutura.

Ela passa a fazer parte do desenho econômico do produto.

Um orçamento mínimo para qualquer Agente em produção

Antes de aumentar a autonomia de um Agente, vale definir pelo menos oito limites.

1. Máximo de etapas ou ciclos: depois de quantas tentativas o Agente deve parar, mudar de estratégia ou escalar?

2. Máximo de chamadas de ferramenta: quantas consultas externas uma tarefa pode justificar?

3. Máximo de retries: quantas vezes vale insistir quando uma integração está falhando?

4. Tempo máximo: por quanto tempo a execução pode permanecer aberta?

5. Limite de tokens ou contexto: quanto conteúdo pode ser acumulado durante a tarefa?

6. Custo máximo da execução: quanto dinheiro aquela tarefa pode consumir?

7. Limite por período: quanto aquele Agente, cliente ou workflow pode consumir por hora, dia ou mês?

8. Comportamento de saída: ao atingir o limite, o sistema interrompe, reduz capacidade, troca de modelo, entrega resultado parcial ou chama uma pessoa?

Os valores não precisam ser iguais para todos os Agentes.

Um Agente que responde perguntas simples pode trabalhar com limites bastante restritos.

Um Agente encarregado de pesquisa complexa pode justificar mais etapas, mais ferramentas, mais tempo e maior orçamento.

Uma tarefa administrativa repetitiva pode exigir limites rígidos de retries.

Uma operação de alto valor pode aceitar mais custo antes de solicitar intervenção.

O ponto não é encontrar um número universal.

É fazer com que o limite seja uma decisão deliberada.

O verdadeiro problema não é quanto a IA custa

Conforme Agentes ganham capacidade de agir, a discussão sobre custo muda.

Encontrar modelos mais baratos continua sendo útil. Otimizar tokens também. Usar cache também.

Mas isso não resolve a pergunta principal.

Um sistema autônomo precisa conseguir decidir quanto vale gastar tentando resolver um problema e impedir que a execução ultrapasse esse valor sem algum mecanismo de controle.

Um Agente sem orçamento pode continuar raciocinando porque acredita que mais uma etapa será útil.

Pode repetir uma ferramenta porque não percebeu que a informação já estava disponível.

Pode insistir em uma API indisponível.

Pode acumular contexto.

Pode continuar replanejando porque sua condição de conclusão nunca foi satisfeita.

Cada comportamento isolado pode representar apenas alguns centavos.

Em escala, eles se transformam em arquitetura.

Por isso, autonomia deveria vir acompanhada de permissões, autoridade e orçamento.

Antes de colocar um Agente em produção, duas perguntas deveriam ser respondidas:

“O que este Agente consegue fazer sozinho?”

E:

“Quanto tempo, dinheiro e recursos estamos autorizando que ele utilize antes de parar, reduzir capacidade ou pedir ajuda?”

Responder à segunda pergunta é o que transforma autonomia de cheque em branco em capacidade empresarial controlável.

Fontes e referências

• AWS Well-Architected: Agentic AI Lens
• AWS: Automated cost controls with intelligent cutoffs
• AWS: Agent cost governance and continuous optimization
• AWS: Cost-effective tool selection
• AWS: Agent cost visibility and attribution
• Microsoft Learn: Resource Governance and Abuse Prevention
• Microsoft Learn: Agent Looping
• Microsoft Learn: Escolha do agente host