Forward Deployed Engineer vs Consultant: The FDE Model Explained

Forward deployed engineer vs consultant: the difference is who stays. A forward deployed engineer (FDE) works inside your business, next to the people who do the work, and builds the AI system around how your company runs. A consultant interviews your team, then recommends, and sometimes builds, from that snapshot. The FDE model keeps one person accountable from the first interview to the system running in production, and through every change after.

Most FDEs today work for software companies and deploy their own platform at their customers. QAI uses the same model as a new way to do consulting: the FDE starts from your process, not from a product to install.

The title comes from software companies that send engineers to work on site with their customers instead of building from headquarters. We use it for a specific kind of person: a systems engineer more than a software engineer. Their job is to bend the technology to fit the business, not the other way around.

If you have worked at a high-complexity tech company, you may know a version of this role as the integration engineer or integration specialist: the person who carries one project across every team until it works.

Day to day, the FDE is the business quarterback. They sit with the people who know the work, including the accountant with fifteen years at the firm who knows things written down nowhere, and turn that knowledge into a process map and into the agents that run on it.

At QAI, every FDE works with a data or solutions architect, depending on the mandate, because a quarterback still needs someone watching the whole field. When your field needs it, an on-call domain expert joins them. Each role answers a different question:

• The FDE: what does your team need? They work inside your team, learn the process, and build and adjust the agents.
• The architect: will it hold? They make sure the pieces fit together: security, data, integration with your existing systems, and decisions that would be expensive to reverse later. Keeping that role is the one part of the traditional model we preserve on purpose.
• The domain expert: is it right for your field? They know the rules of your industry that an FDE cannot learn in a few weeks: regulations, standards, and how the work is judged. They check the process map and what the agents produce against those rules. For an accounting firm, that is an accountant who checks that an agent applies the tax rules correctly.

The FDE is your team's single contact. When a question needs the architect or the domain expert, the FDE brings them in.

The role started at Palantir about twenty years ago. Its software did not fit large customers out of the box, so the company sent engineers, called "Deltas" internally, to build solutions inside each customer's environment (The New Stack). Until 2016, Palantir had more of these engineers than regular software engineers (The Pragmatic Engineer).

AI companies picked up the model when they started selling to large enterprises and ran into the same problem: a powerful model is not a working system. OpenAI set up its FDE team in 2024, and Anthropic hires for the role too. In May 2026, OpenAI launched a separate company built around FDEs, starting with about 150 of them through its acquisition of an applied AI consulting firm (OpenAI). At the end of July 2026, The Bench counted 170 open "Forward Deployed" roles across 98 companies. New postings went from one in January to 62 in July (Mind the Product).

The short answer: a consultant interviews your team once, then recommends and sometimes builds from that snapshot of how the work ran. An FDE builds with your team, and the system changes as the work does.

The handoffs are the real cost of the traditional chain. Between the engagement manager and the developers there are four or more of them, and each one adds waiting time and loses context.

The business analysts who understood your process are usually moved to another project once the requirements are signed, so the knowledge leaves with them.

An FDE removes most of those handoffs, because the person who learned the process is the person who builds and adjusts the system.

It also removes most of the contract work. In a traditional mandate, a good idea found midway is a scope change: a change request, a new estimate, sometimes a new contract, and a debate about scope creep. An embedded FDE is engaged for an outcome and a rhythm, not a fixed list of deliverables. When a quick win shows up in another department, you redirect the FDE to it, without new paperwork.

The way of working is the same: embed with the team, learn the process, build, adjust. What changes is who the engineer works for and where they start.

A vendor's FDE is there to make the vendor's platform work at your company. That is the right help once you have picked the platform. Their field work also feeds the vendor's product: OpenAI describes its FDE cycle as build, prove, generalize, where patterns found at customers become product features (OpenAI).

A consulting FDE starts from your process and picks the tools after. At QAI, the FDE maps how the work runs today. Then, for each step, they decide whether to build, buy, or connect a tool you already pay for, or to leave that step without AI. A useful rule: buy what works the same at every company, and build what sets yours apart (UX Collective).

Two questions sort out any FDE offer: who does the engineer work for, and what do you keep when they leave?

1. Captures undocumented knowledge. Interviews and job shadowing with the people who do the work, written into a process map.
2. Turns requests into what you actually need. A request is a starting point. The FDE checks it against how the work really runs, says early when it will not work as asked, and finds another way to get you the result.
3. Knows who to ask. No one person knows your accounting, your systems and the tools at the same time, and a good FDE does not pretend to. They find the person who knows, in your team or ours, and bring them in before the question blocks the work.
4. Keeps the process map alive. The map is updated as the work changes. It is a working tool, not a PDF delivered once.
5. Builds and adjusts the agents. Each agent does one narrow task, with the smallest access it needs, and gets more room only as its results earn it.
6. Works across departments. Finance, HR, marketing and sales often share the same bottlenecks. One FDE can rotate, for example one day a week per department.
7. Handles adoption from the start. The people whose work changes are part of the design, not told about it at the end.

Our FDEs build the same kind of agents we run on QAI's own books. Our bookkeeping agent, for example, attaches the receipt to each transaction and checks the sales tax split. We explain how it is built in Skills vs agents.

It fits mandates defined by an outcome over a long horizon: launch a new service, reduce the cost of a process, shorten a cycle, absorb growth without hiring at the same pace, over a year or two. Those goals need someone who learns the business and adjusts as results come in.

It fits less well when the scope is fixed and known in advance, like a standard integration between two systems with a clear specification. A fixed-scope, fixed-price project is usually the better buy there.

1. "We need a senior expert in our field, and that profile is rare." It is rare, and the model does not count on finding it in one person. The FDE carries the work, the architect covers the foundations, and the domain expert covers your field, as described above.
2. "Isn't this staff augmentation?" In part, yes: the FDE works inside your team, at your pace. The difference is what they answer for. You set a result together, the same person carries it from the first workshop to production, and your team learns to run it after.
3. "Our people don't have time." The pace adapts to yours. Many teams start with one fixed day, for example every Wednesday.
4. "We'll be locked in." You own the living process map and the skills that describe what each agent does. Another team could pick them up.

1. On-demand expertise: a set number of hours with an FDE and an architect, to review a process, check an agent design, or unblock your own team.
2. Managed sprints: a scoped outcome over a few weeks, for example one process mapped and one agent running in production.
3. Side-by-side capacity: an FDE embedded with your team on a fixed rhythm, like one day a week per department, over a long horizon. This is the full model described in this post.

Every option includes an architect. Two additions are available: an on-call domain expert and a forward deployed product manager who sets the priorities for work that spans several departments. When the work is done, we train your team to take it over, and maintenance stays available. Providers retire model versions on a schedule, and a newer model can answer the same request differently, so maintenance includes a set of 20 to 30 real tasks with known good results, run again before your agents switch to a new model.

Most engagements start with the free workflow assessment: one or two of your workflows, in four steps. Three workshops of about an hour and a half with the people who do the work, then a readout. We usually hold one a week, because getting everyone in the same room takes some coordination. A team in a hurry can hold two a week and finish in about two weeks.

1. The pain points: the whole team of one domain, finance for example, says what works and what doesn't, then votes on the biggest pain points.
2. Every task, measured: only the people who run the chosen workflows. Each step is broken down to the task, with volumes and time per task.
3. Rethink the work: the same people, one question: with a magic wand or a hundred interns, how would you split this work?
4. The readout: a map of the tasks and a ranked list of where to start, by hours saved and by effort.

The readout also names the next step. When the first win is one workflow with a clear finish line, that is a managed sprint. When your goal spans several workflows, or reaching it will take several tries, that is side-by-side capacity with an FDE. When nothing on the list is ready, the readout says so, and why.

See where the assessment fits in an AI rollout on our AI adoption page.