AI at work
What a forward-deployed engineer does
A forward-deployed engineer is a software engineer who works inside a customer’s business, next to the people who do the work, and builds what they need there. They stay until the software is in daily use. A smaller company can benefit from one when it has a few months of real work to change, spread across several people and systems, and someone inside who will own the result.
The title comes from large software companies, so it can sound like something only they need. This article explains where the role comes from, what the work looks like, how it compares with other ways of getting help, and when it makes sense for a smaller company.
Where the role comes from
Palantir used the title early and explained it publicly in a 2019 post about its engineering roles. The post describes two groups. Its software engineers build its platforms. Its forward-deployed software engineers deploy those platforms for one customer at a time. Internally the second group was called “Deltas”, and it was one of the company’s two biggest engineering roles by headcount.
The post sums up the difference in one line. A software engineer’s focus is “one capability, many customers,” while a forward-deployed engineer’s is “one customer, many capabilities.” It also takes on the obvious question of whether this is just consulting. One of the engineers says that consultants “generally create a one-time analysis, recommendation, or solution to a specific problem,” while they work with the customer “to build a long-term solution.”
One of Palantir’s current postings, for US Government work in New York, describes the starting point well. Projects “often start with a nebulous question like ‘Why are we losing customers?’” The engineer then takes it all the way: system design, prototypes, application development, and connecting the data.
Sources: Palantir, Dev versus Delta, April 2019; Palantir, Forward Deployed Software Engineer job posting.
How OpenAI and Anthropic describe it
OpenAI and Anthropic now hire for the same role. Their job postings, as of October 2026, describe it in very similar terms.
OpenAI says its forward-deployed engineers “own discovery, technical scoping, system design, build, and production rollout,” working directly with the customer’s engineering and domain teams. OpenAI’s posting also says: “You will measure success through production adoption, measurable workflow impact, and eval-driven feedback that changes product and model roadmaps.”
Anthropic’s posting for Munich asks its engineers to “work within customer systems to build production applications with Claude models.” They deliver building blocks for agents, such as MCP servers, sub-agents, and skills, “that will be used in production workflows.” The role expects 25 to 50 percent of the time at customer sites, “to build in person with customers.”
Both companies offer this to their most strategic customers. Both describe engineers who work closely with the customer’s own teams and build production software themselves. Only OpenAI says its engineers own delivery “from first prototype to stable production” and count success by production adoption.
Sources: OpenAI, Forward Deployed Engineer job posting; Anthropic, Forward Deployed Engineer job posting (Munich). Both read on 16 October 2026.
What the work looks like
The first weeks look less like engineering than most people expect. The engineer sits with the people who do the work: the planner who checks stock every morning, the person who answers service emails, the team lead who builds the weekly report by hand. They write down what really happens, including the exceptions nobody mentions in a meeting.
Then they find where the data lives. Usually it is spread across an ERP, a CRM, a few shared spreadsheets, and a lot of email. Connecting those is often the biggest part of the job, and it is hard to do from outside the company.
After that, the building starts, in small pieces. One agent might watch orders and supplier dates and flag the orders likely to be late. Another might sort incoming service requests and draft replies to the routine ones. Each piece runs next to the old way until people trust it. The engineer changes it based on what they see each day, because they are in the room when it goes wrong.
Near the end, the work shifts to people. Someone on the team learns how each piece works, where its records are, and what to do when it fails. The engineer leaves a list of what to automate next, based on what the company learned along the way.
Consultant, agency, new hire
Companies usually have three other ways to get this kind of help. Each one is good at something.
| Who | Where they work | What you get | Afterwards |
|---|---|---|---|
| Consultant | Mostly in meetings and workshops | Analysis and recommendations | Your team builds it, or hires someone who will |
| Agency | In their own office, from a brief you write | A finished project built to that brief | A support contract, or your team takes over code it didn’t write |
| New hire | Inside your company, for good | A person who learns your business over time | They stay, if you find and keep the right person |
| Forward-deployed engineer | Inside your company, for a set period | Working software in your systems, and people trained to run it | Your team runs it, with the engineer available if you want |
The biggest difference is where the knowledge ends up. A consultant leaves a recommendation. An agency builds from a brief, and the brief only holds what you knew to write in it. A forward-deployed engineer finds the things nobody wrote down, because they are there when those things happen.
A good hire does the same in the long run. But finding an experienced engineer who also knows how to build with AI agents takes time, and a permanent salary is a lot to pay for a few months of change. You can also do both: bring in an engineer for the first months, and hire someone who learns from them and takes over.
When a smaller company needs one
The model works for a company of twenty or two hundred people, as long as a few things are true:
- The work you want to change involves several people or systems, so one automation won’t cover it.
- It repeats often enough that it matters every week.
- You can give the engineer real access to systems and data, under rules you set.
- Someone on your team will own the result when the engineer leaves.
- You can give it a few months. Less is rarely enough to go from watching the work to daily use.
It is the wrong choice when the job is small and clear. If one team loses hours every week to one kind of task, a short sprint is faster and cheaper. If the work is mostly your own week, a personal setup fits better. It is also the wrong choice if nobody can get the engineer access to the systems, or if what you want is a strategy document. In those cases the engineer spends weeks waiting, and you pay for the waiting.
Whichever way you go, the first step is the same: write down how the work is done today. Most work is never written down explains how.
How I do it
This is the third way I work with companies. I join for three months or more, on site in Frankfurt or remotely, and work with your people, systems, and data. Usually that means operations: sales and service, inventory, purchasing, and production. There, agents can watch stock and supplier delays, prepare orders, sort service requests, and connect systems that never talked to each other. Where your data supports it, I also build custom machine learning models, for example to forecast demand.
I started as a systems engineer and spent years building web applications in JavaScript and TypeScript. Today I build most of my own software together with AI agents, including Flowmind and Text Atlas. I work the same way inside a company: agents do much of the building and checking, and people decide what matters.
At the end you have agents and software built into how your company runs, a team that knows how to work with them, and a clear list of what to automate next. The details are on the services page.
If you are thinking about this for your company, write to me. Tell me what takes up your team’s time, and I’ll tell you whether a few months inside your company is the right fit or whether something smaller would do.