How FDE Differs from AI Accompaniment | They Are Different Jobs Once You Look at What Is Being Sold

Hello, this is Ryuta Hamamoto from TIMEWELL.

"Send an engineer to the floor and AI will reach production." I have been hearing that a lot this past year. The name is FDE. Forward Deployed Engineer. Palantir grew the role, and OpenAI and Anthropic now use the same words in public.

In Japanese meeting rooms, the next question is almost always the same. Isn't that just an on-site SE? How is it different from the AI accompaniment consultancies sell?

I will start with the answer. It is not two names for similar work. What is being sold is different. Who owns the deliverable is different. Whether anything is written into the system is different. Accompaniment is one of the things we sell. That is why I wanted to put our own product on the shelf and sort it out. Otherwise this is not useful to you.

What is failing is not the model

MIT NANDA's July 2025 report, "The GenAI Divide: State of AI in Business 2025", is blunt with the numbers. Enterprise spending on generative AI is estimated at 30 to 40 billion dollars. Against that, 95% of organisations have not seen a measurable return¹. Of the integrated pilots, 5% are drawing out value in the millions of dollars. ChatGPT and Copilot have been tried by eight in ten organisations, and nearly four in ten have adopted them. That is individual productivity. It has not reached the profit and loss account.

There is a set of numbers closer to the floor. 60% of organisations looked at a dedicated enterprise tool. 20% made it to a pilot. 5% reached production¹. The survey window is January to June 2025. More than 300 public AI cases, interviews with 52 organisations, a survey of 153 senior people. The report itself calls the findings preliminary. The direction is still clear.

The report is explicit: the cause is not weak models. The barrier is learning. Most generative AI systems do not keep feedback and do not improve against the context they sit in. Larger companies run more pilots and then lag on the move into production. Working with an outside partner was about twice as successful as building only in-house¹.

In the source material we called this the implementation gap. MIT's term is the GenAI Divide. Either name is fine. What I see on site is simpler. It runs in the meeting room. It stops on the messy data of the floor. Once it stops, the person in charge does not touch it again.

Traditional business systems could be built on the premise that if you put A in, B comes out. Requirements, design, build, test, handover. If it does not match the spec, it is a bug. The moment you put an LLM in the path, the same input can produce a different output. That is not a bug. That is the machine. Behind one line that says "read the amount on the invoice" sit handwriting, missing stamps, multiple tax rates, a different layout for every supplier. You will not find that in the meeting room. You only see the shape of the failure once you run it.

So you need a loop: watch, fix, watch again. While the work is still moving. Whether someone on the floor can run that loop is usually what decides if the project lives.

If you want a read on whether your own AI use is still at the trial stage or just short of production, the AI literacy check will give you a current position.

What does an FDE actually do?

An FDE is an engineer who goes into the customer's organisation to develop and implement, so that the vendor's own product actually runs in the customer's production environment. "Forward deployed" is a military phrase. You put the unit on the front line, not at headquarters.

The origin is Palantir. In the early years, customer data was dirtier than expected, the work was more complicated than expected, and there was often nobody who could even give you requirements. So they sat an engineer at the next desk and made them learn the work itself. Later write-ups agree that this is where it started. We have not seen the inside of Palantir, so I will not treat the founding story as established fact. The shape of the role is still there. You do not wait for a specification. You put something that runs on the customer's real data first.

The signature habit is shipping code on day one. Spend 90 days locking requirements, demo on clean sample data, then break on live data the week before go-live. That is a common way to die. The FDE pattern is the reverse. Touch live data on day one. Put something incomplete but running in front of the person who does the job. People cannot put their own work into words in front of a blank specification. Show them something that moves and they start saying "not in this case" and "this one needs the section head's sign-off." The prototype is not a deliverable. It is a questioning device for pulling out requirements.

Technical skill is not enough. You have to be able to build a distributed system yourself. You have to learn, in a few weeks, enough to argue with the customer about aircraft maintenance rules or the appended tables of Japan's Export Trade Control Order. You have to pull different demands from the executive, the business-unit head, and the floor, and fold them into one design. That last one is the hardest. The executive wants to change what the industry treats as normal. The business-unit head wants to cut this year's cost. The floor does not want the current procedure touched. Finding the one point that satisfies all three is the actual job.

From 2025 into 2026, the role stopped being Palantir's private property. In a 4 June 2025 essay, a16z called FDE the hottest job in startups, and framed it as temporarily taking a hit to gross margin in order to hold implementation and buy a moat². The jump in job ads is not in the a16z text. It is a figure reported by the Financial Times and others from Indeed Hiring Lab: listings from January to September 2025 were up more than 800%³. That is a press figure. Read it with a range.

The moves you can check in primary sources are more recent. On 11 May 2026 OpenAI announced the OpenAI Deployment Company. The short name is DeployCo. It is acquiring Tomoro, an applied-AI consultancy, and putting about 150 FDEs and implementation specialists in place on day one. Initial investment is more than 4 billion dollars. TPG leads, and consultancies and systems integrators are also on the list⁴. On 4 May 2026, in an announcement from the financial-infrastructure firm FIS, Anthropic said its Applied AI team and FDEs would be embedded in FIS to jointly design an agent for financial crime. The aim, the release says, is not to stay on site forever. It is to hand over the knowledge so FIS can run on its own⁵. That is a step more restrained than the "standing on-site team" in the source material.

Accompaniment and FDE sell different things

This is the main point. If you only look at "we go on site" and "we build together", you cannot tell them apart. Break the inside and they are different businesses.

Accompaniment and on-site development sell hours. Revenue is person-months. The number that matters most becomes utilisation. Empty time is cost. A longer engagement is, at least for near-term revenue, a plus. An FDE sells a product. The FDE's hours are not revenue. They are an investment to get the product into the customer's work. The metric is time until the customer feels the value. The faster you stand them up, the faster you reach the main contract and the sideways rollout, the more the seller gains. A structure that makes more money the longer you stay, and a structure that makes more money the sooner you let go. The arrows point opposite ways.

Ownership of the work splits too. What on-site development builds becomes the customer's asset. Source is handed over. Maintenance sits with the customer or another vendor on a separate contract. What stays with the seller is the individual engineer's experience. What an FDE builds is an application on the seller's own platform. The design aim is that when the platform goes up, the customer goes up with it. In a metaphor: on-site work lays a gravel road for each customer. It fits that customer. It starts ageing the moment it is laid, and the next customer cannot use it. An FDE lays the gravel and brings the paving method home. Pull a pattern out of the pain on the floor and lift it into a standard feature. The cost of rolling out to the next customer falls. An FDE that does not run this loop is just expensive contract work.

The deepest difference is read versus write. Almost everything accompaniment and a proof of concept produce is read-only. Analyse, visualise, offer a finding. There is no permission to change a record in the core system. Judgement and execution stay with people. An FDE takes it through to write-back. Allocate stock. Raise an order. Rebuild a shift. If a read-only system is wrong, a person can notice and stop. If a write is wrong, reality breaks. A bad order. A bad shipment. A bad credit decision. So you need a set: the types of action that are allowed, permissions, a simulation before the fact, a human in the loop on serious calls, and an audit trail. A write without that set should not be done. Engagements that start with "we will accompany you" rarely go this far. To write is to take responsibility.

Where the learning sits is different too. Accompaniment knowledge collects in the consultant's head. If the person leaves, it goes. When FDE works, the knowledge collects in a structure of meaning. What is a customer in this company? At what point is a shipment complete? If delay crosses a threshold, who is hit and with what? You pin that down in a form a machine can read. It stays when people leave. The name is ontology. It sounds harder than it is. What you are doing is teaching the AI this company's nouns and verbs.

Item	Accompaniment and on-site development	FDE
What is sold	Hours	An investment that embeds the product in the customer's work
Metric	Utilisation	Time until the customer feels the value
Deliverable	Customer asset	Product asset
System	Read	Write
Learning	Inside the consultant's head	Structure of meaning and standard features
Ideal relationship	It lasts a long time	The customer stands up quickly, then it spreads sideways

Our WARP sits closer to the left column of that table. Hiding that would be spotted immediately, so I will say it first. This is not a piece against accompaniment itself. It is against accompaniment that stays read-only and leaves behind a beautiful report. Accompaniment that does not put the right-hand column into the design — write-back, the loop home, and being measured on the customer's performance numbers — drifts towards the 95% MIT described.

An agent cannot run if you have not taught it the nouns and verbs

The first thing an FDE does on site is put down a structure of meaning. Scattered data gets defined as entities: customer, invoice, part, worker. Then as actions: refund, place an order, rebuild a shift.

Most companies will say they already have a data platform. Conventional normalised models are designed to hold a slice of now. They are thin on the thickness of time. A star schema is strong at aggregation and pre-joins, and the transformation logic hides inside the ETL. Both are well made for a person looking at a graph and deciding. They are not enough for a machine to walk the path and execute. I wrote about putting the relationships themselves into a form you can walk from another angle in What graph engineering actually is.

Some people will say this is not the same thing as academic ontology, RDF, or OWL. Those are strong at static knowledge representation and search. What the floor needs is a cycle: execute, write back, learn. In layers: a layer that holds the nouns, a layer that holds the actions, a layer that holds permissions and simulation. The operations defined in the action layer become tool calls from the LLM's point of view. Ordering a part number that does not exist stops being something the type will accept. The idea is to hold hallucination down with structure, not with a cleverer prompt. The reason agents break on long jobs sitting more in the environment than in the model is the same ground I covered in An introduction to agent engineering.

I will keep the cases I could confirm separate from the ones I cannot write as they stood in the source material.

Airbus Skywise appears in an official announcement dated 20 June 2017, as an aviation-industry data platform built with Palantir⁶. The sequence is: use it first in Airbus's own manufacturing and maintenance, then open it to airlines. The figure that A350 deliveries became 33% faster sits in Palantir's public material⁷. It does not appear in the Airbus release. So I treat it as Palantir's claim, and as an official announcement I only write the launch of Skywise. The story in the source material about shipping a digital twin in three days is not something I could trace in Airbus primary sources. I am not writing it.

On John Deere, OpenAI published a conversation in May 2025 in which the John Deere side says See & Spray targets weeds only and cuts chemical use by up to 70%⁸. That is a product story. The story in the source material about an FDE going onto an Iowa farm and making a harvest deadline is not something I could pull from the same conversation. The point that production needs the three-piece set of evaluation, plumbing, and control still seems right to me. I do not have the grounds, this time, to write that as a John Deere FDE engagement.

What I can confirm is that the role is spreading. OpenAI has carved out an implementation company. Anthropic has put FDEs inside FIS. a16z's "trade margin for moat" is a management argument. 2010s SaaS won on self-serve and high gross margin. Generative AI that replaces a core workflow needs a deep connection and real permissions. Self-serve alone is hard to get past. Put more people in, take a temporary hit to gross margin, and hold the door into the data and the work. ServiceNow's gross margin at IPO was 63.2%, Workday's 54.1%. By 2024 they were back to 79% and 75%, a16z writes². Whether you can live with the short-term criticism of margin is the question. Deciding to put FDEs in is less a technical call than a management one.

An FDE in name only is worse than contract work

It is not a cure-all. An FDE that does not loop knowledge home is just expensive person-months. What share of the features born on the floor this quarter made it into the standard product? An organisation that is not tracking that should not call itself FDE.

Keep stacking customer-specific exceptions and the codebase breaks in a few years. Is this a pattern that should be standardised, or a branch for this customer only? The ability to refuse is a skill. Keep writing scripts on the floor without putting down a structure of meaning, and the moment the person leaves, nobody can touch it. Being on site is not the point. Turning the tacit knowledge of the floor into structure is. Using "we will send an engineer" as a way to close a deal becomes free customisation. Is this customer's pain shared by many others? Putting people in without that investment hypothesis is a stand-in for sales.

The prescription for a Japanese company is not to import a job title. Narrow it to the one process that hurts most. Start with company-wide digital transformation and you are back in the meeting room. Write out the nouns and verbs of that process in the floor's own words. Translate into system language later. On day one, put down something incomplete that runs. Do not measure 95% accuracy. Measure whether three hours became twenty minutes, or how many points the send-back rate fell. Before you write, put permissions, simulation, a human in the loop, and an audit record in place. Do not connect anything that lacks those four to a core system. Recording what the agent read and binding the exit is also what I wrote in Why Cloudflare OS is open source. The idea points the same way.

Accompaniment is work that supports the customer while they decide. You offer findings. You lay out options. Final responsibility sits with the customer. That is necessary work, and we sell it. An FDE is work that carries, all the way to the floor, the responsibility the vendor's product takes for the customer's reality. That is why it writes. That is why it builds governance. That is why it is measured on the customer's performance numbers. What it learns there comes home into the product and becomes the paving for the next customer.

The 95% are stuck not because the model is weak. Because nobody carried responsibility as far as the floor. Generative AI will keep getting more capable. The implementation ditch will not fill on capability alone. What fills it is people who go down, and a structure that turns what they bring home into product.

When we take on the design on the floor, that is WARP. The side that keeps internal knowledge as relationships is ZEROCK. If what you want is not to import a job title, but to decide how far one process in your own company should write, start from a conversation and tell us where you are.

---

Footnotes

1. MIT NANDA, "The GenAI Divide: State of AI in Business 2025" (Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari, July 2025). Survey period January to June 2025. Review of more than 300 public AI cases, structured interviews with 52 organisations, and a survey of 153 senior people collected at four industry conferences. Enterprise spending on generative AI estimated at 30 to 40 billion dollars; 95% of organisations have not seen a measurable return; of integrated pilots, 5% are drawing out value in the millions of dollars; ChatGPT and Copilot have been tried by more than eight in ten and adopted by about four in ten, but stay at individual productivity; dedicated tools: 60% considered, 20% piloted, 5% reached production; the barrier is not model quality but learning (not retaining feedback, not adapting to context); success with an external partner is about twice that of an in-house build; large companies lead on pilot count and lag on scale. All of the above is from the same report. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf ↩ ↩² ↩³

2. Andreessen Horowitz (Joe Schmidt), "Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups" (4 June 2025). In enterprise AI, product-led growth alone struggles to replace core workflows; thicken implementation support, temporarily lower gross margin, and take a moat. ServiceNow's gross margin at IPO 63.2%, Workday's 54.1%; by 2024, 79% and 75% respectively. Of OpenAI's 311 public job listings, 22 were FDE or solutions-related. All of the above is from that essay. The text does not contain the 800% rise in job ads. https://a16z.com/services-led-growth/ ↩ ↩²

3. A figure that Forward Deployed Engineer-related job listings rose more than 800% from January to September 2025. Secondary reporting of Indeed Hiring Lab analysis by the Financial Times and others. Not included in the a16z essay above. https://m.economictimes.com/magazines/panache/what-are-the-hottest-jobs-within-ai-hiring-up-800-this-year/articleshow/125036908.cms ↩

4. OpenAI, "OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence" (11 May 2026). Establishment of the OpenAI Deployment Company (DeployCo for short); agreement to acquire the applied-AI consultancy Tomoro; about 150 FDEs and Deployment Specialists; initial investment of more than 4 billion dollars; OpenAI holds a majority; TPG-led investment and consulting partners. All of the above is from that announcement. https://openai.com/index/openai-launches-the-deployment-company/ ↩

5. FIS, "FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes" (4 May 2026). Anthropic's Applied AI team and FDEs embedded in FIS; jointly design a Financial Crimes AI Agent; transfer knowledge so FIS can later expand agents on its own; BMO and Amalgamated Bank as early adopters. All of the above is from that announcement. https://www.fisglobal.com/about-us/media-room/press-release/2026/fis-brings-agentic-ai-to-banking-with-anthropic-starting-with-financial-crimes ↩

6. Airbus, "Airbus launches Skywise – aviation's open data platform" (20 June 2017). An aviation-industry data platform in collaboration with Palantir; used first in Airbus manufacturing, engineering, and services, then opened to airlines. All of the above is from that announcement. A digital twin shipped in three days, and a 33% acceleration of A350 deliveries, are not in this release. https://www.airbus.com/en/newsroom/press-releases/2017-06-airbus-launches-skywise-aviations-open-data-platform ↩

7. Palantir's public impact description of Airbus / Skywise. Foundry accelerated A350 delivery by 33% and the work was extended into Skywise in 2017. Unconfirmed in Airbus's official announcement, so this article treats it as Palantir's claim. The URL is not placed in the footnote body, to avoid sending readers to a competitor product page. ↩

8. OpenAI, "John Deere transforms agriculture with AI" (conversation with Justin Rose, 6 May 2025). See & Spray sprays weeds only and reduces chemical use by up to 70%, per the John Deere side. This conversation does not describe an FDE stationed on a farm during harvest. https://openai.com/index/john-deere-justin-rose/ ↩