Construindo um agente de vendas outbound como um plugin do Claude Code

Eu administro uma pequena empresa de software em Tóquio. Sou engenheiro, não vendedor. O outbound frio era a parte do meu trabalho que eu sempre evitava. Então, construí um agente que faz isso por mim. Ele funciona como um plugin do Claude Code, e toda a pilha é de código aberto. Este post é sobre as decisões de arquitetura que importaram.

O produto é LeadAce (leadace.ai, código-fonte). Está em Beta Público. Ele encontra empresas que correspondem ao seu ICP, lê o site de cada empresa, escreve um e-mail por empresa e envia do seu próprio Gmail. Em seguida, coleta as respostas. E transforma cada rejeição em uma razão estruturada: orçamento, timing, comprador errado ou recurso ausente. Esses dados mudam o direcionamento da próxima rodada.

Por que um plugin, e não outro painel

A razão honesta: eu já passo o dia todo no Claude Code. Eu não queria construir mais um aplicativo web com uma caixa de chat nele.

Mais tarde, encontrei uma razão melhor. Um plugin do Claude Code roda no plano próprio do usuário da Anthropic, na máquina dele. Eu não faço proxy das chamadas LLM. Então, não preciso cobrar por elas. O preço cobre apenas o volume de envio e a infraestrutura. É por isso que o plano de entrada pode ser de $29/mês. Meus usuários são desenvolvedores que já pagam pelo Claude Pro ou Max. Para eles, "traga seu próprio tempo de execução de agente" é um recurso, não uma limitação.

O plugin é apenas a camada de UX. Tudo que é stateful é um backend SaaS normal por trás dele.

O modelo de plugin do Claude Code em 30 segundos

Se você ainda não construiu um: um plugin é um diretório com habilidades (instruções em markdown que se tornam comandos de barra), uma declaração opcional de servidor MCP e scripts. A distribuição é um repositório git:

claude plugin marketplace add aitit-inc/leadace
claude plugin install leadace@leadace

LeadAce envia habilidades como /leadace (onboarding: aponte para sua homepage), daily-cycle, build-list, outbound, check-responses e evaluate. Cada habilidade é um prompt que funciona como um programa. Ele contém instruções, guardrails e referências a ferramentas MCP e scripts locais. ${CLAUDE_PLUGIN_ROOT} resolve caminhos de arquivos dentro do plugin instalado. Isso pode parecer uma coisa pequena. Mas você precisa disso na primeira vez que um script auxiliar dentro do seu plugin precisa rodar na máquina de outra pessoa.

A divisão que importa: LLM vs ferramentas MCP vs ferramentas locais

A principal questão de design para qualquer produto de agente é esta: o que o modelo decide e o que é código?

Nossa divisão:

• Ferramentas MCP (lado do servidor, determinísticas): gravações de banco de dados, deduplicação, aplicação de cotas, verificações de conformidade, listas de não contatar. O modelo chama record_outreach. Ele não vê as doze regras de validação por trás disso. A validação é executada no servidor. Portanto, uma injeção de prompt escondida no site de alguma empresa não pode desativá-la.
• Ferramentas locais (máquina do usuário): coisas que precisam do ambiente do usuário. Enviando através do Gmail dele. Buscando páginas. Automação de navegador. Isso é o que mantém "envios do seu próprio inbox" verdadeiro.
• O LLM (julgamento): lendo o site de uma empresa e escolhendo o ângulo, escrevendo o e-mail, classificando uma resposta, atualizando a estratégia.

A regra que acabei adotando: se um erro causar um problema de conformidade ou de dados, deve ser código. Se um erro causar um problema de qualidade, o modelo pode fazê-lo, com portões de revisão ao redor.

Há mais um ponto que entendi tarde demais. Essa divisão também é a fronteira de confiança. O agente lê sites aleatórios o dia todo. O site de um prospect é uma entrada não confiável por definição. Portanto, qualquer coisa que toque o banco de dados ou envie e-mails deve ser um contrato fixo em código. Não deve ser algo que o modelo possa ser convencido a fazer.

Multi-tenancy: RLS como a rede de segurança

Cada tabela tem um tenant_id. Cada solicitação é executada em uma transação Postgres que começa com:

SET LOCAL ROLE app_rls
SET LOCAL app.tenant_id = '<tenant>'

app_rls é um papel com segurança em nível de linha aplicada. As políticas filtram em app.tenant_id. Os manipuladores de rota ainda escrevem consultas filtradas normais. RLS não é o mecanismo de consulta aqui. É a coisa que te salva no dia em que um manipulador esquece um where. Apenas o middleware de autenticação ignora o RLS, porque precisa resolver usuário → inquilino antes que o inquilino seja conhecido.

Todo o setup tem cerca de cem linhas. Este produto armazena listas de prospects e threads de e-mail de outras pessoas. Para esse risco, cem linhas é um seguro muito barato.

Uma variável de ambiente para desligar a cobrança

O backend tem um interruptor, LEADACE_EDITION. Ele tem dois valores: cloud e self-hosted.

No modo self-hosted, os endpoints do Stripe (/me/checkout, /me/portal, /stripe/webhook) retornam 404, e cada inquilino resolve para um plano ilimitado. O padrão é self-hosted. Portanto, uma nova implantação falha fechada no modo gratuito. Não pode executar acidentalmente a cobrança sem chaves.

Isso é o que torna a história de código aberto real. O serviço hospedado e a implantação auto-hospedada são o mesmo código. Hospedado é apenas a edição onde o Stripe está ativo. O alvo de implantação é Cloudflare Workers + Supabase. Os níveis gratuitos de ambos cobrem volume de solo e pequenas equipes. Portanto, a auto-hospedagem não custa nada.

Por que dar uma edição ilimitada? Porque meu comprador é um desenvolvedor. Um desenvolvedor pergunta "o que acontece se essa empresa desaparecer?" antes de conectar seu pipeline de outbound a um SaaS. Minha resposta: você implanta o mesmo repositório e continua. Essa resposta fecha a objeção melhor do que qualquer página de uptime. (A licença é uma Apache 2.0 modificada.)

O que eu faria diferente

• Enviar o único ponto de entrada primeiro. Durante semanas, o plugin teve muitas habilidades, mas nenhuma porta de entrada clara. A adoção ficou mais fácil no dia em que /leadace <seu-homepage> se tornou o único comando que configura tudo o mais.
• Construir o lado de recebimento mais cedo. Cada destinatário recebe uma página onde pode fazer perguntas antes de responder. Acredito que esse lado é o núcleo de longo prazo do produto. O roadmap é agente para agente via A2A, e o esquema de razão de rejeição se tornará uma especificação pública. Eu construí essa parte tarde demais.
• Não pré-carregar e mesclar para PUTs de upsert. Dois escritores concorrentes e um ciclo de leitura-modificação-gravação significam perda silenciosa de dados. Use o upsert do banco de dados.
• Tratar migrações como imutáveis uma vez que toquem qualquer ambiente. Eu editei uma migração Drizzle aplicada uma vez porque "é apenas staging". É assim que você obtém duas histórias divergentes.

Números e limites honestos

As taxas de resposta do outbound frio estão na casa dos dígitos únicos. O pitch não é "10x respostas". O pitch é que os nãos voltam como razões estruturadas em vez de silêncio. O envio é limitado a um ritmo humano por caixa de entrada, de propósito. Os destinatários estão limitados aos EUA, Canadá e Japão até que as regras de conformidade por país sejam implementadas. O plugin é verificado no macOS com o Claude Code hoje. Outros tempos de execução não são verificados.

Usamos o LeadAce para vender o LeadAce. Portanto, a maioria das razões de rejeição no meu painel são sobre meu próprio produto. Ler essas razões não é divertido. Mas é a tela mais útil do produto.

Código: github.com/aitit-inc/leadace · Produto:

O uso de agentes de IA para automação de vendas pode transformar a forma como empresas brasileiras abordam o marketing e a prospecção. A solução open-source permite que pequenas empresas adotem tecnologia avançada sem altos custos. Isso pode aumentar a competitividade no mercado.