Resumo rápido. Forward Deployed Engineering (FDE) é o modelo de entrega em que engenheiros de software embarcam dentro da operação do cliente, com acesso aos dados e sistemas reais, e escrevem código que vai para produção naquele ambiente. A diferença em relação à consultoria, à alocação de profissionais e ao squad ágil não é de intensidade, é de entregável: o FDE não entrega recomendação nem protótipo, entrega sistema funcionando sobre os dados do cliente. O modelo nasceu na Palantir em 2006 e voltou ao centro do debate porque a parte difícil da IA corporativa deixou de ser o modelo e passou a ser o deployment.
Forward Deployed Engineering é o modelo de entrega em que engenheiros de software embarcam dentro da operação do cliente, com acesso aos dados e sistemas reais, e escrevem código que vai para produção naquele ambiente, em vez de entregar recomendação, diagnóstico ou protótipo.
Definição canônica: Um Forward Deployed Engineer é um engenheiro de software que escreve e depura código de produção dentro do ambiente operacional do cliente, respondendo pelo funcionamento do sistema entregue, não apenas pela sua construção.
Vale separar o profissional do modelo. O Forward Deployed Engineer é a pessoa. O Forward Deployed Engineering é a forma de entrega que organiza a estrutura de engajamento, os critérios de sucesso e a relação contratual. Empresas diferentes usam títulos diferentes para o mesmo papel: Forward Deployed Software Engineer (FDSE), Applied AI Engineer (o título que a Anthropic adotou em seu time), Deployment Strategist. A nomenclatura varia; a substância não.
A assimetria que define o papel é esta: um engenheiro de produto constrói uma capacidade para muitos clientes. O Forward Deployed Engineer constrói muitas capacidades para um cliente. Isso muda o que ele precisa saber, como ele opera e o que mede como sucesso.
O modelo nasceu na Palantir por volta de 2006, quando ficou claro que vender software de integração de dados para clientes de defesa e inteligência não funcionava. O produto era capaz, o cliente não conseguia operacionalizá-lo. A solução foi parar de enviar software e começar a enviar engenheiros para construir os fluxos dentro do cliente.
A linha do tempo é relevante porque explica por que o modelo é difícil de replicar:
O retorno não é tendência de mercado de RH. É uma resposta a um problema estrutural: a parte mais difícil da adoção de IA corporativa deixou de ser a capacidade do modelo e passou a ser a integração com o ambiente real do cliente. Dados fragmentados, sistemas de registro que não têm API, controles de acesso, compliance regulatório e processos de trabalho que existem há anos e não vão se reorganizar para o software novo. Essas barreiras só aparecem quando o engenheiro está dentro, com acesso real, escrevendo contra dados reais.
A diferença não é de intensidade nem de discurso. É de entregável e de posição na cadeia. A consultoria entrega recomendação e opera antes da implementação. A alocação entrega horas de profissional. A squad ágil entrega backlog executado. O FDE entrega sistema em produção rodando sobre os dados reais do cliente, com o engenheiro respondendo pelo resultado e não apenas pela entrega.
| Modelo | Entregável final | Quem responde pelo resultado | Onde vive o código | Quando faz sentido |
| Consultoria | Relatório, diagnóstico, roadmap | A empresa contratante, após o contrato | Fora da operação do cliente | Problema de decisão estratégica, não de implementação |
| Alocação de profissionais | Horas de trabalho de um profissional alocado | A empresa contratante, que gerencia o alocado | No ambiente que a empresa já mantém | Quando a empresa tem arquitetura própria e só precisa de capacidade adicional |
| Squad ágil | Incrementos de backlog entregues por sprint | Compartilhada entre a squad e o PO do cliente | No repositório do produto sendo desenvolvido | Quando há produto definido a ser construído com time dedicado |
| Forward Deployed Engineering | Sistema em produção rodando sobre dados e sistemas reais do cliente | O time FDE durante o engajamento, depois o time interno do cliente | No ambiente de produção do cliente, com código transferido | Quando o problema é conhecido, o valor é alto e o obstáculo está na complexidade do ambiente |
Dois pontos merecem honestidade antes de avançar. Primeiro: consultoria é o modelo correto quando o problema ainda é de diagnóstico estratégico, não de implementação. Contratar FDE antes de saber qual processo atacar é desperdiçar capacidade cara. Segundo: alocação funciona bem quando a empresa já tem arquitetura definida e squad de engenharia própria, precisando apenas de capacidade adicional em tecnologia específica.
O padrão de falha do modelo FDE é conhecido: quando não há mecanismo de generalização, o engajamento se transforma em desenvolvimento sob medida indefinido, onde o cliente depende eternamente do fornecedor para qualquer mudança. O antídoto, que os times de FDE mais maduros operam, é identificar padrões que se repetem entre deployments e generalizá-los em produto ou plataforma. É o que a Palantir fez ao lançar o Foundry. É o que um fornecedor de FDE responsável deveria fazer com as soluções que constrói.
Porque o piloto e a produção resolvem problemas diferentes. O piloto testa se o modelo consegue realizar uma tarefa. A produção exige que esse modelo funcione integrado a dados sujos, a sistemas legados que não têm API documentada, a controles de acesso que ninguém documentou, a uma trilha de auditoria que o regulador pode pedir amanhã e a um processo de trabalho que existe há anos e não vai parar para se adaptar ao software novo.
As barreiras mais comuns, em ordem de frequência com que aparecem nos primeiros dias de um engajamento real:
Há uma razão estrutural para tudo isso: é possível entrevistar usuários sobre o processo que eles acreditam ter. Não é possível entrevistar um sistema legado sobre as exceções que ele trata em silêncio há dez anos. Falar com usuários tem valor; trabalhar ao lado deles, contra dados reais, revela o que a entrevista não captura.
A dimensão regulatória, notadamente LGPD, residência de dados e trilha de auditoria, é um capítulo à parte que merece tratamento próprio — a interseção com FDE é real: o engenheiro embarcado precisa construir dentro dos controles que o compliance exige, e não depois que eles forem definidos.
FDE faz sentido quando o problema é conhecido, o valor é alto e o obstáculo está na complexidade do ambiente do cliente, não na capacidade da tecnologia. Não faz sentido quando o escopo é padronizado, quando existe produto pronto que resolve, ou quando a empresa ainda não decidiu qual problema quer resolver.
Sinais de que você provavelmente precisa do modelo FDE:
Sinais de que o modelo FDE provavelmente não é o correto:
O critério de investimento e as métricas de retorno merecem análise própria de cada caso de uso antes de começar — o que se mede, com que linha de base, e o que caracteriza sucesso.
Um engajamento FDE tem quatro momentos: imersão na operação, definição do primeiro caso de uso com valor mensurável, construção em produção sobre os dados reais e transferência de conhecimento para o time interno.
Fase 1: Imersão. O que sai desta fase: um mapa de processos com dados reais de acesso, qualidade e volume, e a lista ordenada por valor de casos de uso viáveis.
O engenheiro não começa a escrever código. Começa a observar. Quais são os sistemas de registro. Onde os dados residem. Quais as exceções que o analista resolve manualmente sem que o processo documente. Quais as restrições de acesso e de compliance que definem o que pode ser construído. Sem esse mapa, qualquer arquitetura desenhada de fora é especulação.
O cliente precisa fornecer nesta fase: acesso aos ambientes relevantes, ponto focal de negócio disponível, e tolerância para perguntas que vão parecer básicas e não são.
Fase 2: Definição do primeiro caso de uso. O que sai desta fase: especificação técnica do primeiro caso de uso, com linha de base mensurável e critério de sucesso acordado antes de começar a construção.
O primeiro caso de uso não é necessariamente o mais importante. É o que combina valor mensurável, viabilidade técnica dentro das restrições reais e velocidade de entrega. Definir a linha de base antes de começar é responsabilidade compartilhada: o cliente fornece os dados históricos do processo, o engenheiro valida que é possível medir a diferença depois.
Fase 3: Construção em produção. O que sai desta fase: sistema em produção, versionado no repositório do cliente, com documentação técnica e testes automatizados.
O código vive no repositório do cliente desde o primeiro commit. O acesso ao ambiente de produção é gerenciado pelo time de TI do cliente, com o engenheiro da Sauter operando dentro dos controles estabelecidos. A construção em produção revela as barreiras reais, que são resolvidas à medida que aparecem, não antecipadas em um documento de arquitetura.
Fase 4: Transferência de conhecimento. O que sai desta fase: time interno do cliente capaz de operar, estender e manter o sistema sem dependência do fornecedor.
Um engajamento FDE bem feito termina com o cliente autônomo. Isso significa documentação que um engenheiro que não participou da construção consegue ler e entender, sessões de transferência com o time interno, e um período de coexistência onde os dois times operam juntos antes da saída. A transferência não é cortesia: é critério de sucesso do engajamento.
O time precisa reunir três competências que raramente moram na mesma pessoa: engenharia de software de produção, domínio da plataforma de dados e de IA que sustenta a solução, e capacidade de conversar com a operação do cliente sem intermediário.
Engenharia de produção. O FDE escreve código que vai para produção no cliente. Isso exige familiaridade com práticas de engenharia de software, não apenas com as APIs dos modelos de linguagem. Teste automatizado, controle de versão, observabilidade, deploy em ambiente restrito são parte do trabalho, não opcional.
Domínio de plataforma. A profundidade em uma plataforma específica, Google Cloud, Vertex AI, BigQuery, arquitetura de agentes com Claude, é o que permite construir rápido e construir certo. Certificações são a evidência verificável dessa profundidade.
Capacidade de operar em ambiguidade. Requisito incompleto é condição normal de trabalho nesse modelo. O cliente não sabe descrever o processo que executa com a precisão que uma especificação técnica exige. O FDE descobre o requisito real trabalhando, não perguntando. Isso exige tolerância a incerteza e habilidade de fazer as perguntas que revelam a restrição, não as que confirmam o que o engenheiro já supõe.
A Sauter é Google Cloud Premier Partner e a primeira parceira oficial da Anthropic no Brasil. As certificações do time são evidência verificável da profundidade técnica nas plataformas que sustentam os engajamentos de FDE.
O retorno de um engajamento FDE se mede por três indicadores que precisam existir antes e depois da entrega: tempo de ciclo do processo atacado, custo unitário da operação e taxa de uso do sistema entregue pelas pessoas que deveriam usá-lo.
O que não medir: número de casos de uso mapeados, horas entregues pelo time de engenharia, quantidade de pilotos realizados, reuniões de alinhamento conduzidas. Essas métricas medem esforço, não resultado. Um engajamento que entrega 40 horas de reunião e zero sistemas em produção gerou zero retorno.
Avalie um fornecedor de FDE por três evidências verificáveis: sistemas em produção que ele pode nomear, engenheiros certificados nas plataformas que vai usar, e disposição contratual de responder por indicador de operação e não por entrega de documento.
As perguntas abaixo servem para avaliar qualquer fornecedor, inclusive a Sauter. É exatamente esse desprendimento que torna o checklist útil:
Sinais de alerta durante a avaliação: proposta que termina em relatório ou roadmap, equipe que só aparece em reunião e não tem acesso ao ambiente, ausência de código versionado no repositório do cliente ao longo do engajamento, recusa de transferência de conhecimento, incapacidade de nomear sistemas em produção com os dados do cliente.
A Sauter opera mais de 1.000 projetos entregues, mais de 300 clientes ativos e mais de 120 engenheiros. É Google Cloud Premier Partner e primeira parceira oficial da Anthropic no Brasil. A prática de FDE está ativa, com engajamentos em empresas de médio e grande porte e em setor público.
A Sauter opera FDE embarcando engenheiros certificados em Google Cloud e Anthropic na operação do cliente para construir sistemas de IA que rodam em produção, com transferência de conhecimento ao time interno ao final do engajamento.
O portfólio que o time acessa inclui engenharia de dados, IA generativa com modelos Claude e Gemini, arquitetura de agentes, plataforma Google Cloud (Vertex AI, BigQuery, Cloud Run) e os produtos proprietários da Sauter, como o Plexy AI, quando fazem sentido para o caso de uso do cliente.
Em setor público, o mesmo modelo se aplica com atenção às restrições específicas de residência de dados, controles de acesso e conformidade regulatória que os órgãos exigem.
Se você tem um caso de uso parado entre o piloto e a produção, fale com um engenheiro da Sauter.
O que significa Forward Deployed Engineering? Forward Deployed Engineering é o modelo de entrega em que engenheiros de software embarcam dentro da operação do cliente, com acesso aos dados e sistemas reais, e escrevem código que vai para produção naquele ambiente. O entregável é um sistema em funcionamento, não um relatório, diagnóstico ou protótipo.
Qual a diferença entre um Forward Deployed Engineer e um consultor? Um consultor entrega recomendação e opera antes da implementação. O Forward Deployed Engineer escreve código de produção dentro do ambiente do cliente e responde pelo funcionamento do sistema entregue. A posição na cadeia é diferente: o consultor trabalha antes da decisão de implementar; o FDE trabalha durante e responde pelo resultado.
Quem criou o modelo FDE? O modelo foi criado pela Palantir por volta de 2006. A empresa, que vendia software de análise de dados para agências de inteligência e defesa americana, descobriu que o produto funcionava mas os clientes não conseguiam operacionalizá-lo. A solução foi embedar engenheiros dentro das agências para construir os fluxos diretamente. Shyam Sankar, um dos primeiros funcionários, é creditado por tornar a prática repetível.
Por que empresas de IA como Anthropic e OpenAI adotaram o modelo FDE? Porque a parte mais difícil da adoção de IA corporativa deixou de ser a capacidade do modelo e passou a ser o deployment. Dados fragmentados, sistemas legados, controles de acesso e processos de trabalho consolidados só aparecem como barreira quando o engenheiro está dentro, com acesso real. A Anthropic descreve seus Applied AI Engineers como FDEs que embarcam nos clientes para construir aplicações com Claude em produção.
Escrito pelo Time Técnico e de Customer Experience da Sauter.
Quick summary. Forward Deployed Engineering (FDE) is the delivery model where software engineers embed inside the client's operation, with access to real data and systems, and write code that goes to production in that environment. The difference compared to consulting, staff augmentation and agile squads isn't intensity, it's the deliverable: FDE doesn't deliver a recommendation or a prototype, it delivers a system running on the client's data. The model was born at Palantir in 2006 and returned to the center of the debate because the hard part of enterprise AI stopped being the model and became deployment.
Forward Deployed Engineering is the delivery model where software engineers embed inside the client's operation, with access to real data and systems, and write code that goes to production in that environment, instead of delivering a recommendation, diagnosis or prototype.
Canonical definition: A Forward Deployed Engineer is a software engineer who writes and debugs production code inside the client's operational environment, accountable for the delivered system working, not just for building it.
It's worth separating the professional from the model. The Forward Deployed Engineer is the person. Forward Deployed Engineering is the delivery format that organizes the engagement structure, success criteria and contractual relationship. Different companies use different titles for the same role: Forward Deployed Software Engineer (FDSE), Applied AI Engineer (the title Anthropic adopted for its team), Deployment Strategist. The naming varies; the substance doesn't.
The asymmetry that defines the role is this: a product engineer builds one capability for many clients. The Forward Deployed Engineer builds many capabilities for one client. That changes what they need to know, how they operate, and what they measure as success.
The model was born at Palantir around 2006, when it became clear that selling data-integration software to defense and intelligence clients wasn't working. The product was capable, the client couldn't operationalize it. The solution was to stop shipping software and start shipping engineers to build the workflows inside the client.
The timeline matters because it explains why the model is hard to replicate:
The comeback isn't an HR market trend. It's a response to a structural problem: the hardest part of enterprise AI adoption stopped being model capability and became integration with the client's real environment. Fragmented data, systems of record without APIs, access controls, regulatory compliance, and work processes that have existed for years and won't reorganize for new software. These barriers only surface when the engineer is inside, with real access, writing against real data.
The difference isn't intensity or messaging. It's the deliverable and the position in the chain. Consulting delivers a recommendation and operates before implementation. Staff augmentation delivers hours of a professional's work. The agile squad delivers executed backlog. FDE delivers a system in production running on the client's real data, with the engineer accountable for the outcome, not just the delivery.
| Model | Final deliverable | Who's accountable for the result | Where the code lives | When it makes sense |
| Consulting | Report, diagnosis, roadmap | The hiring company, after the contract | Outside the client's operation | Strategic decision problem, not implementation |
| Staff augmentation | Hours of work from an allocated professional | The hiring company, which manages the allocated professional | In the environment the company already maintains | When the company has its own architecture and just needs extra capacity |
| Agile squad | Backlog increments delivered per sprint | Shared between the squad and the client's PO | In the repository of the product being developed | When there's a defined product to be built with a dedicated team |
| Forward Deployed Engineering | Production system running on the client's real data and systems | The FDE team during the engagement, then the client's internal team | In the client's production environment, with code transferred | When the problem is known, value is high, and the obstacle is environment complexity |
Two points deserve honesty before moving on. First: consulting is the right model when the problem is still one of strategic diagnosis, not implementation. Hiring FDE before knowing which process to attack wastes expensive capacity. Second: staff augmentation works well when the company already has a defined architecture and its own engineering squad, needing only extra capacity in a specific technology.
The FDE model's known failure pattern: when there's no generalization mechanism, the engagement turns into indefinite custom development, where the client depends on the vendor forever for any change. The antidote, which the most mature FDE teams operate, is identifying patterns that repeat across deployments and generalizing them into a product or platform. That's what Palantir did when it launched Foundry. It's what a responsible FDE vendor should do with the solutions it builds.
Because the pilot and production solve different problems. The pilot tests whether the model can perform a task. Production requires that model to work integrated with dirty data, legacy systems without documented APIs, undocumented access controls, an audit trail the regulator might request tomorrow, and a work process that has existed for years and won't pause to adapt to new software.
The most common barriers, in the order they tend to appear in the first days of a real engagement:
There's a structural reason for all of this: you can interview users about the process they believe they have. You can't interview a legacy system about the exceptions it has silently handled for ten years. Talking to users has value; working alongside them, against real data, reveals what the interview doesn't capture.
The regulatory dimension, notably LGPD, data residency and audit trail, deserves its own dedicated treatment — the intersection with FDE is real: the embedded engineer needs to build within the controls compliance requires, not after they're defined.
FDE makes sense when the problem is known, the value is high, and the obstacle is the complexity of the client's environment, not the technology's capability. It doesn't make sense when the scope is standardized, when an off-the-shelf product solves it, or when the company hasn't yet decided which problem to solve.
Signs you probably need the FDE model:
Signs the FDE model probably isn't right:
The investment criteria and return metrics deserve their own analysis for each use case before starting — what to measure, against what baseline, and what defines success.
An FDE engagement has four moments: immersion in the operation, definition of the first measurable-value use case, building in production on real data, and knowledge transfer to the internal team.
Phase 1: Immersion. What comes out of this phase: a process map with real data on access, quality and volume, and a value-ranked list of viable use cases.
The engineer doesn't start by writing code. They start by observing. What are the systems of record. Where does the data live. What exceptions does the analyst resolve manually without the process documenting them. What access and compliance restrictions define what can be built. Without this map, any architecture designed from outside is speculation.
What the client needs to provide in this phase: access to the relevant environments, an available business focal point, and tolerance for questions that will seem basic and aren't.
Phase 2: Defining the first use case. What comes out of this phase: technical specification of the first use case, with a measurable baseline and success criteria agreed before building starts.
The first use case isn't necessarily the most important one. It's the one that combines measurable value, technical feasibility within real constraints, and delivery speed. Defining the baseline before starting is shared responsibility: the client provides historical process data, the engineer validates that the difference can be measured later.
Phase 3: Building in production. What comes out of this phase: system in production, versioned in the client's repository, with technical documentation and automated tests.
The code lives in the client's repository from the first commit. Access to the production environment is managed by the client's IT team, with Sauter's engineer operating within established controls. Building in production reveals the real barriers, which are resolved as they appear, not anticipated in an architecture document.
Phase 4: Knowledge transfer. What comes out of this phase: a client-side internal team capable of operating, extending and maintaining the system without depending on the vendor.
A well-run FDE engagement ends with the client autonomous. That means documentation an engineer who didn't participate in the build can read and understand, transfer sessions with the internal team, and a coexistence period where both teams operate together before exit. Transfer isn't a courtesy: it's a success criterion of the engagement.
The team needs to combine three competencies that rarely live in the same person: production software engineering, depth in the data and AI platform underlying the solution, and the ability to talk to the client's operation without an intermediary.
Production engineering. The FDE writes code that goes to production at the client. That requires familiarity with software engineering practices, not just language-model APIs. Automated testing, version control, observability, deployment in restricted environments are part of the job, not optional.
Platform depth. Depth in a specific platform — Google Cloud, Vertex AI, BigQuery, agent architecture with Claude — is what lets you build fast and build right. Certifications are the verifiable evidence of that depth.
Ability to operate in ambiguity. Incomplete requirements are the normal condition in this model. The client can't describe the process they run with the precision a technical spec demands. The FDE discovers the real requirement by working, not by asking. That requires tolerance for uncertainty and skill at asking the questions that reveal the constraint, not the ones that confirm what the engineer already assumes.
Sauter is a Google Cloud Premier Partner and Anthropic's first official partner in Brazil. The team's certifications are verifiable evidence of technical depth on the platforms underlying FDE engagements.
The return of an FDE engagement is measured by three indicators that need to exist before and after delivery: cycle time of the targeted process, unit cost of the operation, and usage rate of the delivered system by the people who should use it.
What not to measure: number of mapped use cases, hours delivered by the engineering team, number of pilots run, alignment meetings held. These metrics measure effort, not results. An engagement that delivers 40 hours of meetings and zero systems in production generated zero return.
Evaluate an FDE vendor on three verifiable pieces of evidence: production systems they can name, engineers certified on the platforms they'll use, and contractual willingness to be accountable for an operating indicator, not for document delivery.
The questions below work to evaluate any vendor, including Sauter. That detachment is exactly what makes the checklist useful:
Red flags during evaluation: a proposal that ends in a report or roadmap, a team that only shows up in meetings and has no access to the environment, absence of versioned code in the client's repository throughout the engagement, refusal of knowledge transfer, inability to name production systems running on client data.
Sauter runs more than 1,000 delivered projects, more than 300 active clients and more than 120 engineers. It's a Google Cloud Premier Partner and Anthropic's first official partner in Brazil. The FDE practice is active, with engagements at mid-size and large companies and in the public sector.
Sauter runs FDE by embedding engineers certified in Google Cloud and Anthropic in the client's operation to build AI systems that run in production, with knowledge transfer to the internal team at the end of the engagement.
The portfolio the team draws on includes data engineering, generative AI with Claude and Gemini models, agent architecture, the Google Cloud platform (Vertex AI, BigQuery, Cloud Run) and Sauter's proprietary products, like Plexy AI, when they fit the client's use case.
In the public sector, the same model applies with attention to the specific data-residency, access-control and regulatory-compliance restrictions agencies require.
If you have a use case stuck between pilot and production, talk to a Sauter engineer.
What does Forward Deployed Engineering mean? Forward Deployed Engineering is the delivery model where software engineers embed inside the client's operation, with access to real data and systems, and write code that goes to production in that environment. The deliverable is a working system, not a report, diagnosis or prototype.
What's the difference between a Forward Deployed Engineer and a consultant? A consultant delivers a recommendation and operates before implementation. The Forward Deployed Engineer writes production code inside the client's environment and is accountable for the delivered system working. The position in the chain is different: the consultant works before the decision to implement; the FDE works during and is accountable for the result.
Who created the FDE model? The model was created by Palantir around 2006. The company, which sold data-analysis software to US intelligence and defense agencies, discovered the product worked but clients couldn't operationalize it. The solution was embedding engineers inside the agencies to build the workflows directly. Shyam Sankar, one of the earliest employees, is credited with making the practice repeatable.
Why did AI companies like Anthropic and OpenAI adopt the FDE model? Because the hardest part of enterprise AI adoption stopped being model capability and became deployment. Fragmented data, legacy systems, access controls and entrenched work processes only surface as barriers when the engineer is inside, with real access. Anthropic describes its Applied AI Engineers as FDEs who embed at clients to build production applications with Claude.
Written by Sauter's Technical and Customer Experience Team.