Análise profunda da arquitetura, gargalos e caminhos possíveis para a Lead2Go escalar de 25 para 200+ clientes sem depender do fundador.
Uma análise minuciosa de cada componente do sistema que impacta velocidade de entrega, custo de suporte e tempo de onboarding. Baseada em leitura completa do código-fonte.
| Etapa | Quem faz | Tempo | Status |
|---|---|---|---|
| Criar Organização | Backoffice UI | 5 min | Automatizado |
| Criar Inbox (WhatsApp) | Backoffice UI | 10 min | Automatizado |
| Configurar Agent (persona, horário, etc.) | Backoffice UI | 30 min | Automatizado |
| Knowledge Base (upload docs) | Backoffice UI | 30-60 min | Automatizado |
| Escrever Agent Instructions | Backoffice (markdown) | 60 min | Semi-manual |
| Criar Agent Version novo (funil diferente) | Desenvolvedor (código) | 3-5 dias | Manual / Código |
| Ajustar prompts da IA | Desenvolvedor (código) | 2-8 horas | Manual / Código |
| Ajustar stages do funil | Desenvolvedor (código) | 4-16 horas | Manual / Código |
| Adicionar integração nova (plugin) | Desenvolvedor (código) | 1-3 dias | Manual / Código |
Cada cliente com funil diferente exige um novo enum no Prisma, ~30 arquivos de código no ai-engine, build da lib, deploy da API. Isso torna o fundador (Dhyego) insubstituível no onboarding. É por isso que existem 25 vendidos mas só 18 onboarded.
Comparação real entre os 4 agent versions existentes no código. Quanto maior a barra, mais código é copy-paste.
~70% do código de cada agent é template reutilizável. Apenas ~30% é realmente específico do negócio do cliente (nomes dos stages, campos do lead, regras de extração específicas, tom da persona). O sistema já é modular por dentro — ele só não foi projetado para ser configurável por fora.
O ConfigurationField no backoffice já suporta 8 tipos de campo e renderiza formulários dinâmicos a partir de JSON Schema. Qualquer campo novo = zero código frontend.
Upload em massa, bulk operations, sincronização com Pinecone, search semântico. O pipeline de conhecimento está maduro e pronto para escala.
Arquitetura de plugins com credenciais encriptadas, config por agent, registry centralizado. UNO Scheduling e Lead2Go já funcionam. Extensível.
Simulador de conversa + avaliadores determinísticos e AI Judge + relatórios de qualidade. Infraestrutura de teste de IA pronta para validar mudanças.
LangGraph com rate limit, spam detection, knowledge retrieval, response generation, validation, transfer judge. Pipeline robusto e genérico.
Métricas via Sentry com dependency inversion, logging estruturado, audit trail completo, token tracking por conversa. Visibilidade total.
A raiz do problema não é técnica — é arquitetural. O que deveria ser configuração está modelado como código. Entender isso é essencial antes de escolher um caminho.
AgentVersion no Prisma = migration SQL para cada clienteagent-registry.tsCada agent version hoje contém estes componentes. A coluna "Natureza Real" mostra o que ele deveria ser.
| Componente | Hoje | Natureza Real | Exemplo do que muda entre agents |
|---|---|---|---|
| Stages (funil) | Código TS | Dados/Config | Nomes, ordem, condições de avanço |
| Prompts (11 arquivos) | Código TS | Template + Dados | Persona, regras de extração, exemplos |
| Variáveis do Lead | Interface TS | JSON Schema | Campos: name, age, complaints vs. englishMotivation |
| Config Schema | Zod + TS | JSON Schema | Persona, clínica, links, horários |
| Tools por Stage | Config em código | Dados/Config | Quais plugins ativos em cada stage |
| GLOBAL_CONTEXT | Copy-paste | Compartilhado | Quase nada — 95% idêntico |
| Utils (client-context) | TS functions | Template | Quais variáveis exibir no contexto |
Se o componente muda entre clientes mas o formato é o mesmo — ele não é código, é configuração disfarçada de código. Stages, prompts e variáveis do lead seguem exatamente esse padrão.
Cada abordagem resolve o problema em uma camada diferente. Não são mutuamente exclusivas — a recomendação final combina elementos das três. Mas é crucial entender os trade-offs antes de decidir.
Maximizar o que já existe. Dar acesso ao cliente para o que hoje só o admin faz, e limpar o código duplicado para acelerar criação de agents.
Replicar no webapp (app do cliente) os formulários que já existem no backoffice: configuração do agent, agent instructions (markdown), knowledge base CRUD. O código dos componentes já existe — é routing + permissões.
Mover GLOBAL_CONTEXT, prompt builders, config schema base e channel labels para funções compartilhadas no ai-engine. Reduzir de ~30 arquivos por agent para ~15, cortando a duplicação de 75% para ~35%.
| Tarefa | Esforço | Impacto |
|---|---|---|
| Expor config form no webapp | 2-3 dias | Cliente muda persona, horário, palavras proibidas sozinho |
| Expor agentInstructions no webapp | 1 dia | Cliente escreve instruções customizadas da IA |
| Expor Knowledge Base no webapp | 2-3 dias | Cliente gerencia docs, FAQs, tratamentos |
| Templates de agentInstructions por vertical | 1 dia | Onboarding mais rápido com texto pré-preenchido |
| Extrair GLOBAL_CONTEXT para shared | 2 dias | Elimina ~400 linhas duplicadas entre agents |
| Criar prompt builders parametrizados | 3-4 dias | Novo agent herda instruções, guardrails, abuse detection |
| Template agent.ts (createBaseAgent) | 2-3 dias | Novo agent = 50% menos código boilerplate |
Excelente como Fase 1. Resolve a dor imediata de suporte e libera 10-15h/semana. Mas sozinha não te leva a 200+ clientes. O refactoring de código prepara o terreno para a Abordagem B, então não é trabalho jogado fora — é pré-requisito.
Transformar Agent Versions de código para dados. Um "Blueprint" no banco define stages, prompts, variáveis e tools. O engine interpreta em runtime. Zero deploy para novo funil.
Editor visual de stages (drag-and-drop), editor de prompts com variáveis {{persona}}, {{clinica}}, schema de variáveis do lead. Tudo salvo como JSON no banco.
Em vez de version: AgentVersion (enum), o Agent tem blueprintId: string. A configuração por org preenche as variáveis do blueprint.
O ai-engine carrega o blueprint do banco (com cache), monta o grafo LangGraph dinamicamente, interpola os prompts com config da org e executa. O pipeline de 15 nodes continua o mesmo.
O suite de testes roda contra o blueprint em DRAFT. Se passar, muda para ACTIVE. Os mesmos avaliadores determinísticos + AI Judge. Nenhuma mudança na infra de testes.
Atualizar um prompt, adicionar um stage, mudar uma condição de transição — tudo via banco. A API carrega a versão mais recente do blueprint automaticamente.
Os 4 agents atuais (MAGRASS_SDR, MAGRASS_SDR_BETA, ADA_TEST, UNIVERSIDADE_BILINGUE) precisam ser convertidos em blueprints. A migration precisa manter backward compatibility — o enum AgentVersion vira um campo legado mapeado para blueprintId.
Blueprints carregados do banco a cada conversa adicionam latência. Solução: cache em memória com invalidação por webhook/pub-sub quando blueprint é atualizado. O engine já tem config estática — substituir por config dinâmica cacheada.
Prompts em banco = prompt injection surface. Necessário: sanitização de entrada, separação clara entre template (admin) e variáveis (cliente), validação de que placeholders são substituídos corretamente. Não permitir código executável nos templates.
O router.prompt.ts do MAGRASS_SDR_BETA tem 23.9KB com lógica de 3 caminhos e regras de extração complexas. Representar isso em JSON declarativo é o maior desafio técnico. Possível solução: DSL simplificada para condições + fallback para prompt livre.
Uma preocupação válida: prompts em código têm git history, blame e diff. Prompts em banco perdem isso. Mitigação: versionamento de blueprint com diff visual no backoffice, + changelog automático a cada save. O sistema de changelog já existe no ai-engine e pode ser adaptado.
É a transformação real. É o que separa "produto que depende do fundador" de "produto que escala sozinho". Mas exige maturidade e preparação. Sem a Abordagem A (refactoring) primeiro, o trabalho de extração e migração será significativamente mais doloroso. Faça A primeiro, depois B.
Construir em cima dos Blueprints um marketplace de templates. Cada vertical (estética, educação, fitness) tem um template pré-configurado. Onboarding = preencher um wizard. Vendedor faz sozinho.
Um AgentTemplate encapsula um Blueprint (o "motor" do funil) junto com valores pré-preenchidos para uma vertical específica. O template de "SDR Clínica Estética" já vem com stages de qualificação estética, prompts de persona empática, campos de configuração com nomes de tratamentos, e até agentInstructions com placeholders.
Em vez de configurar 15+ campos em formulários técnicos, o cliente (ou vendedor) responde 5-7 perguntas simples: "Qual o nome da sua clínica?", "Quais tratamentos vocês oferecem?", "Qual o horário de atendimento?". O sistema preenche tudo automaticamente.
| Passo | O que acontece | Tempo |
|---|---|---|
| 1. Escolher template | Vendedor seleciona "SDR Clínica Estética" no catálogo | 1 min |
| 2. Dados da empresa | Nome, cidade, endereço, horário (wizard guiado) | 3 min |
| 3. Persona da IA | Nome, tom (seleção), tratamentos oferecidos | 3 min |
| 4. Revisar agentInstructions | Texto gerado automaticamente com placeholders preenchidos, editável | 5 min |
| 5. Knowledge Base | Upload de FAQs, fotos de antes/depois, social proof | 10 min |
| 6. Conectar WhatsApp | QR code ou API token (fluxo existente) | 5 min |
| 7. Testar conversa | Sandbox com preview da IA funcionando | 3 min |
| Total | ~30 min |
É o endgame. É onde a Lead2Go vira plataforma, não serviço. Mas só faz sentido depois que B estiver sólida. O risco de pular para C sem B é construir um wizard bonito que alimenta um sistema frágil por baixo. B é o alicerce, C é a casa.
| Critério | A — Self-Service | B — Blueprints | C — Templates |
|---|---|---|---|
| Tempo de implementação | 1-2 semanas | 4-6 semanas | +2-3 semanas |
| Redução de suporte | -50% | -70% | -90% |
| Novo funil (tempo) | 1-2 dias (dev) | 2-4 horas (config) | 30 min (wizard) |
| Quem cria agent | Desenvolvedor | Qualquer pessoa do time | Vendedor / Cliente |
| Teto de escala | ~50 clientes | ~200 clientes | 1000+ clientes |
| Risco técnico | Baixo | Médio | Médio |
| Dependência do fundador | Parcial (ainda cria funis) | Mínima (revisa blueprints) | Zero (vendedor faz tudo) |
| Narrativa de investidor | Melhorou operação | Plataforma configurável | Plataforma no-code para agentes IA |
A melhor estratégia é inútil se ignorar a realidade dos recursos. Com um time de 3 devs e clientes esperando, cada semana conta. Vamos ser honestos sobre o que é viável.
Dhyego a 60% + 2 devs em ramp-up = ~1.5 FTE efetivo para features. Isso significa que uma abordagem de "4-6 semanas focadas" na prática pode virar 8-10 semanas. Planeje com essa realidade.
O que já existe no código e pode ser alavancado em cada abordagem.
| Ativo existente | Onde está | Reutilizável em | Esforço de adaptação |
|---|---|---|---|
| ConfigurationField (8 tipos de campo) | backoffice/components/ | A, B, C | Baixo — copiar para webapp |
| DynamicConfigForm (Zod + React Hook Form) | backoffice/components/ | A, B, C | Baixo — mover para libs/ui |
| AgentInstructionsDialog (markdown editor) | backoffice/components/ | A, B, C | Baixo — copiar para webapp |
| BulkUploadKnowledgeDocuments (1.466 linhas) | backoffice/components/ | A, C | Médio — simplificar para cliente |
| Eval Framework (simulador + avaliadores) | libs/ai-engine-eval/ | B, C | Baixo — já é genérico |
| Plugin Registry + Config System | libs/types/src/plugin.ts | B, C | Baixo — já extensível |
| Pipeline de 15 Nodes (LangGraph) | libs/ai-engine/src/engine/ | B | Médio — parametrizar inputs |
| createBaseAgent pattern | libs/ai-engine/src/agents/ | B | Médio — transformar em interpreter |
| Changelog system | libs/ai-engine/src/changelog/ | B | Médio — adaptar para blueprints |
O gap de 7 clientes não onboarded está crescendo. Cada semana que passa sem resolver é receita parada e risco de churn antes mesmo do onboarding. O parceiro de vendas continua vendendo. Se você não resolver a entrega, o problema piora exponencialmente. Além disso, Renato e Gustavo estão em ramp-up — dar a eles tarefas claras (webapp self-service) é a melhor forma de acelerá-los.
Parar tudo para fazer Blueprints em 6 semanas significa 6 semanas sem bugfixes, sem features de conversão, sem onboarding de novos clientes. Os Tier 1 e Tier 2 do backlog (SERVICE_UNAVAILABLE, IA que hallucina, scheduling quebrado) continuariam afetando os 18 clientes ativos. Churn dos existentes é pior que atraso dos novos. Retenção > Aquisição.
Não é "ou/ou" — é sequencial e paralelo. Fase 1 (self-service) em paralelo com bugfixes dos Tier 1-2. Fase 2 (refactoring) quando o Tier 1 estiver limpo. Fase 3 (Blueprints) como projeto focado depois que a base estiver sólida. O pior erro é tentar fazer tudo ao mesmo tempo com 1.5 FTE.
Um plano realista que considera o time atual, os bugs pendentes, e a necessidade de entregar valor incremental sem parar a operação. Cada fase entrega resultado sozinha.
Dar ao cliente o controle sobre o que ele já pode mudar. O código dos componentes já existe no backoffice — é replicar no webapp com permissões adequadas. Executável pelo Renato e Gustavo com review do Dhyego.
~50% dos tickets de suporte eliminados. Cliente muda persona, horário, palavras proibidas, instruções da IA e knowledge base sozinho. Libera ~10-15h/semana do Dhyego.
Extrair o código duplicado entre agents, criar builders compartilhados e reduzir o boilerplate. Acelera a criação manual de agents (1 dia vs. 3-5) e prepara o terreno para Blueprints. Pode rodar em paralelo com bugfixes dos Tier 1-2.
Código por agent: ~30 arquivos → ~12-15 arquivos. Duplicação: 75% → 35%. Criar novo agent version: 3-5 dias → 1 dia. Eval suite garante que nada quebrou.
A mudança de paradigma. Agent versions deixam de ser código e viram configuração no banco. O engine interpreta blueprints em runtime. Ajustado para a realidade de 1.5 FTE.
Novo funil = horas de configuração, não dias de código. Qualquer pessoa do time cria agents. Prompts editáveis em tempo real. Escala viável para 200+ clientes.
O toque final: templates por vertical + wizard de onboarding guiado. Vendedor onboarda cliente sozinho em 30 minutos. Fundador livre para estratégia e produto.
Onboarding: 3-5 dias → 30 minutos. Suporte: -90%. Vendedor onboarda sozinho. Lead2Go vira plataforma, não serviço.
| Métrica | Hoje | Pós Fase 1 | Pós Fase 2 | Pós Fase 3 | Pós Fase 4 |
|---|---|---|---|---|---|
| Onboarding / cliente | 3-5 dias | 2-3 dias | 1 dia | 2-4 horas | 30 min |
| Criar funil novo | 3-5 dias dev | 3-5 dias dev | 1 dia dev | 2-4h config | 30 min wizard |
| Pedido de ajuste IA | 2-8h dev | 30 min client | 30 min client | 5 min client | 5 min client |
| Tickets suporte / semana | 5-10 | 2-5 | 2-5 | 1-2 | 0-1 |
| Horas Dhyego em suporte | 15-20h/sem | 5-10h/sem | 5-10h/sem | 2-3h/sem | 0-1h/sem |
| Código por agent | ~30 arquivos | ~30 arquivos | ~12-15 arq. | 0 arquivos | 0 arquivos |
| Teto de clientes viável | ~30 | ~50 | ~80 | ~200 | 1000+ |
| Período | Dhyego | Renato | Gustavo |
|---|---|---|---|
| Semanas 1-3 Fase 1 + Bugfixes |
Bugfixes Tier 1-2 (80%) + Review (20%) | Webapp self-service: config + instructions | Webapp self-service: KB + endpoints de permissão |
| Semanas 4-6 Fase 2 |
Refactoring ai-engine (prompts, builders) | Features de conversão (Tier 2 backlog) | Consolidar config schemas + ajudar refactoring |
| Semanas 7-13 Fase 3 |
Blueprint interpreter (core) + migration | Editor de blueprints no backoffice | Cache + versionamento + endpoints CRUD |
| Semanas 14-17 Fase 4 |
Templates curadoria + sandbox preview | Wizard de onboarding + sandbox UI | AgentTemplate model + CRUD + testes e2e |
As Fases 1 e bugfixes rodam em paralelo naturalmente (times diferentes). Na Fase 3, o Dhyego foca no core (interpreter) enquanto Renato e Gustavo fazem frontend e infraestrutura. O ponto de convergência (migration final) é onde o time inteiro se alinha.
Cada fase não é apenas uma melhoria técnica — é um shift de posicionamento. De serviço manual para plataforma. De dependente do fundador para escalável.
Cada cliente é um projeto custom. O fundador escreve código para cada funil. O parceiro vende mais rápido do que você entrega. Escala limitada pela mão-de-obra técnica.
25 vendidos, 18 onboarded, teto: ~30 clientes
Cliente resolve 50% dos pedidos sozinho. Code base limpo permite criar agents 3x mais rápido. Fundador foca em produto e arquitetura. Time junior assume execução.
Teto: ~80 clientes
Novo funil = configuração, não código. Qualquer pessoa do time cria agents. Prompts editáveis em tempo real. Deploy zero. A IA do cliente evolui continuamente.
Teto: ~200 clientes
Vendedor onboarda em 30 min. Templates por vertical padronizam qualidade. Flywheel: mais clientes por vertical = template mais refinado = melhores resultados = mais vendas.
Teto: 1000+ clientes
Cada conversa gera dados sobre o que funciona. Com 50+ clientes em estética, você sabe exatamente qual tom converte mais, quais objeções são mais comuns, qual sequência de stages tem maior taxa de agendamento. Isso retroalimenta os templates — moat impossível de copiar.
Com blueprints data-driven, cada funil validado vira um ativo reutilizável. Concorrentes precisam reconstruir do zero. Você tem um catálogo de funis otimizados por centenas de conversas reais.
O eval framework já existente se torna o guardião de qualidade. Cada mudança de prompt é testada automaticamente. Clientes não percebem, mas a qualidade da IA melhora continuamente. Retenção sobe porque a IA fica melhor sem esforço do cliente.
| Oportunidade | Requer | Potencial |
|---|---|---|
| IA que cria a IA do cliente | Blueprints + Templates | Descreva seu negócio → agente criado automaticamente por LLM |
| Marketplace de blueprints | Blueprints + Versionamento | Partners criam e vendem blueprints customizados para nichos |
| Auto-otimização de prompts | Blueprints + Eval Framework | Sistema testa variações de prompts e seleciona a que converte mais |
| Multi-agent por org | Blueprints (já modelado) | Uma clínica com SDR, pós-venda, NPS — cada um um blueprint diferente |
| White-label para agências | Templates + Self-service | Agências de marketing criam e gerenciam IAs para seus clientes |
Comece pela Fase 1 esta semana. O ROI é imediato: componentes já existem, execução é delegável, e libera 10-15h/semana do fundador. Use esse tempo para Fase 2 (refactoring). Quando a base estiver limpa e os Tier 1-2 resolvidos, mergulhe na Fase 3 como projeto focado de ~7 semanas. A Fase 4 é o prêmio: Lead2Go se torna uma plataforma que escala sem você.
O maior risco não é técnico — é tentar fazer tudo ao mesmo tempo. Com 1.5 FTE, o segredo é sequência implacável: uma fase de cada vez, resultado tangível em cada uma, e disciplina para não pular etapas.