If your pilot demos well and nobody uses it, this is for you. The same goes if security will not let it write to Salesforce. The usual cause is not the model. Nobody built the tool inside the work: the real data, the real exceptions, the identity it writes as, and the person who has to change how they do their day. That is the job a forward-deployed engineer is hired for, and McKinsey published an explainer on it this week. From AWS down, services firms now want to sell you one.
This is not for you if you are still choosing a first process. Start with the process, not the platform, and come back when one job has an owner.
What is a forward-deployed engineer?
An engineer who works inside your company's systems and data, building software alongside the people who will use it. McKinsey's explainer quotes Holger Hürtgen, who has done the job for 20 years: "You don't work in a lab. You work with the real problem."
The title comes from Palantir. Its CTO, Shyam Sankar, says he coined it in 2007, The Register reported this month. The idea was that engineers sit with the customer, not behind a wall.
The difference from a consultant is what is left when they go. In Hürtgen's words, an FDE has to "work in the system of a client and develop a product, so you leave behind the product." A consultant, in the older sense McKinsey's Martin Harrysson describes, is paid for a recommendation or a plan.
Why is everyone selling one now?
Because buyers started asking. US Google searches for "forward deployed engineer" went from 1,600 a month in March 2025 to 40,500 a month from June to September 2026.
US monthly Google searches for 'forward deployed engineer'
The large firms followed. According to The Register, AWS announced a dedicated FDE organisation with USD 1 billion behind it in June, and Microsoft answered in July with a USD 2.5 billion "Frontier Company". The cloud firm DoiT told the same paper it has worked this way since 2011 and renamed its practice FDE in late 2025.
Even McKinsey's own people are wary of the word. Hürtgen calls the term "maybe a bit of a buzzword", then gives the reason the work still matters: without someone tailoring the model to the problem, "You will see token spend going up, but you won't see any bottom-line impact." That is a stalled pilot, described exactly.
What goes wrong when it works?
The risk with a forward-deployed engineer is not that they fail. It is that they succeed, and only they can run what they built.
That is not our opinion alone. Gartner's March guidance, quoted by The Register, tells buyers to "beware of ill-conceived FDE engagements that can lead to a high degree of vendor dependency, security/data risk exposure, technical debt, and talent atrophy." Its warning on the last one: "Your internal team may become operators of a black box rather than architects." Forrester, in a June report, calls it the "bespoke trap", where "highly tailored solutions deepen vendor dependence and make future change costly."
So the question is not whether to bring in an engineer who works inside your systems. A stalled pilot usually needs one. The question is how you make sure you can do without them in month seven.
What five things should you do before you hire one?
Most of what makes a forward-deployed engagement work is done on your side, before anyone arrives. None of these five needs us or any other firm.
- 01Name one process and one owner. The owner is the person who can change how that process runs, not the sponsor who wants AI.
- 02Sit with the person who does the work for an hour, and write down every exception they handle that the pilot never saw.
- 03Write the job on one page: inputs, the write, the limit, who approves, what it must never do.
- 04Ask security now which identity an agent may write as, and what they need logged. Their answer shapes the build, so get it before week one.
- 05Pick the person on your side who sits with the engineer all week, and clear their diary. If nobody can, wait.
The last one decides most of the others. Gartner's "talent atrophy" is what happens when nobody on your side was in the room.
Which five questions go to any FDE team?
Our method for a first agent is called Spec, shadow, gate. Turned into questions, it covers the risks Gartner names. Then put these five to any firm, us included, before anyone gets access.
- 01The job: can I read it on one page before you build? Inputs, the write, the limit, who approves, and what it must never do.
- 02The shadow run: will it run beside my person and write nothing until I have compared its calls with theirs?
- 03The stop: does every write go live behind a person's approval, and can my team switch it off without calling you?
- 04The accounts: does it run in our org, our cloud and our logins, and write as a named identity we can audit, so nothing lives only on your side?
- 05The person: who on my team sits with your engineer for the week, so the knowledge stays here when you leave?
The first three answer "black box": your team can read the job, see every decision before it writes, and stop it. The fourth is the one your security team will ask first: whose identity the agent writes as, and where that is logged. The fifth answers talent atrophy, and it names who owns the exceptions after we leave: a person on your side, not ours. A "no" to any of them is the answer you were looking for.
What does the first week look like?
McKinsey's Harrysson describes the first phase as "sitting next to people performing a task", working out who makes decisions and which data matters, "because a lot of those things may not always be documented very well." We agree, and we write it down.
Our first build week is spent in your org, not in slides. Agentforce when the work already lives in Salesforce, a custom stack when it does not. The process picks, and the week writes down why. It produces the one-page job for one named process: what comes in, what the agent may write, the limit, who approves and what it must never do. It does not produce a finished agent. The shadow run comes next, then go-live behind a human gate, then a handover to the people who run it.
Here is the shape of what the shadow run shows you. A made-up example, not a client.
The gate loosens only where the shadow run earned it. If the pilot is already built and stuck, we start with the rescue week instead: read-only access, then a written call to finish it, cut it or rebuild it.
How do you make it work in your org?
McKinsey's people are blunt about where these engagements fail. "The more difficult part is the human aspect of it," Harrysson says, "sometimes even trickier than getting the actual technology to work." His example is a senior developer who tried agents after training, hit a problem, fixed the code by hand, and may not try again. Hürtgen's test for success is that "people who are supposed to use it like the solution and do use it."
How we would run it, in the order it happens:
- 01Your person leads. The engineer asks; the person who does the work points at the step that matters. The spec is written in their words.
- 02Keep it to one process. A second process waits until the first one is used every day.
- 03Let the shadow run build trust. Your people see the agent's calls next to their own before it writes anything, so nobody is asked to trust a demo.
- 04Count use, not demos. The measure is how many cases the agent handled this week and how many a person had to fix.
- 05Plan for your best expert to switch back. The most experienced person is the likeliest to fix it by hand, as in Harrysson's example. Give them the stop switch and the rule to change, not a request to be patient.
- 06Hand over before you are finished. Your person changes a rule while the engineer is still there to watch, so the first change after we leave is not the first change ever.
What do we put on the table?
The work is led by Shivanath, our founder, a Salesforce MVP Hall of Fame member who has put 200+ agents into production, with desks in the UAE, India and the US.
The assessment is free: a short read of the pilot and a written note. If you go ahead, the first build week is a fixed USD 4,050 (AED/SAR 14,900), credited in full when you sign the build within 60 days.
After go-live there is the Run plan, for teams with a named admin on their side: 8, 20 or 40 hours a month at AED/SAR 6,900, 15,900 or 30,900 (about USD 1,880, 4,330 or 8,415), excluding VAT. It is optional. The point of the first four questions is that you never need it to keep the agent running.
We do not publish client names or client figures. Ask us for the sample spec, and judge the week by it.
When are we the wrong answer?
When you want an engineer inside your team for a year, a forward-deployed engineer on payroll is the right hire, and we are not it. When the backlog is already clear and you just need hands, staff augmentation is simpler. And when you have not picked the first process, see the top of this page.
For the steps between a pilot and production in more detail, read the pilot-to-production guide. For how approvals and stops are recorded, see AI governance.
If you would rather have the first read done for you, send us the pilot. For the Gulf view of agents, see AI agents in the UAE, and for how the agent is built so it can be stopped, our architecture.
