Dois terços do nosso trabalho de implementação agora é feito de forma autônoma pelo nosso próprio produto (via Duet).
Este post é sobre por que isso acontece, nossa filosofia de construir um produto e um modelo de implementação, e como isso evoluiu ao longo do tempo.
Algo que costumávamos desprezar agora é a resposta padrão
"Forward Deployed Engineer" se tornou a resposta para quase todas as perguntas difíceis no go-to-market de IA. Implementações são dolorosas? Contrate FDEs. Clientes não conseguem se servir sozinhos? FDEs. Produto não está pronto? FDEs. A Anthropic e a OpenAI criaram divisões de implementação empresarial explicitamente modeladas na Palantir, e toda startup em estágio inicial com quem converso agora tem uma vaga de FDE aberta. As vagas com esse título supostamente cresceram várias centenas de por cento no último ano.
O estranho é que isso era, até muito recentemente, algo pelo qual você era criticado. Colocar engenheiros dentro dos clientes era visto como sinal de que você não tinha um produto de verdade: sua receita era de menor qualidade e suas margens eram estruturalmente limitadas. Nada sobre a economia subjacente mudou.
O ponto-chave dos FDEs é que eles entregam resultados. Isso é incrível na era da IA, porque as empresas podem não ter certeza do caminho até o resultado, mas está claro que a IA gera resultados atraentes.
Ao mesmo tempo, o papel está virando muleta e não deve ser usado para esconder um problema estrutural.
"FDEs devoram dor e excretam produto"
A Palantir (de onde veio meu cofundador @AshwinSreenivas) popularizou o papel em meados dos anos 2000 vendendo o Gotham para a CIA, NSA e unidades de inteligência do Exército. E eles aguentaram as críticas por muito tempo. Joe Lonsdale, um dos cofundadores, escreveu que durante quase duas décadas a visão mainstream da Palantir era a de uma consultoria glorificada, e não uma empresa de tecnologia de verdade, e que essa visão se baseava em uma observação verdadeira: muitos dos seus engenheiros passavam muito tempo sentados com clientes.
Mas Shyam Sankar, CTO da Palantir, tinha uma frase que repetia constantemente: FDEs devoram dor e excretam produto.
As primeiras implementações do Gotham na Palantir eram profundamente sob medida, construídas para responder a uma pergunta de inteligência específica para uma unidade. A Palantir codificou os problemas que observaram como primitivas de plataforma: a ontologia, os modelos de objetos, permissões, motores de workflow, rastreamento de proveniência. Essas primitivas se tornaram o Foundry. O Foundry se tornou algo que podia ser vendido comercialmente. Apollo e AIP seguiram o mesmo caminho.
Nada disso teria existido sem engenheiros devorando dor no campo antes. A dor era o insumo do produto, não um custo de venda.
Conforme o Foundry amadureceu, implementações padronizadas reduziram drasticamente a necessidade de trabalho customizado, as margens brutas subiram para a casa dos 80%, e a Palantir migrou de um modelo liderado por FDEs para vendas baseadas em contas. Muitos desses FDEs migraram para a engenharia principal. Eles também ficaram famosos por recusar contratos em que o cliente só queria uma Accenture com software melhor.
O time de FDEs não era o modelo de negócio. Era o caminho para construir o produto certo.
Por que algumas startups de IA realmente precisam de FDEs agora
Se você estivesse construindo um SaaS de CRM em 2015, não precisava descobrir o workflow. Durante vinte anos, muita gente já tinha pensado sobre o que é um pipeline, o que é um estágio, como é um handoff de lead.
Se você está construindo um agente de IA para contabilidade em 2026, não existe workflow estabelecido, porque literalmente ninguém nunca usou um desses. Ninguém sabe como é a jornada do usuário — nem você e, principalmente, nem seu cliente. Eles não conseguem te dizer o que querem, porque a coisa que eles quereriam ainda não tem forma.
Essa é a mesma situação em que a Palantir começou. A lógica do Lonsdale era que eles foram forward-deployed por necessidade: tinham tecnologia forte e nenhuma ideia de como seus primeiros clientes de defesa e inteligência realmente funcionavam.
Então sim, mande engenheiros. Sente na sala. Veja sua coisa quebrar de formas que seus testes nunca imaginaram. Em uma categoria genuinamente nova, a última milha não é um problema de entrega, é um problema de descoberta, e não há substituto para estar lá.
A armadilha não é começar. É não parar.
Quando você souber quais são as jornadas do usuário de verdade, comece a tirar os FDEs do campo.
Você não vai querer. Não porque alguém toma uma decisão ruim, mas porque é mais fácil mantê-los em todas as sprints.
FDEs permitem que você evite todas as decisões difíceis de produto. Você nunca precisa decidir o que o produto faz, nem qual das duas demandas de clientes vence, nem onde termina a superfície de configuração. Parece de graça. Ninguém precisa dizer não para ninguém. Nenhuma decisão arquitetural dolorosa é tomada. O cliente fica encantado.
E agora você tem todas as desvantagens do modelo e nenhum dos benefícios de descoberta. Seu custo de atendimento não diminui. Suas margens continuam limitadas. Seu crescimento é limitado por contratações. Cada correção sob medida no campo é uma decisão de produto que você escolheu não tomar. Cada implementação deve facilitar a próxima.
Além disso, pouquíssimas startups conseguem fechar os contratos de 8 dígitos que a Palantir fechava logo de cara, o que torna a economia ainda mais difícil de sustentar.
Mais uma coisa para não confundir
FDE também não é a mesma coisa que implementação. "Construir essa integração no sistema de tickets deles" é um trabalho real e necessário, mas é execução contra uma especificação conhecida, não descoberta de uma especificação desconhecida. Juntar os dois sob um mesmo título é como as empresas se convencem de que uma organização de serviços em crescimento é um investimento em produto.
Modelos escrevem código bem o suficiente agora para que muito do que um time de implementação fazia em 2023 esteja se tornando algo que o próprio produto faz. Eventualmente, você vai conseguir construir um agente que faça todo o trabalho da última milha de ponta a ponta. Ele pode observar workflows e até entrevistar clientes.
O que fizemos em vez disso
No nosso caso específico com a @DecagonAI, acreditamos fundamentalmente que uma abordagem orientada a produto é a resposta, em vez de uma orientada a serviços ou FDEs. Atendimento ao cliente é de alto volume, repetível e decomponível, e quando falamos com empresas, duas coisas são sempre consistentes:
- Velocidade de iteração é fundamental. Lançar um agente de IA não é uma coisa única. Ele precisa ser constantemente ajustado e atualizado ao longo do tempo. Se cada ajuste exigir engenharia, vai ser lento e caro demais para escalar.
- Lock-in de fornecedor e soberania. Dada a experiência das organizações com SaaS, ninguém quer ficar preso a um fornecedor e dependente dos recursos deles.
Nos primeiros dias, o Ashwin e eu construímos pessoalmente o que os clientes pediam. Conforme o produto decolou, tomamos a decisão explícita de que nossa proposta de valor central seria ter o melhor produto.
Para ser claro, ainda fazemos parceria com o cliente para entregar o resultado de ponta a ponta. No entanto, mesmo nesse processo, nós somos donos da construção, enquanto habilitamos o time deles no nosso produto e entregamos as chaves. Conforme o produto amadureceu, o trabalho específico de clientes que nosso time de engenharia fazia caiu drasticamente.
Essa decisão teve seus tradeoffs. Significou não improvisar algo no campo quando isso teria sido mais rápido. Significou transformar escalações em requisitos em vez de patches, o que leva tempo no curto prazo.
O retorno:
- Dois terços do trabalho de implementação agora acontece autonomamente pelo Duet: configuração, iteração, a longa cauda de ajustes que costumava exigir um humano no loop.
- Leva em média apenas alguns dias para lançar o primeiro AOP, mesmo para grandes bancos, companhias aéreas, operadoras de telecom, etc.
Ainda há muito trabalho a fazer, mas estamos na jornada.
Então: FDE ou não FDE?
Vá forward-deployed cedo. Capte o sinal. Coloque seus engenheiros na frente dos clientes para sempre.
Depois faça as perguntas certas. O sob medida está no ambiente do seu cliente ou nas lacunas do seu próprio produto? A última milha é irredutível ou simplesmente não foi construída? Seus FDEs estão descobrindo algo ou absorvendo algo? E o que foi construído no produto na última vez que um deles voltou?
Use FDEs para descobrir o que precisa existir no produto. FDEs devoram dor e excretam produto. Se os seus estão devorando dor e excretando mais dor, você não tem um time de FDEs. Você tem um negócio de serviços.
