“Forward deployed engineer” has become one of the most talked-about job titles in technology. Behind the title is a simple idea that matters to any Kuwaiti company trying to get AI past the demo: put a capable engineer inside the business, working on its real systems with its real people, until the thing works. The usual alternative is advice from outside or a product handed over at the door.
This is what the role is, why it has spread so fast, what the work looks like inside a company in Kuwait, and how to tell whether you need one.
Where the title comes from
The role was invented at Palantir in the early 2010s, as a16z notes in the announcement of its fellowship for forward deployed engineers. Palantir sold software that only paid off once it was wired into a customer’s messy reality, so it sent engineers to sit with the customer and do that wiring themselves, and to feed back into the product whatever kept getting in the way.
Gergely Orosz’s explainer in The Pragmatic Engineer puts Palantir’s own framing well: an ordinary developer builds one capability for many customers, while a forward deployed engineer covers many capabilities for one customer. He also notes that onsite time is part of the job. Palantir expects about a quarter of the week at the customer.
Why it is suddenly everywhere
Generative AI made the gap between a demo and a working system wider than ever. A model can answer beautifully in a browser and still fail on a company’s own PDFs, permissions and edge cases. The AI companies noticed first. eWeek, reporting on research by the Financial Times, wrote that postings for forward deployed engineers on Indeed rose more than 800% between January and September 2025, with OpenAI, Anthropic and Cohere all building teams of them.
The investor Andreessen Horowitz explained the logic in a piece called “Trading Margin for Moat”: enterprises want AI, but, in the author’s words, they are like a grandmother with a new iPhone who needs someone to set it up. Software companies are accepting lower margins to do that setup themselves, because the setup is what makes the product stick.
The cost of not doing it shows up in the failure rate. Gartner has predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, pointing to rising costs, unclear business value and weak risk controls. The forward deployed engineer is the industry’s answer to those three causes.
The gap the role closes in a Kuwaiti company
Most AI work in Kuwait does not fail on the model. It fails on everything around it. The invoices are scanned Arabic PDFs with handwritten notes. The customer history sits in an ERP that was customised ten years ago by someone who has since left. Approvals happen on WhatsApp. The person who really understands the process is a senior employee who has never been asked to write it down.
None of that appears in a proposal or a demo. It appears in the first week of sitting next to the team. A consultant can describe it in a report; a vendor can promise their product handles it. Someone still has to write the code that reads those PDFs, the integration that respects those permissions and the tests that prove the Arabic answers are right. That person is the forward deployed engineer.
This is also why I wrote that your team has to be able to do certain things before AI is worth buying. An engineer working inside the company is often the fastest way to find out which of those things are missing.
What the first six weeks look like
The shape I use is close to the one OpenAI and Palantir describe, adapted to how Kuwaiti companies actually work.
Weeks one and two: sit with the work. Watch the process being done by the people who do it, not the version in the procedure manual. Collect fifty to a hundred real examples: emails, forms, calls, invoices. Agree one measure of success in the business’s terms, such as hours saved, response time or errors caught, before writing any code.
Weeks three and four: build on the real systems. Connect to the actual ERP, inbox or database with the access a normal employee would have, nothing more. Build the narrowest version that does the job end to end on real data, in Arabic and English where the work is bilingual. Show it to the team every few days and change it based on what they say.
Weeks five and six: measure and hand over. Run it beside the existing process and compare results against the measure agreed in week one. Write down what it gets wrong and what a person must still check. Then hand the code, the prompts, the test set and the running costs to someone inside the company who will own it.
Arabic deserves its own line in that plan. A model that scores well in English benchmarks can still misread a Kuwaiti customer’s message, mix dialect and formal Arabic in one reply, or get a name, an area or a civil ID number wrong. The only reliable check is a test set built from your own Arabic examples, marked by someone in your team who knows what a correct answer looks like, and run again every time the prompt or the model changes.
At the end of six weeks you either have a working system with numbers behind it, or a clear, cheap reason to stop. Both are better than a pilot that runs for a year without anyone being able to say whether it works.
Forward deployed engineer, consultant or solutions engineer
The titles blur, so it helps to compare what each one actually hands you.
A consultant gives you a recommendation and leaves before it is built. A vendor’s solutions engineer builds a convincing proof of concept, usually on sample data, and the integration work comes back to you. A forward deployed engineer works on your systems, with your data, and stays until the result is measured and owned. The Pragmatic Engineer draws the same line: consultants make one-off recommendations, while forward deployed engineers stay with the customer and build what is missing.
None of these is wrong. A strategy question needs a consultant. A standard product with a standard integration may only need the vendor. The forward deployed model earns its cost when the work is specific to your company and nobody has built it before.
When a Kuwaiti company should bring one in
The signals are usually obvious once you look for them:
- A pilot that worked in the demo and has been “nearly ready” for months.
- An AI idea that depends on an old internal system that no vendor will touch.
- Arabic documents, Arabic speech or bilingual customers that off-the-shelf tools handle badly.
- No technical lead in the company who can judge what the vendors are saying.
The last one overlaps with what a fractional CTO does, and in practice the two roles often sit in the same person: deciding what should be built, then building the first version inside the business.
It is the wrong model when the problem is a standard one with a good product already on the market, or when the company is not willing to give an engineer access to real systems and real people. A forward deployed engineer kept at arm’s length is just an expensive consultant.
Why this is how I already work
I have spent three decades in business in Kuwait, more than twenty of them building web and digital products, over a hundred in total, including UTTER IN, AI Khazna and POPIN.ID. The pattern has never changed: the plan is never the hard part. The hard part is the week someone discovers the data does not look like the plan said it would.
So my AI consulting is not a report followed by a goodbye. It is working beside your team on your real systems: reading the Arabic documents, testing on your own calls and emails, and building the first working version until it is measured and someone inside the company owns it. The industry now has a name for that way of working. I am glad it does, because it makes the conversation with a buyer much shorter.
What to ask for in the agreement
Whoever you hire for this kind of work, a few terms protect you:
- The success measure written down before the build starts, in business terms.
- All code, prompts and configuration in your own accounts, not the supplier’s.
- The test set of real examples handed over, so you can check any future change.
- Running costs shown monthly, from the first week.
- A named person in your team who shadows the work and takes it over.
The handover deserves the same care as any supplier change; I have written about what a handover has to contain, and the same list applies to an AI system. If the work then grows into a product, the AI development side takes over from there.
Frequently asked questions
What does a forward deployed engineer actually do?
They work inside the client’s business, on its real systems and data, to turn a piece of software or an AI model into something that does a specific job there. They write code, talk to the people doing the work and stay until the result is measured.
Is a forward deployed engineer the same as a consultant?
No. A consultant recommends; a forward deployed engineer builds. The useful question is who writes code on your systems and who is still there when the first version breaks.
Does the engineer need to be onsite in Kuwait?
For part of the time, yes. The first two weeks especially need someone sitting with the team. After that, much of the build can be remote, with regular visits to test with the people who will use it.
How long should a first engagement run?
Around six weeks is enough to know whether one use case works on real data. If nobody can show a measured result by then, that is a reason to stop or change direction, not to extend.
What happens when the engineer leaves?
Nothing should break. The code, prompts, test set and costs are already in your accounts, and someone in your team has shadowed the work. If that is not true, the engagement was not finished.
The short version
The title is new; the idea is old. Software that has to fit a real business needs someone to fit it, inside that business, with their hands on the systems. If your AI plans keep stalling between the demo and the daily work, the missing piece is rarely a better model. It is usually an engineer sitting in the right room.