Principal Forward-Deployed Engineer
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. Our first client runs 260 sites.
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, because everyone calls the same models 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, 260 remote sites, 500 to 650 references each, thousands of orders a year, half the sites sending no 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, built by the founder; 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.
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: valid JSON is not correct JSON, and a truncated generation is neither. 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; a model that wins on MMLU under one prompting technique loses under another. Orchestrate. The chain is not one call: intent classification, retrieval from the client's own records, resolution, scoring of the proposal, human gate on exceptions. You decide what each step is made of and where a plain rule beats a model. Build the surface. The first deliverable is an operator workbench used every morning by people who did not ask for AI. You own it end to end, or you work with a front-end engineer and hold the standard. 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. Make disciplined standardization-versus-customization decisions instead of defaulting to bespoke work; turn messy deployment problems into reusable patterns for the next client.
The deal: funded engagement on a client contract. Contractor day rate at market for the seat, discussed at step 1. 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. The founder sells and holds the client; you own the build. If it works between us, there is a path to a stake in the firm, and that conversation happens once we have shipped together, not in an advert.