Como a LangChain construiu um agente de IA que passou a gerar 20% do pipeline de vendas

Por que isso importa agora

Durante os três primeiros anos, o pipeline de vendas da LangChain cresceu de forma orgânica — open source, conteúdo, YouTube, comunidade e meetups. Em janeiro de 2026, a empresa decidiu acelerar o programa de publicidade paga para alcançar prospects que não atingia organicamente: novas regiões e tomadores de decisão em grandes empresas. O desafio: escalar de um motor majoritariamente orgânico para cinco canais pagos em seis meses, com uma equipe de marketing enxuta.

O case, detalhado no blog oficial da empresa, é uma das descrições mais concretas já publicadas de como um agente de IA em produção é projetado, instrumentado e operado — não um protótipo, mas um sistema que roda semanalmente no Slack e move dinheiro real. O código foi open source e serve de ponto de partida para qualquer time que queira aplicar os mesmos padrões.

Resultados medidos

Antes dos detalhes técnicos, os números que justificam o investimento:

• A mídia paga passou de 0 a 20% do pipeline de marketing em seis meses.
• O custo por lead qualificado (CPL) caiu 30% de junho a agosto, enquanto o gasto mensal subiu cerca de 60%. No LinkedIn — maior canal social — o CPL ficou 40% menor que em janeiro.
• Economia de ~US$ 5 mil por mês ao internalizar análise e relatórios, antes feitos por uma agência.
• Otimização do próprio agente: mover cálculos para código e remover chamadas desnecessárias ao modelo deixou um fluxo de relatórios ~40x mais barato e 13x mais rápido (de 18 minutos para 85 segundos).

O que foi construído

O Paid Media Agent é um agente de longa duração que vive no Slack. Toda segunda-feira, combina dados das plataformas de anúncio com leads e pipeline do data warehouse, e publica um resumo com um PDF de marca explicando o que mudou, por quê e o que o time deve fazer. A equipe pode marcá-lo em uma thread para perguntas de acompanhamento, e ele propõe novas palavras-chave, mudanças de segmentação, textos de anúncio ou novas campanhas de busca.

Como foi construído: o agente como trabalhador do conhecimento

O princípio central é simples e poderoso: um agente de código é um trabalhador do conhecimento. Em vez de tratar o agente como um oráculo, o time o tratou como um analista recém-contratado — deram a ele um computador, o software necessário, acesso aos dados e documentação sobre como o negócio funciona.

O sistema operacional

O harness usado foi o LangChain Deep Agents, que gerencia acesso a arquivos, execução de código e memória de trabalho, além de ferramentas para planejar, delegar a subagentes e gerenciar contexto.

O computador

Cada execução roda em um sandbox LangSmith: uma microVM isolada com 32 GB de disco e um shell. O ambiente vem equipado com pandas e DuckDB para análise, openpyxl para planilhas e WeasyPrint + Jinja2 para relatórios. Para acelerar o startup, software e wiki são gravados em um snapshot, o que reduziu o tempo médio de inicialização em 10 segundos.

Contexto como mapa, não como depósito

Uma das lições mais transferíveis: o gargalo costuma ser a janela de contexto, não o modelo. Em vez de carregar todo o conhecimento no prompt do sistema (que ficaria caro e rapidamente obsoleto), o time trata o prompt como um mapa. O conhecimento vive em arquivos estruturados com localizações previsíveis, e o agente carrega apenas o contexto exigido pela tarefa. O contexto foi dividido em cinco camadas, ordenadas pela velocidade de mudança.

Seis lições técnicas de engenharia de agentes

1. Use o modelo para julgamento, código para consistência

Cálculos, regras de fonte da verdade e salvaguardas ficam no código. O modelo foca em interpretar resultados e recomendar próximos passos — mais rápido, mais barato e mais confiável.

2. Defina uma fonte da verdade para cada métrica

Com seis plataformas e esquemas diferentes, tentar normalizar tudo em um modelo único adicionaria complexidade sem aumentar a confiança. O time definiu qual sistema é confiável para cada métrica: as plataformas são a verdade para gasto, impressões e cliques; o warehouse é a verdade para leads e pipeline. Isso ficou evidente quando 10% do gasto do Google não mapeava no warehouse (campanhas de vídeo sem palavras-chave).

3. Deixe o agente descobrir ferramentas em vez de carregar tudo

O catálogo de ferramentas via MCP da Pipeboard expunha mais de 200 ferramentas; carregar apenas os nomes custava 38 mil tokens antes mesmo de ler a pergunta do usuário. A solução foi uma interface mínima com três operações — Search (encontra até oito ferramentas), Read (carrega o schema só da selecionada) e Run (executa). O primeiro turno caiu para ~12 mil tokens, 4x mais barato mantendo a mesma qualidade.

4. Projete o isolamento explicitamente

Contextos separados não dão isolamento automático. Dois subagentes escreviam no mesmo local e compartilhavam o mesmo flag de conclusão — um podia parar sem produzir relatório ao confundir o estado do outro. A correção: cada plataforma com local de relatório e estado próprios, e subagentes limitados a três ferramentas (ler contexto, computar, renderizar).

5. Dê ao agente um caminho da análise à ação

Um agente que só analisa é um dashboard melhorado. O Paid Media Agent propõe mudanças no Slack, mas com permissões e aprovação humana: o servidor valida o ID do usuário do Slack antes de aceitar qualquer edição, e cada mudança proposta aparece em um cartão de aprovação (Block Kit) que o revisor pode editar antes de aprovar. O código aplica a mudança e confirma na plataforma.

6. Combine a interface ao tipo de trabalho

O Slack funciona bem para decisões focadas. Para trabalhos mais complexos (muitos grupos de anúncios, edições em massa, revisões em várias rodadas), o time está migrando para uma interface dedicada construída em torno do agente.

O que levar para o próximo build

Os princípios que a equipe levaria para outro agente: equipar o agente como uma contratação (sandbox, bibliotecas, dados e documentação), separar instruções reutilizáveis do conhecimento da empresa (skills explicam o como, a wiki explica o negócio, ferramentas ao vivo fornecem o estado atual), usar código para o que deve ser reproduzível, projetar limites explicitamente e otimizar pela capacidade de concluir o trabalho — não apenas por custo e latência.