State of the Market
So apparently AI is being used everywhere, from startups to enterprises. Making our jobs easier, making us work faster, better. Lots of people talk about how they are using it in their day to day, how much AI have helped them. People even talk about, not if, but when, AI will take our jobs.
Nevertheless, when you see the actual adoption, you say "Hmm, not quite". MIT's 2025 GenAI Divide report says only about 5% of task-specific GenAI tools are successfully implemented with marked and sustained productivity or P&L impact, and attributes the gap largely to poor workflow integration and brittle custom tools. Source.
Now over to the job market. In 2025, FDEs (forward deployed engineers) were one of the most demanded professionals. In 2026, they are still well above software engineers. And still growing in demand. Frontier AI labs like OpenAI, Anthropic and even Google are hiring FDEs at a great pace. OpenAI launched the OpenAI Deployment Company. Some say they are speeding up the interview process even. The goal is to, well, deploy their models and integrate them into existing companies' systems.
A Forward Deployed Engineer
But what exactly is a forward deployed engineer? An engineer who integrates AI (e.x agents, chatbots) into existing, working systems. You could think something like an integrations engineer. A little plumbing over here and over there. Connect APIs, libraries, SDKs. Build a pipeline where AI is used on some step. However, the job is not only technical. A FDE has to sit down with clients, talk to them, see what's missing, what's broken, fix bugs, present solutions to stakeholders. The job has a little of sales stuff.
Sometimes the job can become repetitive, same integrations, same agents, same workflows. Same boilerplate code, same API plumbing. Define policies, run evals, deploy agents with a certain harness. Gather traces, build dashboards. Find a way to somehow document all of it, present to the client. This often requires bespoke glue code, ad hoc evals, custom logs, fragile tool permissions, and one-off reports.
Why FDEKit
I'm building FDEKit, a field-deployment operating layer for AI companiesā€™ forward deployed engineers: scaffold integrations, connect enterprise systems, enforce governance, run evals, observe behavior, and package reusable customer patterns into deployable modules. The goal here is deployment reliability: production deployment is messy: customer APIs, legacy systems, auth, permission boundaries, data privacy, evals, latency, observability, hallucination control, rollback plans, procurement, and ROI proof.
The idea is to connect an AI agent to a companyā€™s internal knowledge base, ticketing system, GitHub repo, Slack, and database, with evals, audit logs, approval gates, and deployment reports. And make it easy, trivial, repeatable. FDEKit aims to work for out of the box for common deployment patterns, and give FDEs typed primitives to adapt to messy systems quickly. Also to reduce risk with policy gates, audit trails, typed permissions, evals, redaction, and approval workflows. It does not magically make agents safe.
FDEs can define agents, tools, evals, policies, environments and deployments and turn repeated customer deployment patterns into reusable, governed AI recipes for production agents.