Freelance or own company
Full time on a funded client engagement, paid from day one as a contractor on the client contract, which explicitly provides for an engineer with a named identity in the client's tenant.
Open role
Principal Forward-Deployed Engineer
Contractor, full time, on a client engagement. Paris, on site with the client as the work demands. Start as soon as possible.
Paris, and inside the client
On site with the client as the work demands. English is the working language; French a plus.
Own the build
Antoine sells and holds the client; you own the build. If it works between us, there is a path to a stake in the firm — that conversation happens once we have shipped together, not in an advert.
The firm
Fieldreason builds the reasoning layer over systems of record for multi-site operators: companies running dozens or hundreds of plants, sites, vessels or clinics far from head office. The ERP knows what was ordered. Nobody's system knows what should be ordered, what will expire first, what can legally cross which border, or which alternative is acceptable when the exact item is gone.
Everyone can call the same models now, so nothing is won at the model layer. The work, and the difference, is in evaluation, orchestration and the interface an operations team actually uses. We put that in software, ship it live inside the client's environment in weeks, and stay to run it.
Who this is for, and who it is not
This is an application-layer role. AI engineering grew out of ML engineering, but with foundation models the work moved from training to adapting and evaluating. You will not train a model, design a model architecture or run a cluster. The system architecture is yours: you decide what each step is made of, where a plain rule beats a model, and how the pieces hold together in production.
A full-stack or front-end background is an advantage here rather than a compromise — everyone calls the same models, so the difference is made at the application layer, and the interface is where an operations team decides whether to trust the thing. If your ambition is model development or research, this seat will frustrate you.
The job now
Make the first build real. A multi-site operator: a few hundred remote sites, several hundred references each, thousands of orders a year, most of them arriving without product codes. You own the production build: a catalogue resolver (exact item, then equivalent, then alternative), inventory and expiry truth per site, a deterministic resupply proposal over a configurable window, humans on exceptions only, a full audit trail. Language-model agents where reasoning is needed, plain code where it is not. Delivered inside the client's Microsoft tenant: Fabric and Foundry, Entra ID, infrastructure as code. Working prototypes exist; you take them to production.
Where the seat goes after that
The first build is one client. What outlives it is the layer around it: golden sets and regression that catch a model changing under us, cost and latency per job, drift and exception rates a client can read every month without taking our word for it. That layer is the firm's, not the client's — it is what we carry to the second build and the third, and it is the reason this seat is an engineer's and not a delivery contractor's. You would own it. It is not a platform project in a corner: it is assembled out of the evidence the first build has to produce anyway.
How we think about models
A foundation model is a probabilistic component, and we engineer around that rather than wish it away. We pin the generation settings and still assume non-determinism, because the serving stack underneath can change without us. Where an output crosses a system boundary — an order, a quantity, a code — the format is enforced by constrained decoding or a finetuned classifier, not requested politely in a prompt. Retrieved facts and generated text stay separated in the context window, so the agent never re-reads its own guess as an established fact.
What you will do
- Evaluation first. Build the harness before the agent: golden sets from real cases, regression on every model, prompt or provider change, drift monitoring in production, every exception traceable to its inputs. Public benchmarks decide nothing here.
- Orchestrate. The chain is not one call: intent classification, retrieval from the client's own records, resolution, scoring of the proposal, a human gate on exceptions. You decide what each step is made of.
- Build the surface. The first deliverable is an operator workbench used every morning by people who did not ask for AI. A reasoning layer nobody trusts enough to click is worth nothing.
- Deploy adversarially. Identity, data boundaries and least privilege inside the client tenant, prompt-injection and tool-abuse defences, an audit trail that survives an auditor.
- Keep backend, agents and front end separated by explicit API contracts, so the reasoning layer can be swapped without touching the interface.
- Turn messy deployment problems into reusable patterns for the next client, instead of defaulting to bespoke work.
What you bring
- You have shipped a product where a model was one component among databases, queues, contracts and a screen, and real users depended on the result.
- You work evaluation-first. Criteria defined before the build, golden sets from real cases, regression on every model, prompt or provider change.
- You have built the layer that watches the system, not only the system — evaluation harness, regression suite, cost and latency per call, drift and exception rates — ideally across more than one build, so you know what generalises and what has to be rewritten every time.
- You can build the surface. TypeScript and a modern front-end framework.
- You have delivered inside a client's cloud tenant, ideally Microsoft: Fabric and Foundry, Entra ID, infrastructure as code. The client's CIO probes this first.
- You are sound on state that must be right: inventory truth, expiry, country import rules. Relational where correctness matters, document stores where honest, graph for catalogue equivalence, vector indexes for what they are and are not.
- You can explain what temperature, top-p, top-k and the seed actually do, why fixing them still does not buy determinism, and what you did about it in a real system.
- You have enforced output formats where it mattered, and have an opinion on constrained decoding versus finetuning versus a validation pass.
- Senior enough to own the build end to end: you write the specification before the code and can argue calmly with a compliance officer.
- English. French a plus.
Process
- Thirty minutes with Antoine.
- A technical screen: a synthetic exercise, deploying a resolver into a client cloud tenant. We grade the reasoning, not the syntax.
- One reference who vouches for one thing shipped inside a client tenant.
- Terms and start.
Apply
Write to Antoine with one shipped system you are proud of and what broke in production.