Engineering inside your operation, not a report about it.
The engineer sits with the people who run the operation, writes code in your environment and answers for what stays in production. It is the model Palantir created in the early 2010s, and the one OpenAI and Anthropic adopted to get AI inside companies that are already running.
Before the job title: what the person actually does.
Drop the label and a plain description is left. It is a software engineer who works from inside your company, in your system, with your real data, next to the people who do the work every day. They do not write a document about your operation: they write the code your operation is going to use.
Three things define the format. Remove any one of them and the model turns into something else.
They stay where the work happens
Not a status meeting. Watching the people who run the operation, at the hours it actually runs, and seeing the step nobody writes down because to them it is obvious.
They write code in your environment
Your repository, your cloud, your real data — not a proof of concept on an anonymized set that somebody has to rewrite later to make it count.
They answer for the result
The test is not "the scope was delivered". It is that the operation got better and keeps working after the engineer leaves the room.
The model is not new. It became urgent now.
It started at a company selling software to governments and heavy industry, where handing over the license and walking away never worked. When AI started depending on each client's own data and process, the same problem came back — and the frontier labs copied the solution.
Where the role was created
The engineer worked inside the client rather than at head office. Until around 2016, the company had more people in that format than it had product engineers.
Source: The Pragmatic EngineerWho copied it first
The team started in early 2025 with two engineers and passed ten, spread across eight cities, to take frontier models into production inside the client.
Source: The Pragmatic EngineerWhat the job description asks for
Build production applications inside the client's system, travel 25% to 50% of the time to work on site, and feed the repeating pattern back to the product team.
Source: the job descriptiona16z called it the most contested role in the industry and opened a program of its own: 65 people in the first cohort, chosen out of thousands of applications. Source: a16z
What breaks when the engineer stays outside.
The pilot works and never becomes production
What runs in the presentation has no integration, no owner to operate it, and no answer ready for the moment it gets something wrong.
We wrote about that →The rule that settles the hard case is not written down
It lives with the person who has been doing this for years. And they only say it out loud when somebody is beside them, watching the same screen, at the moment the hard case turns up.
The integration shows up on cutover day
The field that is empty on part of the records, the system that only accepts a load overnight, the report somebody has been fixing by hand forever. A round of meetings finds none of it.
Nobody owns it once it is live
Delivery signed off, team disbanded, and the first error in production has nobody to call. That is where the project turns into a loss — not during the build.
How it works at Moonxi, week by week.
It is not a sixth front. It is the format Moonxi delivers the build, software development and dedicated squad fronts in. The quote is still fixed front by front, in the diagnostic.
Conversations with the people who run the operation. Read-only access to the systems and the database. A map of the data: where it is, what state it is in, who uses it. What you have already tried and where it stopped.
Where AI goes first, which architecture, what it costs to run per month, what needs a human approval. A fixed quote front by front, with a date. Not one line of code.
The rhythm becomes weekly: one review with the people who run it, one working piece in your environment, and the list of what changed. Your team reviews every step while the build happens.
Someone on your team learns to operate it, review it and correct it while it is being built, not afterwards. Whatever goes live goes live with documentation and an operating manual.
What does not change: the rules in how we work apply here exactly the same. Every number carries its source, somebody approves before an action goes out, and sensitive data does not leave your environment.
Who it is for.
The decision you want to automate sits inside an operation that already runs, with people, systems and volume.
Getting it wrong costs money, time or regulatory risk — and somebody has to answer when it does.
There is a person on your side willing to operate it, review it and correct it. They do not need to know how to code.
Who it is not for.
What you need is a recommendation to take to the board. In that case the answer is the discovery and architecture front.
What is missing is hours of labour with no target attached. That is staff augmentation, and Moonxi does not do it.
No system of yours can be touched by anyone outside. With no agreed access to the real environment, this model does not exist.
What changes compared with a consultancy or an hourly contract.
All three formats exist because they solve different problems. The difference that matters is always the same one: where the person works, what is left when they leave, and who answers when it breaks at three on a Wednesday afternoon.
Consultancy
Right when the bottleneck is the decision, not the system.
Hourly contract
Right when you already have the architecture, the target and a reviewer.
Forward Deployed Engineer
Right when the system has to work every day and somebody has to have a name when it does not.
Questions about this model.
Is Forward Deployed Engineer a sixth Moonxi front?
No. It is the format Moonxi delivers the build, software development and dedicated squad fronts in. The quote is still fixed front by front, in the diagnostic.
Does the engineer sit in our office?
Part of the time, when the operation is on site. The rest is inside your digital environment: your repository, your cloud, your team rituals. The arrangement is settled in the diagnostic, before anything starts.
Do you need access to our systems?
Yes, and the level of access is agreed beforehand. During the diagnostic the access is read-only. Where the data is sensitive, the standard architecture keeps identified data inside your environment.
Is this staff augmentation under another name?
No. Staff augmentation is hours sold with no target attached. Here there is a fixed scope, a deadline, and someone who answers for what is in production.
What if we want to carry on without you later?
You can. Whatever goes live goes live with documentation and an operating manual, and someone on your team learns to operate, review and correct it during the build, not after it.
What does it cost?
The quote is fixed at the end of the diagnostic, front by front. There is no price list because no two projects are the same.