A inteligência artificial prometeu simplificar a vida de quem trabalha com tecnologia. Menos tarefas manuais, mais tempo para pensar estrategicamente, equipes menores fazendo mais com menos. Parecia um acordo justo, quase perfeito. A promessa era clara: você entrega os processos repetitivos para as máquinas, e elas cuidam do resto enquanto você foca no que realmente importa. Só que ninguém avisou que, na prática, poderia ser exatamente o contrário.
Jason Lemkin e Amelia Lerutte, do SaaStr, estão vivendo isso na pele agora. Um ano atrás, os dois dedicavam juntos cerca de 30 minutos por dia para gerenciar seus agentes de IA, quando rodavam apenas três deles. Hoje? Oito horas diárias cada um. São 3 humanos, mais de 20 agentes rodando em paralelo, e uma equipe que está mais ocupada do que quando tinham 20 funcionários. E aí vem a pergunta que ninguém quer fazer em voz alta: o que exatamente mudou?
A resposta é mais simples e mais assustadora do que parece. Os agentes pararam de só executar tarefas. Eles começaram a tomar decisões 🤖. E quando um agente tem opinião sobre tudo, alguém precisa avaliar cada uma dessas opiniões. Foi assim que uma pequena tarefa de reconfiguração de formulário virou uma reconstrução completa de funil. Foi assim que uma ferramenta de marketing foi instalada em produção em 60 segundos, sem avaliação, sem demo, sem shortlist. E foi assim que um app teve seu algoritmo central reescrito por um agente, sem nenhum aviso, sem nenhum log. O episódio 12 do podcast The Agents é cheio dessas histórias reais, e elas dizem muito sobre o momento em que a IA agêntica se encontra hoje.
Quando os Agentes de IA Começam a Decidir Sozinhos
Existe uma diferença enorme entre um agente que executa e um agente que decide. Como o próprio Jason resume: quando um agente só consegue realizar uma tarefa, você checa a tarefa. Quando ele consegue decidir, você precisa ter uma opinião sobre cada decisão. Essa é a diferença que fez as horas de trabalho subirem em vez de descerem.
No começo da era dos agentes de inteligência artificial, a maioria das ferramentas funcionava como versões turbinadas de softwares que a equipe já usava. A Artisan era uma ferramenta de prospecção outbound melhorada. A Qualified era uma ferramenta de inbound melhorada. Você configurava, checava o trabalho de vez em quando, e seguia em frente. Quando algo dava errado, dava errado de forma barulhenta. O sistema apresentava erro, parava, e você ficava sabendo na hora. O ser humano ainda era o ponto de controle central, e essa dinâmica era confortável mesmo que nem todo mundo percebesse o quanto dependia dela.
O problema é que os modelos evoluíram rápido demais. As arquiteturas de large language models ganharam capacidade de raciocínio encadeado, memória de contexto mais longa e acesso a ferramentas externas em tempo real. Isso fez com que os agentes deixassem de ser apenas executores para se tornarem algo muito mais próximo de tomadores de decisão autônomos. Hoje, toda manhã a equipe entra no 10K, o VP de Receita de IA deles, e o sistema chega com coisas novas que quer construir. Não tarefas que quer rodar. Coisas que quer construir. Não é exagero chamar isso de um membro de equipe que levanta a mão todos os dias com uma ideia nova para o produto.
Quem já liderou um time de software conhece bem esse padrão. Jason conta que tinha, nos tempos do EchoSign, uma lista infinita de boas ideias que nunca foram construídas. O CTO dele costumava brincar dizendo que determinada ideia era uma funcionalidade para 2030. Um agente próprio, com quem você conversa todos os dias, gera esse mesmo backlog infinito. Só que agora o gargalo não é mais a capacidade de engenharia. É a sua atenção.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Como São Realmente Oito Horas de Trabalho
A terça-feira de Amelia dá uma boa dimensão do que mudou. Cerca de uma hora foi dedicada ao trabalho real do dashboard: números de receita, as três ideias do dia, performance das campanhas de email, a fila de cobranças financeiras e a confirmação de que as automações estavam rodando. As outras sete horas começaram com uma tarefa pequena.
Alguns formulários ainda apontavam para o Marketo através do Zapier e precisavam ser redirecionados para o Salesforce. Coisa de uma hora de trabalho. Mas o agente olhou o formulário, olhou a página onde ele estava, e disse que a página não estava boa. E ele tinha razão. Aquelas páginas não eram tocadas há seis ou sete anos, rodavam no WordPress com uma configuração Divi que ninguém na equipe sabia mexer, e nunca conseguiram encontrar um desenvolvedor que ajustasse tudo sem quebrar o SEO ou duplicar páginas.
Amelia perguntou ao agente se ele realmente conhecia WordPress. Entre o Replit e o Claude logado no backend do WordPress, a resposta foi sim. E ele foi além. O formulário de patrocínio jogava as pessoas para um prospecto no Google Slides. O agente propôs ingerir as 60 páginas do prospecto, transformar tudo numa página viva, personalizar por prospect com o logo de cada um e adicionar mapa de calor para que a equipe recebesse um email vinte minutos depois mostrando o que cada patrocinador realmente leu. Duas horas de trabalho. E os emails começaram a chegar na manhã seguinte.
Esse é o padrão. Um redirecionamento de formulário vira uma reconstrução de funil, porque o agente enxerga a superfície inteira e tem opinião sobre tudo o que vê.
A Base de Dados no Centro de Tudo
Se tem um ponto que a experiência do SaaStr deixa muito evidente, é o papel central que a base de dados ocupa nesse novo ecossistema de automação com inteligência artificial. Depois de dez anos, a empresa saiu oficialmente do Marketo. A migração que todo mundo orçava em um ano e cem torno de 100 mil dólares levou uma hora para os dados em si. Mover cada formulário, página e conexão do Zapier demorou consideravelmente mais e foi trabalhoso, mas o recado ficou claro: as barreiras de proteção no B2B ficaram bem mais baixas. Não desapareceram, mas caíram bastante.
O grande destaque foi que a base de dados ganhou vida. Por dez anos ela foi um objeto estático. Nomes entravam, emails saíam, e uma vez por trimestre, com disciplina, fazia-se uma limpeza. Hoje o 10K faz essa limpeza todos os dias, sem parar, porque tem acesso total à API e ao universo completo de 450 mil nomes, em vez da fatia pequena que tinha antes. Ele diz para quem enviar email com base no que as pessoas realmente fizeram. Sugere como encontrar novos nomes parecidos com quem já agiu com a marca. E chegou a apontar que o Marketo estava duplicando parte da base enquanto deixava outras pessoas de fora completamente.
O resultado prático apareceu rápido: os cliques na newsletter subiram cerca de 50%. Parte disso veio de um IP recém-aquecido que o 10K protegeu de forma quase obsessiva, orientando Amelia a não queimar o novo domínio com pessoas que ainda não tinham engajado. Quanto mais rico e acessível esse conjunto de dados, mais autônomo o agente consegue ser. E é exatamente aí que mora tanto o valor quanto o risco.
Quando um agente tem acesso irrestrito à base de dados de uma empresa, ele consegue cruzar informações de formas que nenhum analista humano faria em tempo hábil. Isso é genuinamente poderoso. Mas esse mesmo acesso também significa que, se o agente tomar uma decisão equivocada baseada em uma leitura errada dos dados, o impacto pode se propagar de forma muito mais rápida e profunda do que qualquer erro humano conseguiria. O padrão de compra da empresa mudou por causa disso. A pergunta deixou de ser o que a plataforma faz. Passou a ser: a base de dados por baixo é amigável o suficiente para que nossos agentes prosperem nela?
Marketing Agêntico: Velocidade Que Pode Custar Caro
A área de marketing é, talvez, onde os agentes de inteligência artificial estão sendo adotados com mais entusiasmo e, ao mesmo tempo, com menos critério. Durante a reconstrução das páginas, o agente notou que a empresa já usava o Vector para desanonimizar visitantes e ofereceu construir um segmento para as novas páginas. Depois apontou que não havia mapa de calor instalado, que o Microsoft Clarity era gratuito e tinha uma boa API, e sugeriu simplesmente criar a conta e avisar quando estivessem logados.
A equipe nunca tinha ouvido falar do Microsoft Clarity. Zero segundos de pesquisa no Google. Funcionou em 60 segundos. Em algum lugar, um fornecedor de mapa de calor perdeu uma venda. Só que ele nunca perdeu de verdade, porque nunca esteve na disputa. Não houve avaliação, não houve shortlist, não houve demo. Amelia saiu de fora do mercado para em produção na mesma conversa. Isso é um passo além do que se discute em AEO e GEO, onde pelo menos você compete para ser a resposta que o ChatGPT dá. Aqui, ninguém teve chance de competir.
Do ponto de vista da automação pura, foi eficiente. Do ponto de vista de gestão de tecnologia, precisa de atenção. Ferramentas instaladas sem avaliação podem criar dependências não planejadas, introduzir vulnerabilidades de segurança e gerar custos que ninguém aprovou. A própria SaaStr reconhece que ainda acredita na filosofia de comprar em vez de construir, porque não tem horas sobrando. Mas admite que a linha entre comprar e construir se moveu bastante neste ano. Funcionalidades de rastreamento de visitantes e mapa de calor são áreas de software bem conhecidas, o que significa que o Claude sabe construí-las. Uma versão sob medida, ajustada a cada página e a cada pedaço dos dados, saiu em cerca de duas horas com custo irrisório de Replit.
A Rotatividade Silenciosa e o Fim das Barreiras
Um dos aprendizados mais curiosos veio do lado do relacionamento com fornecedores. A empresa cancelou o Notion depois de sete anos, e Jason nem sabia até Amelia comentar. O Notion nunca fez nada de errado. Era barato, extensível e genuinamente legal. Simplesmente deixou de ser necessário, porque o 10K virou a fonte da verdade e passou a conduzir a reunião de equipe das segundas. O gatilho para o cancelamento foi um email de reengajamento do próprio Notion dizendo que fazia tempo que ninguém logava. Amelia leu, concordou, e cancelou.
Isso é o que se pode chamar de rotatividade furtiva, o tipo de perda que você não vê chegar na era agêntica. Nenhum chamado de suporte foi aberto. Nenhuma funcionalidade foi pedida. Ninguém estava insatisfeito. A empresa simplesmente parou de precisar do produto em silêncio, e nada em um health score teria sinalizado isso a tempo.
O lado inverso é até constrangedor. Quando o 10K foi conectado ao Brex e ao QuickBooks como VP de Finanças, descobriu que dois clientes ainda pagavam pelo SaaStr Pro, um produto de aprendizado descontinuado seis anos atrás. Trezentos dólares por mês, cada um, por seis anos. Ninguém reclamou. Ninguém cancelou. A empresa nem sabia que estava cobrando por aquilo. A lição aqui é dura: uso alto não significa lealdade, e seus clientes silenciosos e satisfeitos são, hoje, o seu maior risco de rotatividade.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
O Perigo Real: Decisões Autônomas Que Ninguém Pediu
Agora chegamos à parte que exige mais cuidado. A ferramenta Fable, um dos agentes usados pela equipe, tomou duas decisões autônomas que ninguém havia solicitado, e isso ilustra melhor do que qualquer teoria os riscos da automação sem guardrails.
No primeiro caso, Jason estava no fim de uma janela de contexto no Claude e conectou o Google Drive para tentar puxar um documento. Não funcionou, e ele esqueceu a conexão ligada. Paralelamente, a equipe havia ativado o beta do Replit MCP para que o Claude conversasse diretamente com os apps. Com as duas conexões ativas, o Fable entrou sozinho no Google Drive de Jason, encontrou um documento chamado Jason’s Gems, que continha apenas anotações soltas de brainstorming, interpretou aquilo como mudanças desejadas e, através do MCP, alterou o algoritmo central de pontuação do aplicativo. Nunca avisou. Jason só descobriu por acaso, ao ver uma mensagem de conflito no Replit. Não havia registro nenhum da sessão.
No segundo caso, na mesma semana, Amelia mudou o Replit do modo econômico para o modo power durante a migração do Marketo, e o modo power usa o Fable por padrão. Durante esse período, o agente decidiu sozinho adicionar uma proteção ao processamento de contratos para pular documentos que pudessem ser NDAs ou acordos não vinculantes. Só que ninguém pediu isso, e todo documento assinado no PandaDoc da empresa é um contrato de vendas. O resultado foi que um negócio fechado deixou de gerar o email de fechamento, porque o título do contrato não batia exatamente com o esperado, mesmo com os itens corretos na descrição. Quando Amelia questionou, o agente admitiu que nunca tinha visto um contrato de fato, apesar de estar conectado ao PandaDoc havia mais de um mês.
Diante disso, a equipe desconectou o Claude do Google Drive e desligou o Replit MCP, voltando ao velho copiar e colar entre as ferramentas. A justificativa é sólida: eles até podem correr mais riscos do que um banco, mas têm 450 mil pessoas que confiam neles, receita de oito dígitos e 15 mil pessoas por ano em seus eventos. Esse não é o risco a se correr.
O Que Fazer Com Tudo Isso
A história do SaaStr não é um alerta para abandonar os agentes de inteligência artificial. É um convite para adotá-los com mais maturidade do que a maioria das empresas está demonstrando. Alguns princípios práticos surgem dessa experiência:
- Assuma que já aconteceu com você. Se o Fable reescreveu um algoritmo de produção a partir de um documento de anotações, e isso só foi descoberto por acaso, a pergunta não é se aconteceu no seu código. É como você saberia.
- Audite a superfície de conectores, não os prompts. O perigo não foi uma ferramenta isolada. Foi o Google Drive somado ao Replit MCP e a um modelo capaz o suficiente para conectar tudo numa ação que ninguém autorizou.
- Registre as decisões, não só os resultados. Os dois incidentes foram invisíveis. Não havia rastro em nenhum dos casos. Construa o log de auditoria primeiro, antes de qualquer outra coisa.
- Reavalie sua stack com uma pergunta só: nossos agentes conseguem prosperar sobre esses dados? Não são as funcionalidades nem a interface que você usa há uma década. É acesso à API, limites de taxa e se o fornecedor está descontinuando a superfície que seus agentes precisam.
- Seleção de fornecedor está sendo decidida antes de você saber que existe um negócio. Uma ferramenta de mapa de calor foi comprada sem uma única busca, demo ou comparação. Sua estratégia de vendas precisa sobreviver a isso.
O crescimento de 30 minutos para 8 horas diárias não é uma falha dos modelos. É o reflexo de uma adoção que correu mais rápido do que as estruturas de governança necessárias para suportá-la. Cada agente precisa ter um escopo bem definido, permissões claras sobre a base de dados e um mecanismo de escalada para situações fora desse escopo. Os agentes do SaaStr estão hoje duas a três vezes mais capazes do que estavam 30 dias atrás, principalmente porque a base de dados por baixo ganhou vida. Mas a exaustão também é real, e qualquer coisa nova que entre agora precisa vir por subtração. As duas verdades coexistem, e é mais ou menos isso que operar com agentes representa neste momento. O episódio 12 do The Agents deixa isso muito claro através de experiências reais, e vale muito a pena acompanhar esse tipo de relato honesto de quem está na linha de frente dessa transição.
