Forward deployed engineer vs consultant

The title is new. The split is not.

Palantir named the role. Labs and hyperscalers are hiring for it in volume. Consultancies are reprinting the same word onto existing delivery slides. None of that tells you what you are buying. The useful distinction is older than the acronym: who is still responsible after the recommendation has been accepted.

A consultant advises and leaves. A forward deployed engineer builds and stays long enough for the thing to write into production, fail in a way you can see, and be operable by someone else. I use “stay” carefully. The job is finished when it runs without me — not when I become furniture.

What each engagement is for

You want a consultant when the question is still “should we.” Architecture options, a risk register, a build plan you could hand to anyone, an honest no. I sell that as a one-to-two-week diagnostic, and sometimes the answer is that you do not need a model at all.

You want a forward deployed engineer when the question has become “make this survive Monday.” The prototype works on a laptop. The steering group liked the demo. Nothing writes to the CRM. Nobody knows what happens when the write fails halfway. There is no approval path a manager will sign, and there is no one on the team who can operate it.

That second state is where nearly every stalled AI pilot is stuck. It is also where the title earns its keep. The work is integration, permissions, data quality, idempotency, and accountability. The model is a small part of it. Several of the systems on this site delivered most of their value from fixing plumbing that was quietly broken before any model was involved.

Four differences you can inspect

Where it ends. Consulting ends at a recommendation. This ends when the system is writing into your production database, a human has approved its output, and someone on your team can operate it without the person who built it.

What they will touch. A consultant can work from a sample export and a workshop. A forward deployed engineer needs the actual table, with the actual nulls, and the workflow where a failure is visible. If they will not ask for production access in week one, they are not doing this job.

Where the rules live. A consultant can write “the agent must not send outbound messages” in a slide. An FDE puts that in a callback that refuses the save unless the preflight ran. Prompt-level rules degrade quietly. Code either ran or it did not.

Who is on the hook at 7am. If an API the system depends on returns a 500 on a Sunday morning, a recommendation does not page anyone. A deployed system should. If there is no page, no kill switch, and no log that distinguishes skip from success, you were sold advice in an engineering costume.

What “embedded” actually requires

Forward deployed means the engineer sits inside someone else’s business — their stack, their constraints, their Monday. I run two companies of my own, Emerge Digital and Aquora. The systems that belong there are useful as a proving ground. They are not the job.

Three of the eight systems on this site run inside businesses I do not own. They are described by what they do rather than by brand name, because those businesses are not mine and the owners have not agreed to be named. That ownership boundary is the product story, not a gap in the portfolio. If every case study is the builder’s own company, you are looking at a founder, which is a different role.

Embedded also means the unfashionable half: a completion marker that a vendor UI can strip, so idempotency has to live in a separate state database; an intake path silently locked to one phone extension, found by reading the data rather than the code; a crawler path returning zero products and burning a metered search API. None of that is in the job description people share. All of it is the job.

When the consultant is the right hire

Not every stalled programme needs an FDE. If leadership has not picked a workflow, if nobody will grant read access to the system of record, if the organisation wants a strategy document to socialise internally — hire someone who writes that document well and stop there. Putting an engineer into that meeting wastes the engineer and does not fix the decision.

The diagnostic sprint exists for this. I get access to the real system, find where the value and the risk actually sit, and come back with an architecture and an honest assessment. If the honest assessment is “do not build this,” that is the engagement. It is cheaper than a twelve-week embed that should never have started.

How to use this in a hiring loop

If you are staffing a lab FDE programme, you already have a loop — decomposition, a customer conversation, a production-shaped build. Add one artefact: a system they shipped that a stranger can operate, with a gate in code and a number that is operational rather than theatrical.

If you are a company whose demo never became software, skip the whiteboard. Give thirty minutes of access to the real workflow and see whether they start at the data. That is the whole interview.

The longer rubric — six things that have to be true of the system, and the questions I would want asked of me — is in how to evaluate a forward deployed engineer.