# 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. 2026-10-15 · Gustavo Karsten 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](https://www.getonbrd.com/jobs/ai-operations-lead-puente-talent-partners-remote/next), da [Assistant Launch](https://torre.ai/post/8W3BXZ6r-assistant-launch-forward-deployed-engineer), da [Artefact](https://www.getonbrd.com/empleos-OpenAI) e da [South](https://hireinsouth.com/roles/forward-deployed-engineer) 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](https://gustavokarsten.com/projects/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](https://gustavokarsten.com/projects/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](https://gustavokarsten.com/projects/sites-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](https://gustavokarsten.com/about). Quer conversar sobre um projeto ou uma vaga? [fale comigo](https://gustavokarsten.com/contact) --- Página: https://gustavokarsten.com/articles/forward-deployed-engineer Contato: gustavo.karsten@outlook.com · https://www.linkedin.com/in/gustavo-karsten-88a04383/ · https://github.com/gustavo-karsten