What Is an FDE (Forward Deployed Engineer)? | A Beginner's Explanation of the Job, Seven Secrets for Drawing Out Insight on Site, and Why We Openly Work FDE-Style

Hello, this is Ryuta Hamamoto from TIMEWELL. I spent more than ten years building new businesses inside large companies, led "CHANGE by ONE JAPAN", a challenger-support programme with over a hundred large companies, and now run WARP ENTRE, an AI-driven development programme for founders and intrapreneurs. Our company openly says it works "FDE-style". Whenever I say that, the same question follows: what is an FDE? This article answers it for people encountering the term for the first time, and then sets out, concretely, the technique FDEs use in the field to draw out insight.

Summary: A Forward Deployed Engineer (FDE) sits next to the customer and does the development and implementation needed to get their company's product running in production on site. Palantir started it; a16z called it "the hottest job in startups" in June 2025; in 2026 OpenAI set up a deployment company with about 150 FDEs and Accenture launched an FDE practice in Japan on the scale of thousands of engineers. The difference from contractors and consultants is in what is sold: FDEs sell a product and feed what they learn on site back into it. Seven secrets for drawing out insight: sit next to the customer, touch real data on day one, use something working as a questioning device, collect exceptions, write down nouns and verbs, listen to the three layers separately, and bring it back weekly.

What an FDE is: the job in three minutes

FDE stands for Forward Deployed Engineer. "Forward deployed" is a military term: units placed at the front line rather than at headquarters. Translated into software, it means an engineer who does not wait for a spec at head office but sits at the customer's site and builds there.

Here is the job as a day in the life, for first-timers. In the morning you report to the customer's factory or office, not your own meeting room. At the desk next to the person in charge, you are shown the systems they actually use and the data they actually hold. Dirty data: inconsistent manual entries, blanks, field names that differ by department. That same day you build something imperfect that runs on that data and put it in front of them. They say: "not in this case", "this needs the section head's approval". You fix it and put it back. Within weeks it goes to production; you fix what production reveals; and what you learned along the way goes back into your company's product so the next customer gets it as a standard feature from day one. That is an FDE's day, and an FDE's engagement.

The origin is Palantir. In its early years, customers' data was dirtier than expected, their work more complex, and there was nobody who could articulate requirements. So engineers were seated next to the customer and made to learn the work itself. Later accounts agree on this. We have not seen inside Palantir, so I will not state the founding story as fact, but the shape of the role is there. In January 2026 a16z summarised the model as parachuting a small team into a messy environment and standing up a customised working platform in months¹.

Here is how it compares with similar jobs. This is the point I most want first-timers to take away: seen only as "goes on site and builds together", they all look the same, but what they sell is different.

Role	What is sold	Where the output goes	Relation to systems	Ideal engagement
Pre-sales engineer	The contract	A proposal	Explains	Short, until signature
Implementation consultant	Advice and reports	The customer's decision	Reads, visualises	Fixed period
On-site contractor	Hours (person-months)	The customer's asset	Writes on instruction	Longer is more revenue
FDE	A product, and the investment to embed it	The product's standard features	Reads and writes back	Fast self-sufficiency, then spread

For contractors, the longer the engagement, the more revenue. For FDEs it is the reverse: the faster the customer becomes self-sufficient and the sooner the next customer can be served, the better. That is why an FDE's hours are an investment, not revenue. I went into this in detail, from what is sold, who owns the output, and the responsibility of writing back, in How FDEs differ from AI "accompaniment" support.

Why it spread so fast in 2025 and 2026

The word FDE started appearing in Japanese news only in 2026, for one reason: generative AI deployments are not reaching production. MIT NANDA's July 2025 report found that despite an estimated $30–40 billion of corporate investment in generative AI, 95% of organisations were getting no measurable return. The cause was not model performance but the absence of any mechanism to accumulate feedback from the field and improve². It works in the meeting room and stops on the dirty data of the real workplace. Once it stops, the person in charge never touches it again. The demand for someone to bridge that gap is what brought the FDE back.

The US milestones, in order. On June 4, 2025, a16z's Joe Schmidt published "Trading Margin for Moat", calling the FDE "the hottest job in startups". The argument is a business one: enterprise AI cannot reach core workflows through self-serve adoption, so it is worth thickening implementation and temporarily lowering gross margin to buy a moat at the data and workflow entry point. The same piece noted that 22 of OpenAI's 311 open roles were FDE or solutions positions³. On January 16, 2026, a16z's Marc Andrusko wrote "The Palantirization of everything", noting that FDE job postings were "up hundreds of percent this year" while warning that Palantir works because there is a real platform underneath; copy only the embedded-engineer part and you end up with an unmaintainable pile of bespoke deployments¹.

In spring 2026 the model makers moved. On May 4, FIS, the financial infrastructure company, announced that Anthropic's Applied AI team and FDEs would be embedded inside FIS to co-design AI agents for financial crime, with the stated aim not of staying permanently but of transferring know-how so FIS could continue on its own⁴. On May 11, OpenAI announced the OpenAI Deployment Company, acquiring the applied-AI consultancy Tomoro, starting with about 150 FDEs and deployment specialists and more than $4 billion of initial investment⁵. In the summer, a16z started an eight-week FDE Fellowship whose founding fellows include an OpenAI FDE, Cursor's regional director of AI deployment and a former Palantir FDE lead⁶.

Japan moved the same year. On April 16, 2026, Accenture announced, with Microsoft's cooperation, a "Forward Deployed Engineering" practice in Japan. The core sentence: the barrier to AI adoption at many companies is not a lack of technology but engineering expertise not being brought to bear on site. Thousands of AI-skilled engineers would be brought together to work directly with customers⁷.

One sober note. The FDE is not a cure-all. As a16z warns, sending engineers to customers without a product underneath is just expensive contracting. The condition for an FDE model to work is that what is learned on site flows back into the product and lowers the cost of the next deployment. I would be wary of any company calling itself "FDE" without that loop. If you want a quick read on where your own company stands, the AI literacy check takes a few minutes.

Why we openly work FDE-style

TIMEWELL builds ZEROCK, which holds a company's internal knowledge in a form agents can traverse, and TRAFEED, an AI agent for export control, and runs WARP, an AI-driven development programme. And we say openly that we work FDE-style. Three reasons, in plain terms.

First, our products are the kind that only work once you are inside the customer's operation. For an AI to traverse a company's knowledge, the company's nouns and verbs have to be made machine-readable: what "customer" means here, at which point "shipment complete" occurs, who is notified when a "delay" crosses a threshold. None of that can be learned in a head-office meeting room. Export control is the same: whether a part falls under a regulation can only be judged from the drawing, the spec and the actual counterparty. The product cannot be sold and left, so there is no way to do it other than putting engineers on site. That is the honest reason.

Second, we do not want to be on the 95% side. In the engagements I have been part of, I have watched a clean demo win agreement and then break on real data, many times. A meeting-room demo teaches you half the requirements. The other half only comes out when something working is put in front of the person in charge. So we ship code on day one. Imperfect is fine. Someone looking at something that runs starts saying what they could never have written on a blank spec.

Third, we are small enough to feed field learning back into the product. Corporate FDE practices run to thousands of people; we are a small company. The advantage of small is that the engineer on site and the engineer building the product are the same person or sit next to each other. An exception found on a customer's floor on Friday is judged "a pattern other companies have too" the following week and becomes a standard feature. That speed of return is why FDE-style makes sense for a small company.

To be candid, the training and accompaniment side of WARP sits close to "implementation consultant" in the table above. But what we sell there is not a report; it is a state in which participants can build something working themselves, run on the same philosophy as the product. The "build while you listen" method in Building the mock while you interview is the FDE's field technique transplanted to new-business teams.

Seven secrets for drawing insight out of the field

Now the substance. An FDE's value lies not in coding speed but in the technique of drawing the real requirements out of the field. Here are seven, in a form anyone can use, engineer or not.

Secret 1. Sit at the customer's desk, not in the meeting room. In a meeting room people describe the work as it should be. At the desk you see the work as it is. The first thing I ask is one sentence: "Could you show me your usual task, done the usual way, while I watch?" Watching, you always find steps that were never explained: exception rules on sticky notes, hidden Excel columns, a separate screen opened to check with a manager. Most insight lives not in the explanation but in those unexplained steps.

Secret 2. Touch real data on day one. Sample data lies. Whatever ran on a tidy hundred-row sample will stop on a hundred thousand real rows. So on day one, get the real thing, anonymised if necessary. The share of blanks, the drift in field names, mixed date formats, operations that differ by department. The dirtiness itself is the requirement. Never say "let's clean the data first". By the time it is clean, the field has moved three months on. Building something that runs on dirty data is the FDE's job.

Secret 3. Show something working as a "questioning device". People cannot articulate their own work in front of a blank spec. They can in front of something that runs. "Not in this case." "That screen would never work on our floor." So put something imperfect and working in front of them on day one and ask only "what's different?" Ask "what do you think?" and you get compliments and nothing else. The technique transfers directly to new-business interviews; Part 1 of the series lays out the procedure and prompts as the "live mock".

Secret 4. Collect the "when it went wrong", not the "usual". The usual work mostly runs on existing systems. The FDE's room to add value is in the exceptions. "What was the worst case last month?" "How did that one finally get handled?" "Who knows how to handle it?" Exceptions are rules that exist only in someone's head, written in no system and no manual. On site I keep an "exception notebook". When it reaches ten entries, three of them turn out to be things that actually happen every week. Those are the first features to build.

Secret 5. Write down the company's nouns and verbs in the field's own words. Customer, invoice, part, operator. Refund, order, reshuffle the shift. Write down the nouns and verbs as this company uses them, without translating into system vocabulary. One remark, "here, 'allocated' and 'reserved' mean different things", can change the whole design. This glossary becomes the prototype of the "structure of meaning" you later teach the AI. Formally it is an ontology; in practice it is turning the company's own words into a dictionary.

Secret 6. Listen to management, division heads and the floor separately. The three layers want different things from the same project. Management wants to change the industry's norms, the division head wants to cut this quarter's costs, and the floor does not want to change today's procedure. Put all three in one room and only management's voice survives. So listen separately. Then look for the single point that satisfies all three: leave the floor's procedure alone, cut this quarter's costs, and be able to talk about the industry next year. Sometimes it does not exist. Learning that it does not is also insight.

Secret 7. Bring it back weekly and feed the product. Do not fix what you find on site and move on. Once a week, take it back and classify it: a branch specific to this customer, or a pattern others share? Patterns become standard features. Branches are recorded as branches and watched so they do not multiply. Skip this weekly sorting and six months later you have ten different things for ten customers that nobody can maintain. What a16z calls the services trap is the result of neglecting it. The record you bring back is exactly the progress document described in Part 3, spec-driven development.

What the seven share is a centre of gravity on seeing rather than asking, and on running something and taking the reaction rather than getting people to talk. And what changed in the AI era is the speed of Secret 3, building the working thing. Shipping code on day one used to be for strong engineers only. Now, with a coding agent, a new-business manager can put up a rough screen in minutes. The FDE's field technique is no longer engineers-only.

What the receiving company must prepare: do not lock the FDE in a meeting room

Finally, for the large companies on the receiving end. Engagements where an FDE arrives and nothing comes of it share one shape: the FDE locked in a meeting room.

First, a seat. Provide a desk next to the person in charge and a screen showing the real systems. A day in the visitors' meeting room shows nothing but slides. Next, data. Decide the anonymisation procedure in advance so real data can be touched on day one. "After the security review" costs three months. Run the review in parallel and work on anonymised data meanwhile.

Decide permissions up front. Read only, or write back? If writing back, which actions, under whose approval, and how far automatically? Leave that vague and put it into production and you get mis-orders and mis-shipments. Writing back needs four things: permissions, prior simulation, human involvement in serious decisions, and an auditable record. That is not a technical matter; it is a decision for the receiving side.

Reserve the person's time, too. The FDE learns by sitting next to the person in charge. If that person keeps saying "later, I'm busy", the FDE has to build from guesswork and you are back to the meeting-room demo. A few hours a week is enough, but book it as part of the project. And measure success in business metrics: not "95% accuracy" but "did three hours become twenty minutes?", "how many fewer returns for correction?" Measured on technical metrics, the evaluation ends before anything reaches production.

Last, do not ask for requirements on paper. The moment someone says "send us the requirements document first", the FDE model breaks. Requirements emerge after something working has been put down. Paper is written afterwards, as a record. Agree that order in advance with procurement and the IT department. When we go on site, we settle this preparation together in the first meeting. The programme structure is on the WARP page.

Wrapping up

An FDE is an engineer who sits next to the customer and builds, so that their company's product runs in production on site. What is sold is the product, the hours are an investment, and the learning goes back into the product. Between 2025 and 2026, a16z, OpenAI, Anthropic and Accenture in Japan all put people and money into this model, because 95% of generative AI is not reaching production.

Seven secrets for drawing out insight: sit at the customer's desk, touch real data on day one, use something working as a questioning device, collect exceptions, write nouns and verbs in the field's words, listen to the three layers separately, bring it back weekly and feed the product. We work FDE-style openly because our products only run once we are inside the customer's operation, because we refuse to be on the 95% side, and because we are small enough to return what we learn to the product.

If you do one thing tomorrow, ask one person in your company: "Could you show me your usual task, done the usual way, while I watch?" You will find at least one unexplained step. That is your first insight. If you want to design the on-site work for one of your own processes together, let's talk through a consultation.

Footnotes

1. The Palantirization of everything (Andreessen Horowitz, Marc Andrusko, January 16, 2026) ↩ ↩²

2. MIT NANDA, The GenAI Divide: State of AI in Business 2025 (July 2025). Estimated $30–40 billion in corporate generative AI investment, 95% of organisations with no measurable return, and the barrier being learning and context adaptation rather than model performance are from that report. See How FDEs differ from AI "accompaniment" support ↩

3. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups (Andreessen Horowitz, Joe Schmidt, June 4, 2025) ↩

4. FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes (FIS, May 4, 2026) ↩

5. OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence (OpenAI, May 11, 2026) ↩

6. FDE Fellowship (a16z Build, Summer 2026 cohort, eight weeks) ↩

7. Accenture launches a Forward Deployed Engineering practice in Japan with Microsoft's cooperation (Accenture Japan, April 16, 2026, in Japanese) ↩