What a forward-deployed engineer actually does.
It is the job title on our careers page, and it is used loosely enough elsewhere that it has stopped meaning much. Here is the version we hire against.
The short definition: an engineer who writes production code inside someone else’s organisation, on their infrastructure, against their real data, and whose job is finished when that organisation no longer needs them. Everything below follows from those four clauses, and most of what makes the role hard is in the last one.
You read the work before you write the code
The first week is not a sprint. It is sitting with the people doing the task, reading the systems it touches, and counting what it costs today — in hours, in errors, in the thing everyone works around and has stopped mentioning. Most of what you learn contradicts the brief. That is not a sign the brief was written badly; it is what happens when a problem is described by someone one level away from it.
The output of that week is a written scope with an estimate, and sometimes a recommendation not to build anything. If a query and a rule solve it, you say so, and you help them write the rule. An engineer who cannot say that sentence is a salesperson with a compiler.
You decide what the model is not allowed to decide
This is the technical core of the job and it is mostly a drawing exercise. On one side: the judgment calls, the ambiguity, the language. On the other: anything with a correct answer — the arithmetic, the eligibility rule, the selection, the safety check. Deterministic code does the second half, always, and the model never gets a vote on it.
Drawing that line badly is how AI projects fail in ways nobody notices for a quarter. Drawing it well is why nearby costs $105 to diagnose a business instead of $420, and why a safety-critical system can be built on models at all: a prompt is a request, a filter is a guarantee, and the guarantee is written in code you can read.
The practical version of this skill is unglamorous. You will spend more time on the interface a model sits behind, the evaluation set that tells you when it drifted, and the fallback when it is unavailable, than on the prompt itself.
You build narrow, in their cloud, from week one
One workflow, real data, inside their VPC, with the failure cases handled rather than hidden. Working software lands every week, starting with the first, because a demo built on synthetic data teaches you nothing about the thing you are actually going to hit — which is usually the data, and specifically the seven years of it that nobody has looked at since a migration.
Working inside someone else’s infrastructure means their review process, their security questionnaire, their on-call rota, and their naming conventions. A forward-deployed engineer who fights all four is a net negative in the building regardless of how good the code is. You are a guest with commit access.
You run agent crews, and you answer for what they do
The volume of the work — the generation, the sweeps, the test suites, the migrations — runs through agent crews. That is what makes a small firm able to take on a build of this size, and it is the part of the job that has changed most in two years. It does not change who is accountable. Every charter has one human answering for it, and “the agent wrote it” is not a defect report, it is an admission that nobody read it.
In practice this means writing loops rather than prompts: a goal loop that runs until a checkable condition is true, and a verification loop that forces the work to be tested before it may be called done. We keep that kit in the lab and every pod inherits it.
You finish by making yourself unnecessary
Handover is a deliverable with a date on it: source, architecture documentation, a runbook, and sessions with the team who will own the system. The test is not that it runs in production. The test is that their engineers can change it without calling you, and if they cannot, the work is not done no matter what the schedule says.
This is the clause that filters people. The incentive in most consulting arrangements runs the other way — toward being needed next quarter — and an engineer who has internalised that incentive will leave a system slightly harder to modify than it had to be, without ever intending to. The role only works if you find the handover satisfying. Some people do. They are the ones worth hiring.
What we look for
Someone who has shipped something they had to keep running afterwards. Someone comfortable being the least knowledgeable person in a room about the client’s domain, and asking the question anyway. Someone who writes the failure case down before the happy path. The model expertise is teachable in weeks; the temperament is not.
We staff per-project pods rather than a bench of generalists, and the pod dissolves when the project does. If that sounds like the job, the open pods are listed here.