AI forward deployed engineer: which of the four vendors are you actually hiring?

The buyer's question, in one file list

Most articles on this topic frame the question as a job description: what does an AI FDE do all day, what salary range, what tech stack. That framing is fine for engineers reading career guides. It is not the buyer's question. The buyer's question is structural: when the engagement ends, which of four files are in my repository, and which are in the vendor's? Print the list, ask the question, and the four vendor types separate themselves before any contract is signed.

The four vendor types, side by side

Same title, four very different contracts. The dimensions that matter to a buyer are: who pays the engineer, what runs the eval at week six, where the agent code lives, what it costs to swap models after handoff, how long the engagement runs, who is actually on the call in week one, and whether there is a refund clause if the work misses the prototype rubric. The vendor-neutral studio is the column we run; the right-hand column collapses the other three for legibility.

The right-hand column is honest about the tradeoffs. A model-lab AI FDE is often the right hire when the team has standardized on one vendor's API and wants white-glove support tightening prompts and agents on that surface. A big-firm consulting AI FDE is often the right hire for a multi-team rollout where the bottleneck is partner-level governance, not engineering velocity. A platform AI FDE is the right hire when the platform is already part of the stack and the agent must run inside it. A vendor-neutral studio is the right hire when the buyer wants the eval harness and the agent code in their own repo, with the model layer swappable, and a fixed-fee engagement that ends.

The four files (and why this is the only test that matters)

Every other test (technical interview, reference check, sample architecture diagram) is gameable in week one and unverifiable in week eighteen. The file-list test is verifiable on day one (ask the candidate to show you redacted versions from a prior engagement) and verifiable on the last day of the engagement (the files either landed on main or they did not). The four files on a vendor-neutral studio engagement, in the order they land:

The first of those files, rubric.yaml, carries the engagement. It defines the bar the model has to clear to ship, the per-axis floors that catch failure shapes the average would hide, and the week-by-week ratchet that walks the bar from prototype-grade in week 2 to production-grade in week 6. A working excerpt from a real engagement, lightly redacted:

A model-lab AI FDE will run substantially the same logic, but the eval surface is hosted on the lab's side, the rubric weights live in a vendor dashboard, and on the day you decide to swap models the eval surface goes with the SDK. A consulting AI FDE will run a manual review by a senior partner, which is credible the day it happens and unreproducible in month four. A platform AI FDE will hand you a dashboard you cannot export. The four-file test is the only version where the artifact survives the engagement intact, in your repo, on your CI, against your test set.

When each vendor type is actually the right hire

A buyer-side decision framework only earns trust if it admits the cases where the column you are pitching is not the right column. Four honest cases:

Why the role exploded in 2024 and 2025

Foundation models commoditized faster than the application layer that uses them. By 2024, the choice between Claude, GPT, Gemini, and an open-weight model on Bedrock or Vertex was a swap, not a strategy. The model labs realized the application layer was the moat, and the cheapest way to win it was an engineer inside the customer's repo for a few weeks. The customers responded by asking for the same shape without the vendor binding. The vendor-neutral studio split off in 2025. The big consulting firms then standardized their own version under the same title, and the platform vendors followed.

The growth number is interesting. The harder fact is that the title fragmented while the listings exploded. A buyer who reads the title alone cannot tell which of the four contracts they are about to sign. The file-list test is the way to read past the title.

What the buyer should do on the first call

A short script that works against any of the four vendor types. The point is not to pitch the studio answer; the point is to surface which column you are actually buying so the rest of the conversation is honest:

1. Open with the file-list question. "When the engineer leaves at week six, which of these four files are in our repo and which are in yours? rubric.yaml, eval/cases.yaml, .github/workflows/pilot-gate.yml, runbook.md."
2. Ask for redacted versions of those four files from a prior engagement, on the call. A vendor-neutral studio will share them. A model-lab FDE will share a vendor-hosted eval surface and a sub-agent skill bundle. A consulting team will share a slide deck. A platform vendor will share a dashboard screenshot. The artifact you see is the one you will get.
3. Ask what happens if the week 2 prototype rubric does not land. The vendor-neutral answer is a prorated refund and the code stays with you. The other three usually have no exit gate; the engagement continues at the agreed rate or the agreed license.
4. Ask which engineer will be on the call in week one. If the answer is a Solutions Architect, an account executive, or a partner with an analyst, then the named senior engineer who writes the code is not the person you are buying.
5. Ask what swapping models costs after handoff. The vendor-neutral answer is one config line and a re-run of rubric.yaml on the same eval set. The model-lab answer is a re-architecture off the SDK. The platform answer is usually a contract amendment.

Ten minutes of those five questions will tell you which of the four columns you are sitting in. The rest of the engagement is mostly mechanical from there.