Quando o Agente Propõe Construir ou Contornar: Um Caminho de Aprovação para Compras

Jason Lemkin, do SaaStr, escreve que “uma estimativa que recebemos coloca nosso custo em até US$ 240.000 por ano” para acesso de API do agente. É uma única estimativa, de um fornecedor sem nome, para um agente que faz de 35.000 a 40.000 chamadas de API por dia. A equipe por trás dele tem 3 humanos e mais de 21 agentes.

A resposta do agente foi parar de pagar pelo acesso e espelhar o sistema de registro em uma instância Postgres de US$ 5. O título do texto carrega esse número. Pelo próprio enquadramento do autor, os US$ 5 nunca foram orçados, e ele admite que o espelho “ficaria fora de sincronia”.

Lemos isso como um evento de compras. A proposta veio de um agente e está entre três movimentos: comprar o acesso, construir um substituto ou contornar a porta do fornecedor.

Duas propostas, um padrão

A primeira proposta é o espelho. O SaaStr também descreve o mercado em poucas linhas. A Salesforce está “lançando agora, com um banner”. A Atlassian “já fez”. Sobre a cobrança da HubSpot, o autor escreve que “até agora parece voltada aos agentes próprios deles”. É a leitura dele de um movimento de preço, não uma política publicada pela HubSpot, e a repassamos como dele.

Ele também descreve um problema anterior com limites de API. O Marketo “caía para nós depois de 10 ou 20 minutos por dia por causa dos limites de API”, e por isso a equipe deixou o Marketo. Os limites de API já tinham forçado uma migração nessa equipe.

A segunda proposta é a construção. Em outro texto, o SaaStr diz que seu agente empurrou a equipe a trocar o Calendly por uma ferramenta de agendamento, montada no Replit em “cerca de 20 minutos”. O raciocínio do próprio texto é de custo: se a construção tivesse sido estimada em duas semanas, a equipe diz que teria ficado com o Calendly.

Essa é a frase útil. O raciocínio da equipe é de custo: mude a estimativa e, pelo relato da própria equipe, a decisão muda junto.

O que a evidência é

Os dois textos são o relato de um operador sobre a própria equipe. O texto do Calendly não traz reservas, conversão nem custo, e não encontramos nada disso no primeiro texto, então não temos dados de resultado de nenhuma das decisões. Os US$ 240.000 são uma estimativa. A medição que o texto do Calendly traz é que o Zapier estava “perdendo silenciosamente cerca de 20% dos nossos cadastros antes de chegarem ao Salesforce”, e o autor não informa o método.

Há também uma questão de divulgação. O autor promove um produto próprio de agentes, e não encontramos divulgação dessa relação nas páginas que lemos. Nenhuma das páginas mostra data de publicação visível. Tratamos ambas como de outubro de 2026, o que os metadados da página indicam.

Portanto isto não prova que agentes compram bem ou constroem bem. É o registro do que um agente propõe quando encontra uma barreira de preço e uma assinatura, e de como uma equipe respondeu.

O gate é o artefato

A parte mais reutilizável é uma frase do texto do Calendly: “Um agente querer construir algo é um mau motivo para construir. Agentes gostam de construir.” A resposta do autor são quatro perguntas para qualquer construção proposta por agente:

O que isso faz que o fornecedor não faz?
Uma integração via API cobriria a maior parte?
De quais dados precisa que só nós temos?
Quanto tempo leva, e o que acontece se quebrar?

A pergunta quatro é onde a decisão do Calendly se resolveu. Uma construção de 20 minutos e uma de duas semanas recebem respostas diferentes. A pergunta dois é onde a proposta do espelho deveria ter sido testada, porque acesso de API é aquilo para que servia a estimativa de US$ 240.000.

O gate é útil porque é curto o bastante para rodar em toda proposta. Tem um limite: foi escrito para construções. O espelho é uma construção de outro tipo, já que copia o sistema de registro para evitar uma cobrança.

Onde nós o estenderíamos

O argumento desta seção é nosso e a fonte não o faz.

Um espelho de um sistema de registro cria uma segunda cópia que alguém precisa manter correta. O autor admite que ela desvia. Duas cópias que discordam são um problema de governança antes de serem um problema de custo: um relatório feito sobre o espelho e outro feito sobre o original podem ser ambos defensáveis e ambos errados. A linha de US$ 5 esconde isso.

Acrescentaríamos duas perguntas para qualquer proposta que contorne os termos de acesso do fornecedor em vez de substituí-lo:

Qual cópia é a autoritativa quando as duas divergem, e quem é responsável pela reconciliação?
Os termos do fornecedor permitem a cópia, e quem os lê antes de o agente construí-la?

Não afirmamos saber o que os termos desses fornecedores dizem. Os textos não informam. Nada neles mostra o agente perguntando, e o gate de quatro perguntas não o obriga a perguntar.

Também acrescentaríamos um passo extra antes das perguntas: um aprovador nomeado. O gate só funciona se um humano com autoridade de orçamento vê a proposta. Um agente que origina a proposta e a julga pelo próprio gate é um proponente aprovando a si mesmo. Leitura relacionada: Seu Agente de Código Aprovou o Próprio Estouro de Orçamento em 97% das Vezes, Quando Seu Próximo Cliente É um Algoritmo, Três Preços para Um Agente e Quando o Agente é o Próprio Departamento de Compras.

O que um caminho de aprovação contém

Propomos cinco elementos, e os marcamos como nossos:

Origem. Registrar que a proposta veio de um agente, e de qual.
Categoria. Comprar, construir ou contornar. Cada uma pede um revisor diferente.
As quatro perguntas, respondidas por escrito antes de o trabalho começar.
Uma estimativa produzida por alguém que não seja o agente, porque a conclusão do próprio SaaStr dependeu de uma.
Um aprovador nomeado e uma data de revisão. Uma construção que você mantém precisa ser julgada de novo contra o fornecedor que abandonou.

Nada disso exige ferramenta nova. Um modelo de ticket resolve.

Faça isto agora

Pegue a última sugestão originada por agente na sua equipe que envolveu um fornecedor: uma assinatura a substituir, uma ferramenta a construir, uma integração a pular. Se nenhuma está registrada, esse é o seu achado: as propostas não têm registro para revisar.

Passe-a pelas quatro perguntas, some as duas perguntas de contorno e anote quem aprovou e com base em qual estimativa. Depois faça disso o modelo da próxima. Faça antes da próxima proposta do agente, porque um agente pode originar uma proposta dessas a qualquer momento, e o caminho de aprovação sai mais barato quando é construído antes de uma delas precisar dele.

Fontes

SaaStr. “We Got a $240,000 Estimate for Agent API Access. Our Agent Suggested a $5 Postgres Instance.” Outubro de 2026.
SaaStr. “We Vibe Coded Our Own Calendly. Our AI Agent Pushed Us To Do It, and It Was Right.” Outubro de 2026.

A Victorino ajuda equipes a desenhar caminhos de aprovação para decisões de compra, construção e contorno originadas por agentes: contato@victorino.com.br | www.victorino.com.br