A primeira feature de que todo agent que gasta dinheiro precisa é um freio

O primeiro agent que você deixar tocar num orçamento vai, mais cedo ou mais tarde, ficar preso num canto que você não previu, decidir que a saída é mais uma chamada de API, e então fazer essa chamada alguns milhares de vezes seguidas. Não vai parecer imprudente por dentro. Cada passo é localmente razoável: a última tentativa quase funcionou, então tente mais uma vez. A conta é a soma de uma longa sequência de decisões pequenas e sensatas que ninguém estava vendo se acumular.

Esse é o modo de falha que ninguém faz demo. A demo mostra o agent reservando o voo. Não mostra a noite em que tentou reservar o voo quatrocentas vezes.

Um agent que pode gastar tem que se deter antes da próxima chamada quando o custo cruza uma linha.

Este post é sobre por que essa única frase é o verdadeiro pré-requisito para confiar dinheiro a um agent, e por que construímos o freio antes de construir quase qualquer coisa que precisasse de um.

A versão ingênua: confie no loop para parar sozinho

A forma óbvia de rodar um agent que gasta é dar a ele o objetivo, dar as tools, e confiar no loop para saber quando terminou. Plan, act, observe, repeat. Quando a tarefa termina, o loop sai. Esse é o design inteiro, e num dia bom é elegante.

Funciona até o ponto em que a tarefa não é finalizável.

Uma tool retorna um resultado levemente errado. O agent lê, decide que está perto, e tenta de novo com um pequeno ajuste. O próximo resultado também está levemente errado, então ele ajusta de novo. Nada aqui é um bug no sentido usual, sem crash, sem exception, sem trace vermelho. O agent está fazendo exatamente o que lhe disseram: continue até o objetivo ser cumprido. O problema é que o objetivo não pode ser cumprido, e “continue” não tem opinião sobre custo. Cada retry é uma chamada real a um provider real que cobra dinheiro real, e o loop não tem ideia de que o relógio está rodando.

Essa é a parte que as pessoas perdem quando raciocinam sobre agents como se fossem chatbots. Um chatbot que entra em loop só desperdiça o próprio tempo. Um agent que entra em loop segurando um cartão de crédito, uma API key paga, ou uma conta de cloud está convertendo um erro de lógica diretamente numa cobrança. O mesmo retry que não custa nada a um chatbot custa a um agent que gasta um item na fatura, e o item na fatura compõe, silenciosamente, no escuro, enquanto o loop se parabeniza pela própria persistência.

Você não percebe em testes, porque em testes as tarefas têm sucesso. Você percebe na primeira vez que uma tarefa real não consegue.

Por que “definir um cap de iterações máximas” não é a resposta

O instinto, depois que você sente isso, é parafusar um contador. Deixe o agent dar vinte passos, depois mate. Tosco, mas para a disparada, e vinte certamente é suficiente para qualquer tarefa razoável.

Não é, e a razão merece um momento de reflexão.

Uma contagem de passos é um proxy de custo, e é um proxy ruim. Um passo pode ser uma única classificação barata. O próximo passo pode ser uma geração longa contra um modelo caro, ou uma tool call que se ramifica numa dúzia de sub-chamadas, ou uma única requisição que processa um documento grande e cobra de acordo. Vinte passos baratos e vinte passos caros são o mesmo número para o contador e números absurdamente diferentes na fatura. Defina o cap baixo o suficiente para ser seguro no caminho caro e você estrangula toda tarefa longa legítima. Defina alto o suficiente para deixar o trabalho real terminar e você deu à disparada cara espaço de sobra para correr.

Uma contagem de passos diz quantas vezes o agent agiu. Não diz nada sobre o que essas ações custaram.

Há um problema mais profundo escondido sob o raso. Um cap de iterações máximas para o agent depois do fato, é um corpo encontrado no pé da escada, não um corrimão no topo. O dano já está na fatura quando o contador dispara. O que você quer de verdade não é um limite de quantas vezes o agent se move, mas uma checagem que roda antes de cada movimento e faz uma pergunta diferente: não “já fizemos isso vezes suficientes?”, mas “podemos bancar fazer isso nem que seja mais uma vez?”.

Essa pergunta é o freio. E o freio mede dinheiro, não movimento.

Nossa versão: o freio roda antes da chamada, e mede dinheiro

O mecanismo é simples, e sua simplicidade é o ponto. Antes de o agent fazer qualquer chamada que custa algo, um pequeno portão roda primeiro. Ele olha quanto este run já gastou, olha o teto que recebeu, e pergunta se a próxima chamada cabe por baixo. Se cabe, a chamada passa. Se não cabe, a chamada nunca acontece. O agent se detém, bem ali, antes do gasto, não depois.

Três coisas têm que ser verdade para esse portão valer alguma coisa, e cada uma é um lugar onde as versões ingênuas erram.

A primeira é que o medidor tem que ser real. Você não pode frear contra um número que não tem, então o agent tem que saber seu custo corrente a cada passo, gasto efetivo, acumulado conforme avança, não uma estimativa que inventou no início. Cada chamada que custa dinheiro reporta o que custou, e o total mora em algum lugar onde o portão consegue lê-lo. O número tem que ser verdadeiro, porque um freio calibrado contra um medidor falso para na hora errada ou não para.

A segunda é que a checagem acontece antes da chamada, nunca depois. Essa é a diferença inteira entre um freio e um post-mortem. Um portão que roda depois da chamada já deixou o dinheiro sair pela porta; tudo o que pode fazer é anotar o que falhou em prevenir. O portão tem que se sentar na frente da coisa cara, de modo que cruzar a linha significa que a próxima chamada simplesmente não dispara. Prevenção, não contabilidade.

A terceira é que o limite é um teto real que o run carrega consigo, não uma sugestão num prompt. “Tente não gastar demais” não é um orçamento, é uma esperança, e o loop que está três mil retries adentro não está em condição de honrar uma esperança. O cap é um número rígido anexado ao próprio run, imposto pelo portão, não pelas boas intenções do agent. O agent pode querer fazer a próxima chamada o quanto quiser. Se a próxima chamada cruza a linha, ele não pode.

Junte essas três e a disparada da abertura vira um não-evento. O agent tenta seu retry sem esperança. O portão soma o que o run gastou, vê que está no teto, e recusa a chamada. O loop que teria feito quatrocentas tentativas faz as que o orçamento podia bancar e então para, limpo, num número, com a razão anotada, em vez de parar quando alguém percebe a fatura.

O freio também é um contrato, não só um disjuntor

Aqui está a parte que transforma uma feature de segurança em algo sobre o qual você pode de fato construir um negócio.

Um orçamento que para uma disparada é útil. Mas o mesmo portão que previne o desastre também torna o agent previsível, e previsibilidade é o que deixa um humano entregar as chaves de início. Se cada run carrega um teto rígido, então o pior caso é conhecível com antecedência. Você não está assinando um cheque em branco e torcendo para o loop se comportar. Você está autorizando um valor limitado, e o sistema garante o limite, não confiando no agent para ser cuidadoso, mas recusando deixá-lo exceder o número, não importa quão confiante ele fique.

Esse é um tipo de confiança diferente de “o modelo é esperto o bastante para não desperdiçar dinheiro.” Modelos espertos ainda ficam presos. Prompts cuidadosos ainda são ignorados três mil iterações adentro de um loop. A coisa em que você de fato pode confiar é o portão que roda toda vez e não tem sentimentos sobre a tarefa, ele não fica otimista, não acha que a próxima chamada vai ser a que funciona, ele só compara dois números e decide.

Você não deixa um agent que gasta seguro tornando-o mais sábio. Você o deixa seguro dando a ele um número que ele não pode cruzar.

E uma vez que o teto é real, ele compõe para cima. Um único run carrega um cap. Um lote de runs carrega a soma dos seus. Uma fleet de agents trabalhando em paralelo durante a noite carrega um orçamento entre todos eles, porque cada um deles está freando contra o mesmo tipo de portão, e um teto que vale para um vale para mil. A disciplina que impede um único agent de entrar em loop até uma fatura surpresa é a mesma disciplina que deixa uma fleet inteira rodar enquanto você dorme. Você não supervisiona o gasto assistindo a ele. Você o limita antes de começar e deixa o portão segurar a linha.

Por que construímos o freio primeiro

A ordem importa, e é um pouco contraintuitiva, então vale dizer claramente.

Você pode esperar que a capacidade de gastar venha primeiro e a segurança venha depois, shipa o agent que reserva o voo, depois adicione o orçamento uma vez que esteja provado. Fizemos o contrário. O freio veio antes do gasto, porque um agent que pode gastar sem freio não é uma versão menor do seguro. É uma coisa diferente, mais perigosa, e você não consegue retrofitar a disciplina num sistema que foi projetado assumindo que não precisava dela. O medidor, o portão pré-chamada, o teto rígido, essas não são features que você adiciona a um agent que gasta. São a fundação sobre a qual um agent que gasta tem que se apoiar antes de você deixá-lo perto de qualquer coisa que cobre.

Toda tool de gasto que conectamos herda essa fundação. Uma nova capacidade não pode pular o portão por ser nova. Ela freia contra um teto de custo do mesmo jeito que a primeira freou, porque a regra não é “esta tool específica é cuidadosa.” A regra é que nada que custa dinheiro roda sem um freio na frente.

A virada: o freio é na verdade sobre quem pode dormir

Um impositor de orçamento soa como um item numa spec. Não é. É a razão pela qual uma pessoa consegue fechar o laptop.

O que você está de fato comprando, quando põe um teto rígido na frente de cada gasto, é a capacidade de ir embora. De entregar uma tarefa real com um custo real a um sistema e não ficar acordado se perguntando se um loop preso está queimando silenciosamente o orçamento do mês enquanto o escritório está escuro. O medo que impede as pessoas de delegar a agents nunca foi que o agent seria burro. É que o agent seria caramente burro, de um jeito que ninguém pegou até a fatura chegar. Um agent que pode gastar tem que se deter antes da próxima chamada quando o custo cruza uma linha, e a razão pela qual essa única frase vale um post inteiro é que ela é a diferença entre entregar uma tarefa e entregar sua paz de espírito. O freio tira esse medo específico da mesa, não prometendo que o agent não vai ficar preso, mas garantindo que quando ficar, o pior que pode custar é um número com o qual você já concordou.

Essa é a coisa silenciosa sob o mecanismo. Um medidor, um portão e um teto são engenharia. Mas o que eles somam é uma pessoa confiando dinheiro a uma máquina e ainda assim dormindo a noite inteira, e essa confiança não é uma feature que você liga. Ela é conquistada, um run limitado de cada vez, por um sistema que nunca uma única vez gastou mais do que tinha permissão.

---

É isso que estamos construindo na Apollo Space: um sistema operacional onde todo agent que pode agir também sabe quando parar, onde o orçamento não é um aviso que você lê depois do fato, mas uma parede que a próxima chamada acerta antes de o dinheiro sair. Se você já descobriu o que um processo preso lhe custou lendo a fatura, você já sabe por que o freio vem primeiro.