Como Agentes de IA estão economizando milhares de dólares em assinaturas de software para startups

"Cuidado com as pequenas despesas. Um pequeno vazamento afunda um grande navio." — Benjamin Franklin

Existe uma versão da gestão financeira de startups que a maioria dos fundadores conhece intimamente. Não é dramática. Não aparece nos relatórios para o conselho. Ela aparece em uma fatura de nuvem que ninguém questionou, em uma licença que alguém que saiu há quatro meses ainda está tecnicamente usando, em uma renovação que foi renovada automaticamente por dezoito por cento a mais porque ninguém teve tempo de contestar.

Startups são extraordinariamente boas em agir rápido. Elas são notavelmente ruins no trabalho pequeno, entediante e caro de gerenciar o que estão realmente gastando. Não porque os fundadores sejam imprudentes — mas porque sua atenção é o recurso mais escasso que possuem, e ninguém descobriu como automatizar a negociação.

Os consumidores ganharam ferramentas que encontram e cancelam suas assinaturas esquecidas. As startups não ganharam nada.

A equipe por trás da LEGR decidiu que esse era o estado errado do mundo.

O problema que eles viveram primeiro

A inspiração não veio de pesquisas. Veio de gerir uma startup.

Chamadas de modelo erradas executando a opção mais cara quando uma mais barata teria feito o mesmo trabalho. Licenças fantasmas de pessoas que saíram há meses. Assinaturas que ninguém lembrava ter feito. Renovações que aumentaram automaticamente porque ninguém tinha três dias para negociar com um fornecedor.

A percepção não foi de que as startups precisavam de um painel melhor. Painéis já existem. Eles são ignorados, porque ver um problema e resolver um problema são duas coisas completamente diferentes. O que a equipe queria construir não era uma ferramenta que mostrasse o desperdício. Era algo que fizesse algo a respeito — redigisse o e-mail, conduzisse a negociação, sobrevivesse ao fim de semana e enviasse a você uma única mensagem quando tudo estivesse resolvido.

A analogia a que eles sempre voltavam: um bom CFO não entrega um relatório e espera. Um bom CFO resolve o problema, mantém você informado nos momentos que importam e fecha o ciclo.

LEGR é o CFO que ninguém podia contratar antes que isso fosse possível de construir.

O que a LEGR realmente faz

O produto tem três funções.

1. A primeira é detectar o desperdício em gastos com IA — as decisões de roteamento de modelos que se acumulam invisivelmente. Chamadas caras sendo executadas onde um modelo mais barato teria produzido o mesmo resultado. Créditos ociosos. Trabalhos em lote esquecidos. Padrões que ninguém notou porque vivem em um arquivo de log, não em uma conversa.

2. A segunda é eliminar a dispersão de SaaS. Toda startup acumula ferramentas. Algumas dessas ferramentas acumulam licenças e assinaturas que sobrevivem às pessoas ou fluxos de trabalho que deveriam servir. A LEGR as encontra — cruzando o que as faturas dizem com o uso real — e então faz o que nenhum painel jamais fez: negocia a renovação, de forma autônoma, durante quantos dias forem necessários.

3. A terceira é a conformidade de despesas — pontuando cada transação em relação à política, permanecendo em silêncio quando tudo está em ordem, escalando apenas quando algo precisa de um humano.

A experiência para um fundador é assim: uma mensagem chega. "Encontrei uma renovação chegando. Negociar? S/N." Ele digita S. Três dias depois, um acompanhamento: "Fechado. US$ 4.140 economizados."

Três palavras digitadas. Quarenta horas de vai-e-vem resolvidas. Uma mensagem enviada.

O pensamento por trás disso

A questão arquitetural que a equipe teve que responder foi esta: alguns trabalhos levam segundos. Outros levam dias. Esses não são o mesmo problema e não devem ser tratados da mesma maneira.

Verificar se uma transação viola uma política é uma tarefa rápida e sem estado. Você a executa, obtém uma resposta e está feito. Mas negociar uma renovação de software não é sem estado. Abrange dias. O fornecedor responde em seu próprio ritmo. Cada resposta muda o que a próxima mensagem deve dizer. O sistema precisa sobreviver a ser reiniciado no meio da terceira rodada.

A equipe construiu uma separação clara entre esses dois tipos de trabalho. Tarefas rápidas e limitadas são executadas como chamadas curtas. Negociações de longa duração vivem como processos persistentes — cada um com sua própria memória, seu histórico de thread, seu próprio entendimento do que foi usado como vantagem e o que resta.

Cada negociação ativa carrega um arquivo de estado. Rodada atual. Histórico completo de mensagens. Que argumentos já foram feitos. Quando um fornecedor respondia "deixe-me verificar com meu gerente", o sistema tinha que classificar isso corretamente — não como aceitação, não como rejeição, mas como um adiamento — e responder com paciência. Esse classificador, a equipe disse, levou mais iterações do que quase qualquer outra coisa na construção.

O problema mais difícil não foi técnico. Foi a moderação.

A primeira versão da interface enviava uma mensagem a cada evento. Em uma hora, tornou-se ruído — a coisa que você para de ler porque sempre tem algo a dizer. A solução foi um sistema de mensagens de três níveis: silencioso quando as coisas estão funcionando, informativo quando há um desenvolvimento que vale a pena saber e um ping real apenas quando uma decisão humana é realmente necessária. Saber quando não falar acabou sendo a escolha de design mais importante do produto.

Do que eles mais se orgulham

O momento que demonstraram no palco: matar um processo de negociação em execução no meio da rodada, reiniciá-lo, vê-lo ler seu arquivo de estado e continuar exatamente de onde parou. O estado persistente não é uma funcionalidade que eles descreveram. É uma que eles provaram em tempo real.

E o ciclo de ponta a ponta — um fundador digitando três palavras, um sistema rodando por dias, uma única mensagem de fechamento. Isso não é um fluxo de demonstração. É o produto funcionando como planejado.

105 participantes. 38 projetos. 36 horas. Temos acompanhado o que saiu daquele fim de semana porque a qualidade do pensamento continuou merecendo atenção.

Vale dizer também: conhecemos o problema da dispersão de SaaS por dentro. A Enter foi construída especificamente para que construtores não precisassem de sete ferramentas para lançar um produto — o editor de design, o backend, o banco de dados, o deploy, a camada de colaboração, tudo em um só lugar. Uma assinatura. Uma plataforma. A ironia de cobrir um projeto que caça assinaturas esquecidas não nos escapa.

A LEGR ganha seu lugar na série porque o problema é real, a solução é específica e a equipe entendeu algo importante: a parte difícil de construir um agente autônomo não é a automação. É saber quando recuar e deixar um humano entrar. A moderação como princípio de design. Isso é mais raro do que parece.

O que vem a seguir

A curto prazo: um processo que faz login nos painéis administrativos dos fornecedores diretamente e executa cancelamentos, completos com recibos em captura de tela. Negociações paralelas que compartilham uma camada de inteligência comum — uma vitória em uma negociação tornando-se alavanca na próxima. Um modelo persistente das preferências de cada fundador, tolerância ao risco e runway de queima.

A aposta de longo prazo: finanças são o ponto de entrada. A mesma arquitetura — agentes rápidos para tarefas limitadas, processos persistentes para trabalhos que levam dias — aplica-se a operações jurídicas, gestão de fornecedores, conformidade de RH. A equipe descreveu isso como a primeira ferramenta que uma startup conecta e a última ferramenta financeira de que precisam antes de poderem contratar o serviço profissional real.

Esse tipo de ambição é exatamente para o que servem os finais de semana em Princeton.

Perdeu os volumes anteriores? → Vol. 1 — Heritage in Pixels → Vol. 2 — Terra Zone AI *→ Vol. 3: *reAgent *→ Vol. 4: *TaleTailor