Eu passei os últimos anos tentando construir um agente de vendas com inteligência artificial.
Passei por n8n. Passei por Google Agent. Passei por agente da OpenAI. Depois Lovable. Depois frameworks de agente de verdade. Foram vários aprendizados — e muita grana, tempo e dor no caminho.
A primeira impressão foi quase mágica.
Eu não era técnico. E, de repente, conseguia imprimir ali um agente com vida: conversava no WhatsApp, respondia perguntas de forma não robótica. Eu senti que tinha dado vida a alguma coisa. Foi bem interessante. Foi brilhante.
Até o momento em que você tenta colocar aquilo pra gerar resultado pra alguém. Pra um projeto real. Pra um cliente. Aí o buraco é mais embaixo.
No dia a dia, o básico precisa estar bem feito
Quando a gente vai construir um agente, muita gente se preocupa com o perfume — e esquece do banho bem tomado.
O perfume é a árvore enorme de automações: regra atrás de regra, node atrás de node, milhão de ferramentas, buscas, integrações, “robustez” na cabeça. O banho bem tomado é outra coisa: o agente sabe o começo, o meio e o fim do trabalho dele?
Eu tentava incrementar o máximo possível no n8n. Criava teias gigantes. Queria robustez. Mas na minha cabeça eu ainda não tinha parado pra pensar, de verdade, qual era a finalidade daquele agente — passo a passo, com todas as portas de entrada e saída.
Essa confusão não é burrice. É o efeito colateral de uma ferramenta poderosa nas mãos de alguém empolgado. Você descobre que consegue. Aí quer conseguir tudo. E “tudo” vira labirinto antes de virar processo.
Aprendizado 1: processo antes de tecnologia
Toda vez que você for construir um agente — independente do stack — é muito importante ter encontrado o processo que você quer que ele siga do começo ao fim.
- O que entra?
- O que sai?
- Quais caminhos o lead pode tomar?
- Quando escala pra humano?
- O que nunca pode acontecer?
Só depois disso faz sentido apelar pro desenvolvimento da tecnologia. Independente da tecnologia que você usar.
Conforme você constrói esse processo bem medido, as vulnerabilidades da ferramenta aparecem. Isso abre o olho pra novos processos e novas possibilidades. Até lá, meça o processo. Não comece pelo perfume.
Um jeito simples de forçar essa disciplina é escrever o processo como se fosse o job description de um funcionário humano:
- Qual é o resultado que ele entrega no fim do dia?
- Quais conversas ele pode ter sozinho?
- Quais ele precisa trazer pra você?
- Como ele prova que fez o trabalho (log, resumo, handoff)?
Se você não consegue responder isso em uma página, o agente ainda não existe. Existe só a vontade de ter um agente.
Aprendizado 2: autonomia importa mais que o caminho perfeito
Autonomia e liberdade são primordiais pra uma LLM operacionalizar o fluxo que você definiu.
Se você cria um processo pobre, mas enche de guardrail e regra de proibição, você não está criando um bom processo. Você está tentando criar um caminho perfeito pro lead.
E lead nenhum caminha perfeitamente até a conversão.
O que funciona melhor:
- Objetivos claros — o agente sabe o que precisa conquistar.
- Proibições importantes — as poucas regras que realmente são vermelho.
- Autonomia — espaço pra o agente construir soluções dentro do processo.
Não amarre a conversa num trilho rígido. Desenhe a pista. Dê o destino. Deixe a inteligência dirigir.
A tentação do empreendedor técnico (mesmo o que não programa) é controlar demais. Porque controle parece segurança. Mas na prática, excesso de regras vira um chatbot disfarçado: opções rígidas, respostas engessadas, lead preso num fluxo que não parece com gente.
A LLM brilha quando recebe um objetivo, um contexto e um perímetro. Ela sofre quando recebe um labirinto de “se… então…” que um humano experiente quebraria em três mensagens.
Por que eu comecei a desgostar do n8n
Um dos primeiros motivos foi multilinguagem. Depois veio o pesadelo operacional: cheguei a ter manutenção em dezenas de n8n diferentes — servidores diferentes, automações diferentes. Atualização quebrava integração. Autenticação caía. Ficou inviável.
n8n me ensinou muito. Ele me deu a primeira emoção de “agente vivo”. Mas não escala como operação de produto pra vários clientes.
Vale dizer o que o n8n ainda é bom: prototype rápido, integração pontual, prova de conceito. Se você quer validar se o mercado responde a um atendimento automático em 48 horas, ele te ajuda. O problema começa quando o prototype vira a casa permanente — e você mora numa obra.
Manter 23 instâncias com automações diferentes é o tipo de dívida que não aparece no demo. Aparece no domingo à noite, quando uma autenticação cai e três clientes param ao mesmo tempo.
Depois veio o Lovable — e o salto foi lindo
Eu não sou programador. Fui buscar soluções. Consegui desenvolver um agente usando o Lovable.
Além de um agente inteligente, eu conseguia criar uma camada de frontend: campos mais bonitos, prompts mais organizados, experiência mais humana. Interagir de forma natural num chat e aquilo virar um agente foi uma experiência linda. Brilhante.
Só que o padrão se repetiu: você incrementa, vê as vulnerabilidades anteriores, abre novas possibilidades — e encontra o próximo teto.
No caso, a limitação vinha forte nas Edge Functions: muito do processamento crítico numa folha só de código, tendo que passar parâmetros demais do atendimento naquele ponto. Começou a quebrar possibilidades — principalmente tratamento de dados pra WhatsApp. Virou pesadelo.
Essa é uma armadilha clássica do no-code / low-code moderno: a interface vende velocidade; a arquitetura cobra juros. Enquanto o volume é baixo e o fluxo é simples, tudo flui. Quando entra multilíngue, filas, mídia, estados de conversa, handoff e multi-cliente, a “folha única” deixa de ser elegância e vira gargalo.
Multi-tenant “no mesmo código” também doeu
Aí eu pensei: agora é hora de algo mais escalável. Vários clientes no mesmo processamento, variando configuração. Multi-tenant.
Cara, que pesadelo.
Erro que acontecia com um cliente não acontecia com o outro — com o mesmo parâmetro, o mesmo código. Era um caos. Foi aí que eu entendi: escala sem arquitetura de agente de verdade só multiplica o problema.
Multi-tenant não é “um if por cliente”. É isolamento de memória, de tools, de identidade, de dados sensíveis, de versão de fluxo. Sem isso, você acha que tem um produto. Na prática, tem um Frankenstein compartilhado.
O que eu chamo de agente de verdade
Antes de falar de stack, preciso alinhar definição — porque o mercado chama de “agente” muita coisa que é só chat bonito.
Pra mim, um agente de vendas de verdade precisa, no mínimo, de:
- Papel claro — atendimento, qualificação, suporte, conteúdo, assistente do dono.
- Processo com estágios — não um monólogo infinito.
- Ferramentas — agenda, base de conhecimento, CRM leve, WhatsApp, handoff.
- Memória operacional — o que já foi dito, o que já foi prometido, o que está pendente.
- Observabilidade — você enxerga o que ele fez e onde travou.
- Limites — o vermelho que não se atravessa.
Sem isso, você tem uma demo. Com isso, você tem um funcionário digital incompleto — mas funcionário.
Onde eu cheguei na stack
Hoje, o padrão que eu uso pra construir agentes é:
- Mastra e Agno como base operacional do dia a dia.
- LangChain / LangGraph quando o cliente é maior e precisa de mais robustez e orquestração de fluxo.
Não é “ferramenta mágica”. É stack escolhida depois de errar o suficiente pra saber o que cada uma aguenta.
O que é um framework de agente
É a camada que transforma “modelo de linguagem respondendo bonito” em trabalho com processo: memória, ferramentas, etapas, handoff pra humano, logs, testes.
Sem isso, você fica refém de automação solta (n8n) ou de um protótipo bonito (Lovable) que estoura quando a operação cresce.
Pensa assim: o modelo é o cérebro bruto. O framework é o emprego — cargo, ferramentas, rotina, chefe e relatório.
Mastra — o que é e pra que serve
Em uma frase: framework TypeScript (mundo JavaScript) pra montar agentes e workflows com estrutura de produto.
Pra quem faz sentido: quando seu time / produto vive em stack web moderna (Next.js, Node) e você quer agente com tools, memória e fluxos sem reinventar a roda.
O que ele te dá, na prática:
- agente com instruções + ferramentas
- workflows (passos encadeados)
- proximidade com o universo de produto digital (UI, API, deploy web)
Como eu enxergo: ótimo quando a construção precisa conversar bem com o mundo do front e do produto. É uma das bases que uso no padrão de construção.
Mastra não é “mais um chat widget”. Ele te empurra pra pensar em componentes de agente como peça de software — e isso muda a qualidade do que sobra depois do hype.
Agno — o que é e pra que serve
Em uma frase: framework Python pra agentes e times de agentes, com foco em performance, tools e operação.
Pra quem faz sentido: quando a inteligência e a orquestração dos workers vivem mais no backend (Python), com vários agentes colaborando — recepção, vendas, conteúdo, assistente do dono.
O que ele te dá, na prática:
- agentes com tools e memória
- times / orquestração entre agentes
- ritmo bom pra colocar operação no ar e iterar
Como eu enxergo: é o chão de fábrica de muita coisa que eu opero hoje. Quando eu falo “agente de verdade”, Agno está no centro do meu padrão.
A vantagem prática de um framework assim é menos “magia” e mais repetibilidade. Você consegue versionar comportamento, separar papéis, testar falhas e evoluir um agente sem redesenhar a teia inteira toda vez que muda uma regra.
LangChain e LangGraph — quando o músculo precisa ser maior
LangChain é o ecossistema mais famoso de conectar LLM a ferramentas e dados. LangGraph é a evolução pra fluxos com grafo: estados, loops, ramificações, controle fino do caminho.
Pra quem faz sentido: cliente maior, processo mais complexo, necessidade de robustez, auditoria de estado e orquestração pesada — quando o fluxo não é uma linha reta.
O que ele te dá, na prática:
- controle explícito de estados do processo
- fluxos que podem voltar, esperar, ramificar
- ecossistema grande de integrações
Como eu enxergo: não é meu padrão do dia a dia pra todo mundo. É a ferramenta que eu puxo quando a robustez e o processamento pedem músculo.
Tem gente que começa por LangGraph porque “parece enterprise”. Eu não recomendo isso pra quem ainda não desenhou o processo. Poder demais cedo vira complexidade cedo. Complexidade cedo vira abandono.
Perfume, banho e a curva de maturidade
Se eu tivesse que resumir os 3 anos numa curva, ficaria assim:
- Empolgação — o agente fala; parece vida.
- Ornamento — mais nodes, mais regras, mais “inteligência”.
- Colapso operacional — manutenção, multilíngue, atualizações, clientes.
- Prototype avançado — UI bonita, sensação de produto.
- Teto de arquitetura — uma folha de código não segura a operação.
- Framework de agente — processo + tools + memória + orquestração.
- Escolha por contexto — Mastra/Agno no padrão; LangGraph no peso alto.
Nenhuma etapa foi inútil. Cada uma pagou o aprendizado da seguinte. O erro não foi experimentar. O erro foi achar que a etapa atual era o destino.
O que eu faria diferente se começasse amanhã
Se um dono me parasse hoje e falasse “quero meu primeiro agente de vendas”, eu não começaria pela ferramenta. Começaria assim:
- Escolher um trabalho só (ex.: atender lead inbound no WhatsApp e qualificar).
- Escrever o processo em 1 página (entrada, estágios, saída, handoff).
- Definir 3 a 5 objetivos e 3 a 5 proibições — só.
- Rodar manualmente o script com humanos por alguns dias pra validar o fluxo.
- Só então escolher a stack do momento (prototype ou framework).
- Instrumentar observação desde o dia 1 (o que falhou, onde, por quê).
- Evoluir autonomia depois que o processo para de mentir.
Isso parece menos glamouroso do que “monte seu AI SDR em 15 minutos”. Também é o único caminho que não me fez chorar duas vezes pelo mesmo motivo.
Checklist rápido antes de escolher stack
Antes de abrir qualquer ferramenta, responda em voz alta:
- Qual resultado de negócio esse agente entrega esta semana?
- Qual canal ele opera de verdade (não no slides)?
- Quais exceções humanas ele precisa reconhecer?
- Como eu vou medir se ele está ajudando ou só conversando?
- Quem atualiza o processo quando a operação muda?
Se a resposta for vaga, a stack não importa. Qualquer uma vai falhar com elegância diferente.
Tabela prática das camadas que eu vivi
| Camada | Melhor pra | Limite que eu vivi |
|---|---|---|
| n8n / automação | Prototype, “primeiro agente vivo” | Manutenção em N instâncias, update quebra, multilíngue sofre |
| Lovable + Edge Functions | Demo linda, UI rápida, aprendizado | Teto de arquitetura; WhatsApp/dados viram pesadelo |
| Mastra | Agentes em stack TypeScript/produto | Escolha consciente: casa com o mundo JS |
| Agno | Workforce de agentes em Python | Meu padrão operacional atual |
| LangGraph | Processos complexos / cliente grande | Mais poder = mais disciplina de desenho |
A regra que ficou
Não importa se é n8n, Lovable, Mastra, Agno ou LangGraph:
- Desenhe o processo ponta a ponta.
- Defina objetivos claros e poucas proibições que importam.
- Dê autonomia pra LLM operar dentro da pista.
- Só então escolha a tecnologia — e troque de stack quando a vulnerabilidade aparecer, não quando o hype aparecer.
Perfume sem banho não fecha reunião. Agente sem processo não escala. E ferramenta errada no momento certo só adia a dor.
Se tem uma frase que eu carrego desses 3 anos, é esta: a inteligência artificial não substitui clareza. Ela amplia a clareza que você já tem — e amplia o caos quando você ainda não tem.
Eu gastei tempo demais tentando compensar processo frouxo com mais tecnologia. A cura não foi mais nodes. Foi aceitar que o trabalho duro é desenhar o trabalho. A stack só executa.