O que é um Forward Deployed Engineer (FDE) e o que ele faz

Um FDE trabalha dentro do cliente, junto com as equipes dele, e é responsável por levar a tecnologia até o ponto em que ela resolve o problema do cliente, não um problema parecido.

A descrição mais direta vem de quem criou o cargo. Na vaga de Forward Deployed Software Engineer da Palantir, o trabalho é entender os maiores problemas do cliente e desenhar e implementar soluções. Os projetos costumam começar com uma pergunta aberta, como “por que estamos atrasando tantos voos?”, e não com uma especificação. A vaga compara a responsabilidade à de um CTO de startup: times pequenos, pouca supervisão e a execução de ponta a ponta de projetos de alto risco. Um mesmo dia pode ir de discutir arquitetura a tratar dados em grande escala, programar um aplicativo sob medida e conversar com executivos do cliente.

Dois traços separam o cargo do resto. O primeiro é a posição: o engenheiro está no ambiente do cliente, com acesso aos sistemas e aos dados, e não atendendo por chamado. O segundo é o critério de conclusão: o trabalho termina quando o sistema funciona na operação, não quando o código foi entregue.

O termo nasceu na Palantir. Shyam Sankar, hoje diretor de tecnologia da empresa, diz tê-lo criado em 2007, depois de o CEO, Alex Karp, perguntar por que os restaurantes franceses são tão bons. A resposta de Karp, como Sankar a conta: a equipe de salão faz parte da equipe de cozinha, conhece a comida e a técnica, e não apenas leva o prato da cozinha à mesa. Karp pediu algo equivalente para engenharia. É a fonte do nome, mas é o relato de uma das duas pessoas da conversa.

A lógica, nas palavras de Sankar, é a de não entregar o software por cima do muro e esperar que o cliente descubra sozinho como usá-lo. Segundo Sankar, os investidores da Palantir achavam a ideia ruim, porque o custo desses engenheiros pesava na margem, e ele defende que o modelo vale o custo por garantir que o cliente entenda o produto e extraia valor dele.

A comparação mais frequente é com consultoria. A diferença, segundo quem vende o modelo, está no formato do contrato e no tipo de acesso. Os pontos abaixo são o argumento dos fornecedores, e não uma regra que valha para todo FDE.

1. 01

   Escopo e cobrança

   A AWS argumenta que a diferença do FDE é não haver escopo fechado nem cobrança por hora: o cliente quer construir e o caminho não está definido de antemão.

2. 02

   Acesso

   Os analistas da Gartner descrevem o FDE como alguém que costuma ter acesso completo ao ambiente do cliente e ao código do fornecedor, e por isso constrói e itera em tempo real.

3. 03

   Quem responde pelo resultado

   Leitura da Invisible Work: quem atende chamados responde por resolver o pedido, e quem desenvolve o produto responde por todos os clientes ao mesmo tempo. O FDE responde por um cliente e por um problema, até ele funcionar.

Os fornecedores dão a mesma razão: as empresas têm dificuldade de transformar experimentos de IA em aplicações em produção. A AWS anunciou em junho uma organização própria de FDEs com US$ 1 bilhão, e a Microsoft, em julho, uma unidade de US$ 2,5 bilhões que diz ir além do modelo.

Um executivo da Cisco, ouvido pelo The Register, resume o que a IA acrescenta: modelos que não são determinísticos, avaliações, requisitos que mudam rápido e habilidades que nem toda equipe de cliente tem. É o tipo de problema que não aparece numa demonstração e que só se resolve com o engenheiro olhando o caso real.

Dois termos que acompanham esse debate têm guia próprio: os evals, que medem se o sistema acerta, e o harness, o sistema em volta do modelo que o faz agir como agente.

Há duas formas de ter um FDE, e elas têm riscos diferentes. Na primeira, o engenheiro é do fornecedor e vai ao cliente, como na Palantir e na AWS. Na segunda, a empresa forma o próprio engenheiro.

O Claude Frontier Academy, da Anthropic, é o exemplo da segunda. Em 2 de outubro de 2026, a Anthropic anunciou US$ 100 milhões para formar 10 mil “Frontier Deployed Engineers” até o fim de 2027. As empresas indicam os próprios engenheiros, cada um com um projeto nomeado para liderar, e eles passam por um curso presencial e por uma residência de 12 semanas na empresa de origem. A sigla é a mesma, FDE, mas a palavra mudou de “forward” para “frontier”, e o engenheiro passou de visitante a funcionário.

Nossa leitura, que é uma hipótese e não um fato da fonte, é que a segunda forma existe porque o que decide o resultado de um projeto de IA é o conhecimento da operação, e esse conhecimento é caro de transferir. Desenvolvemos o argumento em “A Anthropic gasta US$ 100 milhões para treinar engenheiros dos outros”.

A Invisible Work trabalha como FDE. Nossos engenheiros entram na operação do cliente, olham o processo como ele acontece, e não como está documentado, constroem a solução junto com a equipe e acompanham a entrada em produção. Diagnóstico e construção são fases do mesmo trabalho, e quem define a arquitetura é quem constrói.

O formato está descrito em Consultoria de IA aplicada. O que muda para o cliente, em comparação com um fornecedor que entrega e sai, é ter alguém dentro do problema até ele funcionar.

Segundo o The Register, Gartner e Forrester consideram o modelo útil e também avisam sobre o mesmo problema: a dependência do fornecedor. A Forrester descreve uma “armadilha do sob medida”, em que soluções muito ajustadas ao cliente aprofundam a dependência e tornam caro mudar depois. A Gartner lista dependência do fornecedor, exposição de segurança e dados, dívida técnica e atrofia de talento, que ocorre quando a empresa contrata FDEs e não treina a própria equipe, que vira operadora de uma caixa-preta.

Perguntas para quem vai contratar ou formar um FDE

São perguntas nossas, derivadas dos riscos acima, e não um padrão de mercado. Valem para qualquer FDE, inclusive para nós.