O que ficou no papel: a anatomia dos 13 agentes que nunca foram ao ar
13 agentes foram ao papel. Arquitetura definida, escopo escrito, em alguns casos código parcialmente implementado.
Nenhum foi ao ar.
Não por falta de orçamento. Não porque o modelo errou. Não porque a tecnologia era imatura. Por um motivo único que só ficou óbvio depois — e que apareceu em variações ligeiramente diferentes em cada um dos 13 casos.
Na semana passada, mostrei os 6 projetos de IA que ficaram rodando. Nesta semana quero fazer o que nenhum consultor de IA faz: mostrar os que ficaram no papel.
Não porque é bonito contar. Mas porque os 13 ensinam mais do que os 6.
Vou dividir por categoria de falha — porque não foi o mesmo erro 13 vezes. Foi o mesmo erro com disfarces diferentes.
Antes de entrar nos casos: dos R$50 mil investidos em 6 meses, estimo que R$18 a 22 mil foram consumidos por projetos que não chegaram à produção. Horas de desenvolvimento, reuniões de alinhamento, licenças de ferramentas que rodaram em ambiente de testes por meses. Esse número nunca aparece no budget aprovado. Ele aparece na análise de oportunidade que ninguém faz.
Categoria 1 — Automação de processo inexistente
Esta é a categoria com mais casos: 6 dos 13. E a mais fácil de não perceber enquanto está acontecendo, porque o projeto sempre parece razoável no papel.
O SDR Bot
O projeto mais ambicioso do lote. Levou 3 semanas de desenvolvimento. A arquitetura estava bem pensada: agente que buscava empresas no perfil do ICP via Apollo, validava contatos, personalizava mensagem com base em sinal de intenção (cargo, setor, tamanho da empresa, mudança recente de ERP), enviava via WhatsApp Business API e rastreava abertura e resposta.
No papel, era elegante. Na prática, travou na semana 3 por um motivo que não tinha nada a ver com código.
Chegou a hora de definir o critério de qualificação — qual empresa entrava na sequência, qual ficava de fora. E descobrimos que o time de vendas não tinha esse critério escrito em lugar nenhum. Cada vendedor qualificava de um jeito. Um priorizava empresas com ERP legado. Outro priorizava tamanho de equipe. Um terceiro priorizava setor. Quando perguntávamos "quem é o cliente ideal para prospectar agora?", a resposta variava dependendo de com quem você falava.
O agente precisava tomar essa decisão de forma consistente, 200 vezes por dia. Mas nem as pessoas conseguiam tomar essa decisão de forma consistente entre si.
Ficamos 2 semanas tentando resolver isso com prompt engineering — tentando codificar na instrução do agente um critério que a equipe de vendas não tinha consenso sobre. É exatamente o que não funciona: você não resolve falta de processo com prompt.
Resultado final: repositório impecável. 0 mensagens enviadas em produção. O projeto existe como documentação de uma decisão que nunca foi tomada.
O gerador de propostas comerciais
Agente que recebia o briefing de um potencial cliente e gerava uma proposta comercial personalizada — estrutura, argumentos, pricing, prazo, próximos passos.
Travou na etapa de aprovação interna. Para o agente gerar uma proposta, precisava saber qual era a política de precificação. Qual era o desconto máximo permitido por perfil de cliente. Quais eram os casos de uso que a empresa atendia bem e quais ela evitava. Quais eram as cláusulas que podiam ser negociadas.
Nada disso estava documentado. Existia na cabeça de 2 ou 3 pessoas — e a resposta variava dependendo do humor do dia e de quem você perguntava.
Passamos 3 semanas tentando extrair esse conhecimento para um documento. O documento chegou a existir. Mas não havia quem se responsabilizasse por mantê-lo atualizado — então ele envelheceu em 6 semanas e ficou inutilizável.
Resultado: 0 propostas geradas em produção.
Categoria 2 — Automação de processo que existe, mas não está documentado
Esta categoria é mais sutil. O processo existe — mas só na cabeça de quem o executa. Quando você tenta automatizá-lo, descobre que ninguém sabe exatamente o que o processo é.
O co-pilot de vendas
Este chegou mais longe. Chegou ao beta com 7 reuniões gravadas.
A ideia: transcrição em tempo real durante reuniões com potenciais clientes. O agente identificava sinais de compra, objeções e perguntas do potencial cliente, e sugeria respostas ao vendedor — visíveis numa janela lateral do computador, sem interromper a conversa.
Tecnicamente funcionava. O modelo identificava objeções corretamente. As sugestões eram coerentes. O problema era que para sugerir a resposta certa, o agente precisava saber em qual etapa do processo de venda a reunião estava.
Numa reunião de diagnóstico, a resposta certa para "qual é o preço?" é "antes de falar de preço, preciso entender melhor o seu contexto — posso te fazer 3 perguntas?". Numa reunião de fechamento, a resposta para a mesma pergunta é muito diferente.
O agente não conseguia distinguir porque o processo de venda da empresa não tinha etapas claras. Cada vendedor conduzia as reuniões de um jeito. Um qualificava na primeira reunião, outro qualificava na segunda. Um apresentava pricing na segunda reunião, outro só na quarta.
Sem etapas definidas, o agente chutava a fase da conversa — e chutava errado com frequência suficiente para os vendedores pararem de usar.
Resultado: 7 sessões de beta. Nenhum vendedor chegou à segunda semana de uso consistente.
O sistema de acompanhamento automático
Agente que identificava negociações sem movimentação há mais de X dias no CRM e enviava acompanhamento personalizado ao potencial cliente — baseado no histórico da conversa, no estágio do processo e na persona do interlocutor.
O problema foi descoberto em 2 semanas: não havia cadência de acompanhamento definida. Quantos dias sem resposta antes de um acompanhamento? Qual o tom — urgência, valor ou curiosidade? Após quantos acompanhamentos sem resposta um negócio é marcado como perdido?
Cada vendedor tinha a própria resposta. O agente precisava de uma. Passamos 3 semanas tentando definir a cadência com o time. A reunião aconteceu. O documento foi escrito. E então o gerente de vendas saiu da empresa, o time passou por uma reorganização e o documento nunca foi implementado como processo real.
Resultado: 0 acompanhamentos enviados em produção.
Categoria 3 — Ferramentas sem processo de uso
Esta é a mais traiçoeira. O projeto é entregue, funciona, está disponível — e ninguém usa.
As bases de conhecimento
Construí 4. Uma para cada empresa com quem trabalhei. Estrutura padrão: portfólio de produtos com argumentação consultiva, histórias de clientes com resultados numéricos, objeções mais comuns com argumentos de resposta, perfis de compradores com pontos de dor específicos. A mais extensa tinha 34 mil palavras.
Levei em média 6 semanas para construir cada uma, com o cliente colaborando nas revisões.
Nenhuma está em uso ativo hoje.
O que aconteceu: a base ficou disponível. Mas não havia momento definido na operação onde o vendedor deveria consultá-la. Antes de uma reunião? Durante a reunião? Ao escrever uma proposta? Quando chegasse uma objeção específica?
Sem processo de uso, a base virou uma enciclopédia interna que todos sabem que existe e ninguém abre. Atualizei as 4 por mais 2 meses depois da entrega. Depois parei — porque ninguém percebia quando estavam desatualizadas, o que significava que ninguém estava usando.
A lição técnica: uma base de conhecimento não é um produto — é uma dependência de um processo. Se o processo não existe, a base não tem onde se encaixar.
O agente de análise de concorrência
Agente que monitorava sites de concorrentes, capturas de tela de anúncios e publicações do LinkedIn para identificar movimentações relevantes: novo produto lançado, mudança de posicionamento, campanha agressiva de preço, nova parceria.
Funcionava. Gerava um relatório semanal com as movimentações identificadas.
O relatório existia. Ninguém sabia o que fazer com ele.
Não havia processo de resposta competitiva na empresa. Quando a concorrência lançava algo, não havia um dono para decidir como reagir. O relatório chegava, era lido, gerava comentários no Slack e desaparecia.
Após 8 semanas, paramos de gerar o relatório. O motivo explícito foi custo de tokens. O motivo real foi que ninguém estava usando a inteligência gerada.
O padrão, com mais precisão
Nos 6 que ficaram rodando, listei três critérios na semana passada: problema delimitado, processo humano antes, dono claro.
Os 13 que ficaram no papel ajudam a entender o que cada um desses critérios significa na prática — porque cada categoria de falha violou um critério diferente.
A Categoria 1 (automação de processo inexistente) violou o critério do processo humano antes. A Categoria 2 (processo existe mas não está documentado) violou o critério do problema delimitado — porque sem documentação, o problema a resolver ainda está em aberto. A Categoria 3 (ferramenta sem processo de uso) violou o critério do dono claro — porque sem dono, não há quem defina onde a ferramenta se encaixa na operação.
Segundo o McKinsey Digital 2025, menos de 35% dos projetos de IA em B2B chegam a uso recorrente. Esse número visto de fora parece pessimista. Visto de dentro — depois de ter passado pelos 13 — parece otimista.
O que o dado não explica é o mecanismo. Os projetos não falham porque a IA é ruim. Eles falham porque a IA foi contratada para resolver um problema de maturidade de processo — e esse não é o trabalho que ela sabe fazer.
O checklist que uso hoje antes de qualquer projeto de IA
1. O processo existe e funciona sem o agente?
Não "existe no papel". Funciona. Alguém faz hoje, de forma consistente, e consegue reproduzir sem perguntar. Se a resposta for não, o próximo passo é criar o processo humano — não o agente.
2. Está documentado a ponto de um novo integrante poder seguir sem perguntar?
Se não está, o problema não é de automação — é de documentação. Resolver primeiro.
3. Existe um dono do resultado — não do projeto?
Dono do projeto assina a aprovação. Dono do resultado responde pela métrica que o projeto deve mover. São pessoas diferentes. Sem dono do resultado, o projeto vira projeto piloto permanente.
4. O processo tem um momento definido de uso?
Antes de automatizar uma ferramenta, mapear onde ela se encaixa na rotina existente. Ferramentas que as pessoas precisam lembrar de abrir geralmente não são abertas.
5. O que muda se o agente sair do ar amanhã?
Se a resposta for "nada" — o agente não está integrado à operação. Está em órbita ao redor dela.
Dos 13 que ficaram no papel, 11 eram tecnicamente viáveis. O código existia ou podia ser escrito. O modelo dava conta. O custo era justificável.
O que faltou, em todos os casos, foi o que deveria ter vindo antes do código.
Você tem algum projeto de IA em avaliação ou em desenvolvimento agora? Qual dos 5 itens do checklist você ainda não validou?
Nas próximas semanas da série: o erro que apareceu em 3 das 4 empresas — e o que eu começaria de forma diferente se voltasse a agosto de 2025.
Se prefere conversar diretamente sobre o que faz sentido na sua operação: Me manda um oi!