What is a forward deployed engineer?

The first cut of the video looked right to me. The presenter was talking about the downtown peninsula, and the drone footage under his voice showed streets, rooftops, water. The local partner watched it once and said: that is not downtown. That is the other side of the river.

He was right. The pipeline was an AI system: a speech model transcribed the presenter, a language model read the transcript and decided what each moment needed to show, and a second model wrote the on-screen graphics. All of that worked. The part that failed was mine: I had grouped 112 drone clips into neighborhoods by GPS proximity, and the coordinates for the two areas are close enough that a naive clustering puts them together. A river runs between them. Anyone who lives there knows the difference in a second. No model, and nobody who does not live there, could have caught it from the numbers.

That moment is the job. A forward deployed engineer is the person who is close enough to the customer's work for that correction to happen in the first week instead of after launch, and who then fixes the actual thing: not the clip, and not the model, but the ground the model was standing on. The fix was boundary polygons and point-in-polygon tests, written the same afternoon, and the lesson went into a file so it would never be relearned.

Where the term came from, and why it came back

Palantir coined it for engineers who were sent to sit with a customer, often a government department or a large company, and build directly on that customer's data rather than ship a generic product and hope it fit. The joke inside the industry was that Palantir was a consultancy pretending to be a software company. The engineers themselves knew it was neither: they were building product, just from the wrong end.

The term came back with the current wave of AI because the same problem returned in a sharper form. A language model is a general capability. The value is in wiring it to one company's invoices, one company's claims process, one company's customer history, and the wiring is where every AI pilot actually fails. The labs learned this and started hiring engineers to go and sit with customers. Everyone else learned it by watching a pilot that impressed the board and never went live.

That is why the role is, today, an AI job. Not because the engineer trains models; almost nobody does. Because the model is now the cheap, general part, and the expensive, specific part is making it correct inside one company: what it is allowed to read, what it must never say, what happens when it is wrong, who checks it, and how it gets into the system the staff already use. Every engagement on this page had a model at the center and the work was all around it.

So the role is not a product of one company. It is a way of working that any senior AI engineer can take into any business, and the rest of this page is what it looks like when you do.

The first thing you write is not code

The first artifact of every engagement I have run is a list of decisions that are not mine. On the engagement above it was a file with a section headed "founder decisions, do not relitigate". Nine lines. Which data source is in and which is out. No phone calls to customers, ever. Which segment first and which later. Which platforms get budget and which are an explicit extra. Even which AI model to use.

Alongside it sat the owner's operating rules: no live change to the domain or the running site without his say-so; keep the analytics exactly as they are; plain English in anything he reads.

Engineers tend to read a list like that as friction. It is the opposite. Every one of those lines is a decision I no longer have to make, defend, or revisit, and every one of them is a boundary the owner will not have to police. When I build my own things I rebuild from scratch freely; one project of mine went from version one to version two with 238 commits discarded after six days. Inside someone else's business you do not get to do that. The list is what makes speed safe.

A week, honestly

People imagine the work as heroic. Mostly it is a sequence of small wrong turns, each caught by a measurement, each written down. The models in that pipeline, transcription, planning, graphics generation, cost me almost no time; the week went on everything around them. A representative week from the same engagement, from the notes I kept at the time:

• The first automated edit desynced its own audio. I had concatenated presenter footage and drone clips into one timeline. Concatenation adds the clip's duration to the video track, so by the first cutaway the voice was drifting behind the picture. The fix was to overlay the clips on top of the presenter track for a timed window instead, which leaves the audio untouched. One evening lost, one principle gained: replace, never append.
• A quality setting turned a 439 MB file into 1.87 GB. The encoder's "best" preset. Backing off to a sane one gave 247 MB that nobody could tell apart from the bloated version. The number went in the decision log with the reason, so the next person does not repeat the experiment.
• Uploads over 100 MB were failing at the proxy with a timeout. Not a video problem at all; the reverse proxy in front of the app gave up before the file arrived. Signed upload URLs straight to storage, bypassing the proxy entirely, fixed it and made the app faster for every file size.
• The database got corrupted when the host restarted the container. The platform kills containers without warning. Turning on full synchronous writes cost some throughput and ended the corruption. The operating environment is part of the system; you do not get to choose it.
• The render took fourteen minutes. Eleven chunks encoded one after another. Encoding them at the same time brought it to about two minutes. Removing an option the concatenation step did not need halved the merge on top of that, 90 seconds to 38.

None of that is clever. All of it only happens if the engineer is inside the workflow, running real footage through a real AI pipeline that the customer is waiting on, rather than demonstrating a model on sample files. The difference between a pilot and a deployment is that in a deployment, the fourteen minutes matter to someone. Most AI pilots never reach this week, which is why most of them never ship.

The last mile is other people's rules

The part of the job that no explainer covers is that the hardest constraints are not technical and are not yours. They belong to platforms, vendors and the customer's own approvals, and the only way to learn them is to try to ship.

On the same engagement the product had to publish content to five platforms. Each one has ceilings you discover by hitting them: one refuses any link that is signed or expiring, so the entire media store had to serve plain public URLs or nothing would post; one caps unverified accounts at fifteen minutes of video, so a full-length master fails silently; one drops reach sharply when a post contains a link; one takes no video at all and archives posts after about a week. I wrote every one of those into a playbook with a mark against it: works as is, needs a change, cannot do. Most of the "needs a change" items turned out to be the same three jobs, done once and reused.

Then there are credentials. The customer's keys, accounts and sign-offs are the slowest thing in any engagement, so I build so that they are never the blocker. Every external seam gets a real implementation and a deterministic stand-in, chosen by whether the secret is present. On one product that meant the whole system, with 127 unit tests and 179 endpoint tests, ran green with no cloud account and no vendor keys at all. When the keys arrive, one environment variable turns the real thing on. The customer never waits on me, and I never wait on them.

The handover is the deliverable

An engagement that ends with a running AI system and no handover has not ended. It has just stopped being visible.

The handover documents from that engagement, ten of them across four codebases, read like contracts because they have to work like contracts. Each one says who it is from and to, what shipped with the commit that shipped it, what was deliberately not built and why, and a numbered activation order that names who does each step: you hand over these records, the owner adds them, you verify, the owner sets these two secrets and redeploys, the owner triggers one real event, you confirm it landed. One of those documents ends with a line nobody volunteers: re-issue this key, because the current one was pasted into a chat.

That is what "the customer's team owns it" means in practice. Not a training session. A document that a person who was not in the room can execute.

What the role is not

It is not consulting. A consultant's artifact is advice; the client's team implements it, or does not, and the consultant is rarely in the room when it fails. On the engagement above I was in the room, and the local partner told me my code was showing the wrong side of the river.

It is not a solutions engineer. A solutions engineer works before the sale, proving that a product could solve the problem, usually on demo data. The forward deployed engineer works after the sale, making it solve the problem on the real data. Same skills, different accountability, different half of the timeline.

It is not an agency. An agency scales by putting more people on more clients and standardizing what it delivers. Forward deployed work does not standardize, because the whole point is that it is shaped by one company's data and rules. It scales by leaving the customer's team able to run it.

And it is not typing. On a retail platform I led for nineteen months, a live merchandising operation with purchase orders, cost of goods, stock transfers between stores, and integrations into the point of sale, the accounting system and the shipping carrier, a team of seven built on the ground I laid. I owned the architecture, the split between the transactional database and the analytics store, the AI layer that turned the sales and stock data into answers, and every integration into the systems the business already ran. The role is the decisions and the seams. Volume is what the team is for.

When this is the wrong call

I sell this way of working, so this section matters more than the others.

• The company has not decided what it wants solved. A forward deployed engineer arriving into that will spend the engagement finding the missing decision, expensively. A short piece of advisory work first is cheaper and more honest.
• Nobody inside will own the system. If there is no person who will run it after the handover, the handover has nowhere to go and the system dies the month the engineer leaves.
• The data is not actually accessible. Not "we have the data" but "an engineer can read it, this week, with permission". If the answer is a procurement process, start the procurement first.
• What is wanted is a strategy document. Some boards need one. It is a different job, and pretending an engineer is the cheap way to get it wastes both.
• The problem is small enough to buy. If a product on the market already does the thing, with the integrations you need, buy it. The forward deployed case is the problem that sits between products, inside your own process.

What to expect if you bring one in

1. You will be asked for decisions in week one, not code. What is in scope, what is out, what the engineer may not touch, who signs off on production changes. Write them down; they will be read back to you.
2. Something usable will ship every week, through a real channel. Progress nobody can touch is theater. If a week produces nothing usable, you will be told why in plain English.
3. Your people will catch things the engineer cannot. That is the design, not a failure. Put the person who knows the work in the review loop from the first cut.
4. The engineer will build around your slowest approvals so they are never waiting on you, and will tell you exactly which key or record is needed and when.
5. The engagement ends with a handover you can execute without them. If it does not, it has not ended.

By industry

How an engagement runs week by week, from the records, is on its own page: forward deployed engineering, how it actually runs. The method is the same in every business; what changes is the process worth building around. I have done this work in retail, real estate, media and ad platforms, robotics and inference, and I write up the opportunity in each industry as the pages land. Until then, the two measured pieces below are the closest thing to proof that exists on a page like this.

Common questions