Forward deployed engineer: o que faz e como é o trabalho

O que faz um forward deployed engineer de IA: junto do cliente, do problema mal definido ao agente em produção. Rotina, habilidades e exemplos reais.

Forward deployed engineer é o engenheiro que trabalha junto do cliente e é dono do problema, do pedido ainda vago até o sistema rodando em produção. Com IA, isso quer dizer pegar um processo de negócio e transformar num agente, numa integração ou num pipeline de dados que alguém usa de verdade. Não é o meu cargo em nenhuma empresa, mas é a descrição mais exata de como eu trabalho como engenheiro de IA na DockPlus AI.

Por que o termo apareceu agora

No Google Trends, "forward deployed engineer" cresceu cerca de 6 vezes nos EUA em 12 meses. Ele também aparece como busca relacionada em alta (+300%) para quem pesquisa "AI engineer". Em português quase não há conteúdo sobre o assunto.

A explicação é simples. Modelos de linguagem ficaram bons o bastante para resolver problemas reais, mas o difícil não é chamar a API. O difícil é descobrir o que o cliente precisa, ligar o modelo aos sistemas que ele já usa e garantir que o resultado continue certo depois do deploy. Alguém precisa fazer esse trabalho perto do cliente.

Também há vagas remotas para a América Latina. Anúncios como os da Puente Talent Partners, da Assistant Launch, da Artefact e da South anunciam algo entre US$ 3 mil e 10 mil por mês, segundo os próprios anúncios.

O que faz um forward deployed engineer

A definição curta: fica embutido no cliente e responde pelo resultado, não por uma parte do código.

Na prática, isso dá três responsabilidades:

• Entender o problema no contexto do cliente. O pedido chega como "quero um assistente que cuide dos orçamentos". Cabe a quem está ali descobrir quais dados existem, quem aprova o quê e o que não pode dar errado.
• Construir a solução inteira. Backend, integrações, agente, deploy. Não dá para esperar outro time fazer a parte que falta.
• Ficar até funcionar. O trabalho não termina na entrega. Termina quando o sistema roda com dados reais e alguém percebe quando ele quebra.

Diferença para o engenheiro de software clássico e para o consultor

O engenheiro de software clássico costuma receber o problema já recortado: um ticket, uma especificação, um produto com roadmap. Ele é dono de um pedaço do sistema. O forward deployed engineer recebe o problema antes do recorte e decide o que construir.

O consultor também começa pelo problema do cliente, mas normalmente entrega diagnóstico, recomendação ou um plano. O forward deployed engineer entrega código em produção e responde por ele.

Dá para resumir assim: o consultor diz o que fazer, o engenheiro clássico constrói o que foi definido, e o forward deployed engineer faz as duas coisas e ainda opera o resultado.

A rotina: descoberta, protótipo, entrega, medição, endurecimento

O trabalho segue um ciclo curto que se repete.

1. Descoberta. Conversar com quem usa o processo, olhar os dados reais e listar as integrações. Aqui aparecem as restrições que nenhum documento conta.
2. Protótipo. Uma versão mínima que roda com dados de verdade, para o cliente reagir a algo concreto e não a uma descrição.
3. Entrega. Colocar em produção com autenticação, permissões e deploy repetível.
4. Medição. Ver o que acontece: logs, custo, erros, casos em que o agente fez algo estranho.
5. Endurecimento. Transformar cada falha encontrada numa regra, num teste ou num limite, e voltar ao passo 1 com o próximo problema.

Habilidades que mais pesam para um engenheiro de IA nesse papel

Integrações. Quase todo projeto real é IA ligada a sistemas que já existem: ERP, contabilidade, CRM, SMS, agenda. Saber ler uma API mal documentada e tratar falhas vale mais do que conhecer o modelo mais novo.

Dados. O agente só é tão bom quanto os dados que ele consulta. Muitas vezes o projeto começa por coletar e organizar dados que estão espalhados.

Avaliação e observabilidade. Sem medir, não dá para saber se o sistema piorou. Na DockPlus uso Langfuse para acompanhar latência, custo de tokens e qualidade das respostas, além de testes automatizados e logs de auditoria.

Comunicação. Explicar ao dono de uma empresa por que uma ação precisa de confirmação, ou por que um número não é comparável, faz parte do trabalho tanto quanto o código.

Exemplos do meu trabalho

Na DockPlus AI, onde sou CTO e co-fundador, atendo clientes no Brasil e nos EUA, do levantamento de requisitos à implantação e ao monitoramento. Desenvolvo com Claude Code. Três projetos mostram bem esse ciclo.

LedgerJob: agente de IA e MCP para empreiteiros dos EUA

O LedgerJob é um SaaS para empresas de construção nos EUA. O dono opera leads, orçamentos, projetos e faturas conversando com um agente, e as mesmas 66 ferramentas ficam disponíveis por um servidor MCP.

O ponto que mais tem a ver com o papel é a fronteira entre o agente e o negócio do cliente. Ação irreversível, como enviar e-mail ou SMS ou apagar dados, não roda dentro do loop do agente: vira um card que o usuário confirma. São 16 ferramentas nessa condição. A identidade vem da API key, nunca do modelo, e o MCP age com as permissões daquele usuário.

Um exemplo do passo de endurecimento: o assistente conseguiu agendar um compromisso "das 18h às 17h". A regra de horário saiu da rota HTTP e foi para a camada de serviço, com teste, porque o agente e o MCP não passam pelo validador HTTP. O sistema também integra Stripe, QuickBooks Online, Twilio, Google Calendar, EagleView, Hover e CompanyCam.

Cape Cod Permits: pipeline de dados para agentes

O Cape Cod Permits começou com um problema de dados: alvarás de obra de Massachusetts ficam espalhados em seis sistemas municipais sem API comum. Construí um coletor por plataforma, todos gravando numa base PostgreSQL, hoje com dados de 74 municípios.

A parte de operação é a que mais conta aqui. Cada resposta bruta fica gravada com hash e versão do parser, então dá para refazer a base sem baixar tudo de novo. Falhas ficam isoladas por plataforma. O health check mede progresso, então um travamento real aparece em 20 minutos.

O servidor MCP é somente leitura e as descrições das ferramentas mandam o agente checar a cobertura de cada município antes de comparar. É a mesma conversa que eu teria com um analista humano, escrita para o modelo.

Sites de clientes: um processo que a equipe repete

Nos sites de clientes, o problema era outro: entregar sites para pequenas empresas sem cada um virar um projeto artesanal. Escrevi uma skill do Claude Code que vai do Instagram e do Google Meu Negócio do cliente até o deploy, em fases com aprovação humana ao fim de cada uma. Contraste WCAG e JSON-LD são checados por script. A equipe da DockPlus usa o mesmo processo.

Como saber se esse papel combina com você

Se você gosta de sair do ticket e conversar com quem usa o sistema, se não se incomoda de mexer no backend, na integração e no deploy na mesma semana, e se quer ver o resultado rodando com dados reais, o papel de forward deployed engineer faz sentido. Se prefere um escopo bem definido e profundidade num único componente, o caminho de engenharia de produto clássica provavelmente agrada mais.

Mais sobre a minha trajetória está na página sobre.

Quer conversar sobre um projeto ou uma vaga? fale comigo