Article · Buying Decisions
Vendor FDE vs independent FDE: how to decide who you work with
A forward-deployed engineer from a model maker and an independent FDE can, on paper, do the same work: sit inside your operation, connect the system and take it to production. The title is identical; the mandate is not. The vendor’s FDE has a goal of deploying the stack their company sells. The independent one optimises your operation and preserves the ability to swap the model. The difference is not one of good faith but of incentives and architecture, and you pay it or bank it on the day you want to change model provider.
If you are not yet clear on what this role actually does, read what a forward-deployed engineer is first. Here I take the role as given and focus on a single question: who they work for.
The same title, two mandates
A model maker who puts engineers in the field does so, among other reasons, to get its technology into production and keep it there. That is legitimate and often useful: nobody knows a model’s capabilities and limits better than whoever built it. But that engineer’s success includes adoption of their ecosystem. When a design decision comes up with two equally valid paths, the one that runs through their own primitives gets a nudge that comes not from the operation but from the mandate.
An independent FDE does not sell a model. Their success is measured by your process working at the agreed quality, cost and risk, and by your still being able to change model tomorrow. They treat models as replaceable components and choose them per task on the basis of evaluations. That is the position I hold at Arkatai, and the reason I stay agnostic about the model provider.
The difference, dimension by dimension
These are the five dimensions where the mandate changes the result, even though the title is the same.
| Dimension | Vendor FDE | Independent FDE |
|---|---|---|
| Mandate | Get the vendor’s stack into production | Make the operation work at agreed levels |
| What it deploys | Its model and primitives as the base | The platform; the model is interchangeable |
| What it optimises | Adoption and fit into its ecosystem | Quality, cost, latency and process risk |
| Model choice | Its own model by default | Per task, based on evaluations |
| When the model changes | High friction: logic lives in its primitives | Re-evaluate, not rebuild the process |
The table does not say one path is right and the other wrong. It says you should read the mandate before signing, because it determines what stays inside your operation when the engineer leaves.
Why it is an architecture problem, not bad faith
The point boards most often misread is simple. You do not need to assume bad intent from the vendor for the risk to be real. The risk is architectural. If, during the deployment, your rules, controls, traces and integrations end up encoded inside one lab’s specific primitives, changing model stops being a contained technical decision and becomes a rewrite of the process. Nobody deceived you. The system was simply built tied to a provider, and now the cost of leaving is high.
The architecture that protects your freedom does the opposite: it keeps the process, its rules, its controls and its trace outside the model, so the model is a connected component and not the foundation. With that separation, changing provider means re-evaluating quality, cost and latency, but not redoing the operation. It is the same logic of treating models as a utility that I explain in service as software: you buy a result, not a commitment to a specific lab.
What happens the day the model changes
Models change on their own. New versions ship, prices drop, a better one appears for your specific task, or your data policy forces you to move part of the work to another provider. That is the day the difference between the two mandates shows.
With an operation built on the vendor’s primitives, migration is a project: you have to find where the logic that assumed that model lived and rebuild it. With an operation where the model is separated from the process, migration is a re-evaluation: you run your test cases again with the candidate model, compare quality and cost, and decide. The ability to make that comparison per task is exactly what I cover in choosing the LLM for each task. Without it, the model choice is effectively made by whoever deployed your system.
When each one fits
The vendor FDE can be the right choice if your company has already decided to marry an ecosystem and does not expect to leave it: in that case, having the person who knows the model best speeds up the deployment and reduces surprises. What you should not do is make that decision without seeing it: choosing the vendor’s FDE is choosing their model, and it is worth measuring the cost of changing later in advance.
The independent FDE fits when you want to keep the model substitutable, when the process is specific enough that technical neutrality matters, or when you do not want the AI provider choice fixed by whoever installed the system. This question is part of a wider decision about who to work with, which I develop in in-house team, consultancy or forward-deployed engineers, and of the underlying decision to buy, build or contract, in buy vs build enterprise AI. The concrete criteria for comparing offers are in how to choose an AI agent provider, and the full map of the terrain, in AI agents for business.
Frequently Asked Questions
What is the difference between a vendor FDE and an independent one?
The mandate. The vendor FDE aims to take into production the model and primitives their company sells, and their success includes adoption of that ecosystem. The independent FDE optimises your operation and treats the model as a replaceable component chosen per task on the basis of evaluations.
Are you implying vendor FDEs act in bad faith?
No. The issue is incentives and architecture, not good faith. A good vendor FDE can do excellent work. What changes is where their mandate pushes and what exit cost your system carries if the logic ends up tied to one specific provider.
Why does being able to change model matter?
Because models change in price, quality and availability constantly, and your data policy may force you to move work. If the process is separated from the model, changing is a re-evaluation. If it is tied to a lab’s primitives, changing means rebuilding the operation.
When would I choose the vendor FDE?
When the company has already decided to commit to a specific ecosystem and does not expect to leave it. In that case, whoever knows the model best speeds up the deployment. The decision should be made with eyes open: choosing that FDE is, in practice, choosing their model.