Forward Deployed AI Engineer
Posted yesterday
The role in short
Embed with client teams to select, fine-tune, and deploy production-grade AI models and evaluation systems that solve specific business problems.
Lunon is an AI-native consulting firm in New York City, backed by General Catalyst. Most companies don't need another deck about AI. They need an engineer who can walk in, understand the operation, and ship. That's what we do: we embed engineers inside the business and stay until the software runs without us.
Our open-source research system ranks first on DeepResearch Bench.
The team is young and moves fast. Everyone here has a wide skill set, works with the newest tools as they land, and owns what they ship end to end. Nobody hands you a ticket.
You own the model side of an engagement: choose the right model, adapt it to the client's data, prove it works, and make it fast and cheap enough to run every day. You work beside a Forward Deployed Data Engineer who owns the data. First up: helping an ERP company make its product AI-native.
- Fully remote, US-based. Lunon is headquartered in New York City.
What you'll do
- Pick the right model for each job, from frontier APIs to open-weight models, and know when fine-tuning beats a better prompt.
- Fine-tune when it pays off: supervised fine-tuning, preference optimization, and parameter-efficient methods like LoRA.
- Build the evaluation harnesses and benchmarks that tell us whether a change made things better.
- Take models from training to serving, and tune inference cost, latency, and quality.
- Sit with the client's team, find where AI moves their numbers, and say no to work that won't pay back.
What you'll need
Experience matters here. We judge it by what you've shipped and kept running, not by a number of years.
- You've fine-tuned or post-trained a model and can explain what worked and what didn't.
- You've built evals that changed a decision.
- You've shipped LLM features that real users depend on.
- You've served a model in production and cared about its cost and latency.
- You use AI coding tools every day and judge the result by the system and its output, not the language.
Nice to have
Apply even if none of these are true.
- You've built on or integrated with an ERP, CRM, or accounting system.
- You've shipped extraction or search over messy business documents.
- You've done consulting, agency, or forward-deployed work and know how to be useful in someone else's building on day two.
How we hire
- A 30-minute conversation with the team about what you've shipped and what we're building.
- A technical deep-dive on one system you owned, from the business problem to production.
- A working session on a real client problem with the team.
- References, then an offer. We aim to finish in two weeks.
Beware of recruitment fraud. All official correspondence comes from a lunon.ai email address. We will never ask you to share bank account information, cash a check, or purchase equipment as part of the hiring process.
Prep for this interview
3 questions likely to come up at Lunon, each matched to a line in this posting.
- 1LLMs, RAG and agents
They wrote: “Fine-tune when it pays off: supervised fine-tuning, preference optimization, and parameter-efficient methods like LoRA.”
A customer wants a chatbot over their internal documents. How do you build it?
How to answer
Why they ask: RAG is the most common first project. They want the whole path, from messy files to answers people trust.
- Collect and clean the documents; handle permissions per user
- Split them into chunks, embed, and store with source links
- Retrieve, then answer with citations; say “I don't know” when retrieval is weak
- Build a test set of real questions with expected answers before launch
Tip: Spend more time on the data and on testing than on the model.
- 2Discovery and scoping
They wrote: “A technical deep-dive on one system you owned, from the business problem to production.”
A customer says “we want AI in our claims process.” What do you ask in the first meeting?
How to answer
Why they ask: Most FDE work starts this vague. They want to hear you find the real problem before you pick a tool.
- Map the current process: who touches a claim, in what order, with which systems
- Find the slowest or most error-prone step and ask what it costs them
- Agree on one measurable goal (for example time per claim, or error rate)
- Ask what data you can access, and who signs off on security
Tip: Ask about the work, not the technology. Who does it today, how long it takes, what a mistake costs, and how they'd know it got better.
- 3Integrations and APIs
They wrote: “Pick the right model for each job, from frontier APIs to open-weight models, and know when fine-tuning beats a better prompt.”
Walk me through connecting our product to a customer's internal system that has no documentation.
How to answer
Why they ask: This happens weekly in the job. They want a calm, step-by-step method.
- Find who owns the system and get read access to a test environment
- Watch real traffic or logs to learn the data shapes
- Build a thin adapter with logging around every call
- Agree on how failures get reported, and who fixes what
Tip: Talk about finding the owner of the system first. The code is the easy part.
Not the one? Get the next one by email
New roles land here every day. Pick what you want to hear about.
Want the job, not just the posting? Learn how FDEs work.
FDE Info is our free weekly newsletter for forward deployed engineers: tools, field notes from real deployments, and how FDE teams hire and pay.
Free. One email a week. Unsubscribe in one click.
