O erro de US$50 em 20 minutos: por que controles de orçamento não são opcionais para agentes de IA

Na terceira semana de operação do nosso pipeline de pesquisa jurídica, um agente analista entrou num ciclo de revisao com o agente revisor. O analista submetia um rascunho. O revisor sugeria alteracoes. O analista revisava. O revisor encontrava novos problemas na revisao. O analista revisava de novo.

Doze iteracoes depois, o output era pior que o rascunho original. E o custo acumulado das chamadas de API era 40x o orçamento previsto para aquela tarefa.

Não houve bug. Nenhum agente falhou. O sistema fez exatamente o que foi instruido a fazer: revisar ate que a qualidade fosse satisfatoria. O problema e que “satisfatorio” nunca chegou, porque cada revisao introduzia novos elementos que o revisor questionava.

Esse tipo de falha não aparece em demos. Aparece em produção, quando agentes operam sem supervisao continua e o único sinal de que algo deu errado e a fatura de API no final do dia.

O custo real de agentes sem controle

Estamos construindo sistemas multi-agente para operacoes empresariais. 10 agentes especializados cobrindo pesquisa jurídica, analise de mercado, compliance, engenharia de dados e estrategia comercial. O sistema roda como um daemon, executando sprints autônomos contra um backlog de tarefas.

O custo operacional alvo e US$20/dia. Nesse orçamento, o sistema completa entre 4 e 8 tarefas por sprint, usando Claude Sonnet 4 (US$3,00/US$15,00 por milhao de tokens) para tarefas de raciocínio pesado e Claude Haiku 4 (US$0,80/US$4,00 por milhao de tokens) para tarefas rotineiras.

Sem controles, esse custo pode escalar de forma imprevisivel por tres razoes:

Loops de revisao sem limite. Um agente gera output, outro avalia, o primeiro revisa. Se não ha limite de iteracoes, o ciclo continua indefinidamente. Cada iteracao consome tokens de input (o contexto acumulado cresce a cada rodada) e tokens de output (a revisao completa e regenerada).

Cascatas entre agentes. Em sistemas onde agentes disparam acoes de outros agentes, uma falha upstream pode gerar retentativas em cascata. O agente A falha, o agente B tenta compensar, o agente C recebe dados inconsistentes e retenta, cada um consumindo chamadas de API.

Tarefas ambiguas sem condição de parada. Quando a instrucao e “pesquise ate encontrar dados suficientes” e os dados não existem, o agente continua pesquisando. Cada tentativa consome tokens. Sem um cap explicito, o agente opera ate que a API retorne um erro de rate limit ou o saldo da conta acabe.

Controle 1: Cap diário com corte automatico

O primeiro controle que implementamos e o mais simples: um teto diário de gastos em dolares.

No nosso sistema, o BudgetGate rastreia cada chamada de API em um banco SQLite. Toda chamada registra o agente que a fez, o modelo usado, os tokens de input e output, e o custo calculado. Antes de cada sprint, o sistema consulta o total gasto no dia.

Cap diário: US$20,00
Gasto ate agora: US$14,32
Disponivel: US$5,68
Status: dentro do orçamento

Quando o gasto do dia atinge o cap, o próximo sprint e cancelado. A mensagem e direta: “Sprint skipped: daily budget exhausted ($20.00 cap reached)”. O sistema não tenta negociar, não executa “so mais uma tarefa”, não faz excecoes. Para.

Esse corte duro ja evitou pelo menos tres incidentes nos primeiros 30 dias de operação. Em todos os casos, o padrão era o mesmo: uma sequencia de tarefas gerou output de baixa qualidade, o sistema tentou reprocessar, e o reprocessamento consumiu mais tokens que a execução original.

US$20/dia pode parecer conservador para um sistema com 10 agentes. E intencional. Num sistema em validacao, o objetivo não e maximizar throughput. E entender o custo por tarefa e calibrar os controles antes de aumentar o volume.

Controle 2: Custo por tarefa e por agente

O cap diário impede que o custo total saia de controle. O rastreamento por tarefa mostra onde o dinheiro esta indo.

O sistema gera relatorios com breakdown por agente:

Budget Report (2025-08-11)
Spent: $16.2340 / $20.00 ($3.7660 remaining)

Per-agent breakdown:
  legal-orchestrator: 12 calls, 45200 in / 8900 out, $7.4820
  corpus-engineer: 6 calls, 22100 in / 5400 out, $3.8730
  market-researcher: 4 calls, 18300 in / 3200 out, $2.9340
  compliance-specialist: 3 calls, 9800 in / 2100 out, $1.9450

Esse nivel de visibilidade revela padroes que um cap agregado esconde. No exemplo acima, o orchestrador consome 46% do orçamento diário. Isso e esperado: ele planeja sprints, coordena equipes e gera relatorios. Mas se o orchestrador comecar a consumir 70% do orçamento, sabemos que ha um problema de design no sistema de planejamento.

Estamos testando alocacoes de orçamento por departamento. A ideia e que cada equipe (validacao de mercado, técnica, funding, compliance) tenha uma fatia do orçamento diário. Se a equipe de mercado consumir toda a sua fatia, as outras equipes continuam operando. Um problema localizado não derruba o sistema inteiro.

Controle 3: Limite de tentativas com bloqueio permanente

O controle que resolveu o problema do loop de revisao foi o mais simples de implementar: um limite de 3 tentativas por tarefa.

O fluxo funciona assim:

1. O agente tenta executar a tarefa.
2. O output passa por um gate de qualidade (50+ padroes de detecção de lixo + pontuação de conteúdo de 0 a 1).
3. Se o output e rejeitado (pontuação abaixo de 0,4 ou padrão de lixo detectado), a tarefa volta para a fila.
4. Na próxima execução, o sistema verifica o contador de tentativas.
5. Se o contador atingiu 3, a tarefa e marcada como “blocked” e removida da fila ativa.

Tarefas bloqueadas escalam para revisao humana. O sistema não tenta resolver o que não conseguiu resolver em 3 tentativas. Essa regra existe porque observamos que, se um agente falha 3 vezes na mesma tarefa, a quarta tentativa quase nunca produz resultado diferente. O problema geralmente esta na tarefa (ambigua, dependente de dados externos indisponiveis, ou mal definida), não na execução.

Nos primeiros 37 tasks do backlog jurídico, 33 foram completadas com sucesso. Das 4 bloqueadas, todas falharam por dependencia de financiamento externo. O limite de tentativas não bloqueou nenhuma tarefa viável. Bloqueou apenas as que realmente não podiam ser completadas com os recursos disponiveis.

Controle 4: Detecção de output lixo

Antes de contar tentativas, o sistema precisa identificar quando o output e lixo. Construimos duas camadas de detecção.

A primeira camada e uma lista de 50+ padroes textuais. Cada padrão foi adicionado depois de uma falha real. Exemplos:

• “as an AI, I cannot” (recusa do modelo)
• “let me search for” (agente planejando em vez de executando)
• “no results found” (busca vazia apresentada como resultado)
• “I don’t have access to” (reclamacao de permissao)
• “the next step would be” (planejamento sem execução)
• “function_call” (agente tentando invocar tools quando esta em modo synthesis-only)

A segunda camada e uma pontuação de qualidade de 0 a 1. A função analisa:

• Tamanho: output com menos de 30 palavras recebe 0,1. Com mais de 100 palavras, +0,1. Com mais de 300, +0,1.
• Marcadores de substancia: presenca de valores em dolares, porcentagens, URLs, datas, tabelas formatadas e headers estruturados. Cada marcador adiciona 0,05, ate um bonus maximo de 0,3.
• Penalidade por planejamento: se o output contem 3 ou mais frases como “we should”, “the plan is”, “steps to take”, a pontuação e reduzida em 0,15.

Qualquer output com pontuação abaixo de 0,4 e rejeitado. Na prática, esse threshold elimina output que parece plausível na superficie mas não contem informação concreta. Um agente que produz 500 palavras de analise de mercado sem um único numero, data ou fonte especifica recebe uma pontuação de 0,3 e volta para reprocessamento.

Controle 5: Circuit breaker entre sprints

Cada sprint consome entre 2 e 4 tracks de execução. Entre cada track, o sistema verifica o orçamento remanescente. Se o cap foi atingido durante o track anterior, o próximo track e cancelado com status “skipped_budget”.

Esse e o circuit breaker: a capacidade de parar no meio de um sprint quando os números não fecham. Sem ele, um sprint com 4 tracks executaria todos os 4 mesmo que o primeiro tenha consumido 80% do orçamento diário.

O sistema também reseta automaticamente tarefas que ficaram presas em “in_progress” de sprints anteriores que falharam. Se o daemon cair no meio de um sprint (crash, timeout de API, reinicio do servidor), as tarefas travadas voltam para “pending” no próximo ciclo. Sem esse mecanismo, tarefas fantasmas ocupariam slots no backlog indefinidamente.

O que os números mostram

Resultados iniciais dos primeiros 30 dias de operação com todos os controles ativos:

Metrica	Valor
Tarefas completadas	33 de 37
Tarefas bloqueadas (limite de tentativas)	4
Tarefas bloqueadas por output lixo	0 (todas as rejeicoes foram resolvidas dentro de 3 tentativas)
Custo médio por dia	US$14-18
Custo médio por tarefa concluida	US$6-9
Sprints cancelados por orçamento	3
Incidentes de custo descontrolado	0 (após implementação dos controles)

O custo de US$6-9 por tarefa concluida substitui trabalho que custaria US$50-200 se feito por um analista junior (considerando salario, gestao, infraestrutura). O ROI e claro. Mas so existe porque os controles mantem o custo previsivel.

Sem os controles, o incidente dos 40x teria acontecido repetidamente. Não por ma-fe do sistema. Por ausencia de limites explícitos.

Implementando controles na prática

Para quem esta construindo sistemas multi-agente em produção, os controles minimos que estamos validando:

Dia 1: Cap diário em dolares. Qualquer valor. O numero exato importa menos que a existencia do limite. Ajuste depois de observar o padrão real de consumo.

Semana 1: Rastreamento por agente e por tarefa. Registre cada chamada de API com o nome do agente, o modelo, os tokens e o custo. Sem essa visibilidade, otimizar custo e impossivel.

Semana 2: Limite de tentativas. 3 e um numero razoavel. Tarefas que falham 3 vezes precisam de intervenção humana, não de uma quarta tentativa.

Semana 3: Detecção de output lixo. Comece com 10-15 padroes baseados nas falhas reais do seu sistema. A lista vai crescer organicamente. A nossa tem 50+ e continua aumentando.

Semana 4: Circuit breakers entre etapas de execução. Verifique orçamento antes de cada etapa. Pare no meio se necessário.

Nenhum desses controles e sofisticado. São verificacoes simples com logica condicional basica. A sofisticacao esta em ter todos operando simultaneamente, com logging suficiente para diagnosticar problemas após o fato.

O que vem depois

Estamos trabalhando em tres extensoes dos controles atuais:

Detecção de anomalia de gasto. Hoje, o sistema so reage quando o cap e atingido. Estamos construindo alertas para quando o custo por tarefa desvia mais de 2x da media histórica. Se uma tarefa que normalmente custa US$5 esta em US$12 após a segunda tentativa, o sistema deveria sinalizar antes da terceira.

Orçamento por departamento. Em vez de um único cap diário, cada equipe de agentes recebe uma alocacao proporcional. A equipe de mercado recebe 30%, a técnica recebe 35%, funding recebe 20%, compliance recebe 15%. Falha em uma equipe não compromete as outras.

Previsao de custo pre-execução. Antes de iniciar um sprint, estimar o custo provavel baseado no histórico de tarefas similares. Se a previsao excede o orçamento disponivel, reduzir o numero de tracks ou adiar tarefas mais caras.

O ponto central e que controle de custo para agentes de IA não e uma feature “nice to have” que você adiciona quando o sistema esta maduro. E infraestrutura basica que precisa existir antes da primeira execução autônoma. O custo de não ter controles não e uma fatura alta no final do mes. E a impossibilidade de confiar no sistema para operar sem supervisao constante. E se você precisa supervisionar constantemente, o sistema não esta realmente autônomo.

---

Synaptic transforma empresas em organizações AI-native. Começamos onde a demo termina. synaptic.so