What I Learned Interviewing Forward Deployed AI Engineers

qw
vc
mshm
Trending AI Topics
October 14, 2026
Three beams of light converging into one glowing focal point, cinematic TAG style in deep blue

Interviews with candidates for the Forward Deployed AI Engineer role reveal a consistent pattern: business insight, technical execution, and AI expertise rarely come together in one person. Handing out a ChatGPT license buys access to a model, not the three skills that make an AI implementation actually work.

Summary

 

  • Three skills rarely sit in one person: business insight, technical execution, and AI expertise.
  • A ChatGPT license gives access to a model, not an implementation.
  • Candidates mostly fail on exception handling, logging, and human-in-the-loop design.
  • Assessing AI expertise means testing all three layers at the same time.
  • We work embedded in production, not advising from the sidelines.

 

Interviews with candidates for the Forward Deployed AI Engineer role reveal a consistent pattern: business insight, technical execution, and AI expertise rarely come together in one person. Handing out a ChatGPT license buys access to a model, not the three skills that make an AI implementation actually work.

 

 

Why I started having these conversations

 

Over the past year I have spoken with dozens of candidates for the role of Forward Deployed AI Engineer. The full term is Forward Deployed Engineer (FDE) with AI specialisation: someone who builds alongside the client in production, rather than advising from the sidelines. The term originates from the military and was popularised around 2009 by Palantir (Wikipedia).

 

The trigger for these conversations is always the same pattern. A company hands out ChatGPT licenses to the team, a few people get excited, and something happens. Only the time saved stays with those few people. The process itself doesn't change, and leadership isn't sure who they should have hired to make that happen.

 

If you don't know the role: we wrote extensively before about what a Forward Deployed AI Engineer actually does. This piece isn't about that job description. It's about what I learned from actually talking to people who say they can fill that role, and why few of them really can.

 

What struck me after the first ten conversations wasn't the technology. Almost everyone could get a language model talking. Where it consistently broke down was the same every time: as soon as I pushed on a concrete business process, a production incident, or the question of when not to use AI, the conversation stalled or turned vague.

 

That pattern was consistent enough that I started writing it down. Not as a complaint about the job market, but as a vocabulary. If you know which three layers you're looking for, you can at least ask targeted questions instead of hoping "AI experience" on a resume means enough.

 

This piece contains no names and no identifiable candidates. Where I give examples, they describe patterns I saw repeated across multiple people, not one specific conversation.

 

 

The three layers that almost never sit in one person

 

What stands out after dozens of conversations is that three skills almost never come together in one person: business insight, technical execution, and AI expertise. Each layer is missing in its own recognisable way.

 

Most candidates are strong in one or two layers. A strong developer without business insight builds a technically beautiful system that solves the wrong problem. A strong process analyst without technical execution delivers a good plan that nobody builds. Only when all three layers come together does anything change structurally.

 

 

Diagram with three circles: business insight, technical execution and AI expertise, overlapping only partially
The three layers that rarely sit in one person.

 

 

Layer 1: being able to question the process

 

Whoever can't get to the bottom of the business process builds the wrong thing perfectly. That's not a marketing line, it's the pattern I run into most.

 

In a conversation I always ask about a process the candidate investigated before. Someone who just repeats the manager's version of events hasn't done the work. Someone who can explain where practice diverged from the official process, and why, has.

 

  • Missing: the candidate takes the manager's first answer as the whole process, then builds something technically correct and commercially useless.
  • Present: the candidate asks just as many questions to the person doing the work as to the manager, and recognises where the official process diverges from how the work actually happens.

 

Layer 2: being able to build in production

 

This is the difference between a demo and something that still works on Monday. A demo runs on a cleaned-up example case. Production gets the messy input of a real working week.

 

Most candidates drop out here, and it's also the layer where we spend the most time in our own build work. A working system recognises when something goes wrong, records what happened, and hands control back to a human at the right points instead of plowing ahead on its own.

 

Anthropic describes this as the core difference between a proof of concept and a working system: agents need extensive testing in a sandboxed environment, clear boundaries, and a human watching at the right points (Anthropic, 2024).

 

 

 

Matte 3D objects representing a safety net and a glowing checkpoint, symbolising exception handling in production
A system that keeps working catches its own errors.

 

 

Layer 3: knowing when AI isn't the answer

 

The candidates who reach for a model for everything drop out hardest here. Not every question is a prompting problem.

 

This is also the layer companies themselves underestimate most. You don't want someone who wants to push AI into everything, you want someone who says just as easily: this process is still better off as a fixed rule, or this stays better off as human work.

 

IBM points to exactly this risk: autonomous AI systems make decisions without fixed human oversight, and that is risky once the stakes are high. That's why IBM argues for controlled testing environments and people who oversee what an AI system does (IBM, 2025).

 

  • Missing: a question that doesn't belong with a language model, like "is this legally allowed" or "is this figure accurate enough for the accountant", still gets an AI answer.
  • Present: the candidate recognises when a fixed rule, a human check, or another piece of software is a better solution than a model, and says so even when it's a less exciting answer.

 

 

Why a ChatGPT license doesn't close this gap

 

A license gives you access to a model. It doesn't add any of the three layers above. That's why "we have AI now" and "AI is delivering results now" are two different sentences.

 

A standalone proof of concept proves that something can be done. It doesn't prove that someone can make it work in your systems, with your data, on a Monday morning with a supplier outage.

 

The problem, moreover, isn't that your team isn't looking. According to Eurostat, lack of relevant expertise was the most-cited reason for EU enterprises not to use AI in 2025: 70.9 percent of the companies that had considered it named that as the reason (Eurostat, 2025). The market tells you that one AI consultant is the answer, while you're actually looking for three different things.

 

That also explains why two companies with the same license end up so differently. One company hires someone who masters all three layers for a single process, and sees that process change structurally within a few weeks. The other company buys more licenses, and gets the same result: a few enthusiastic users, no change in the process itself.

 

 

How to assess someone on these three layers

 

These are the questions I ask in a conversation, mapped exactly onto the three layers in this piece. No trick questions, just the questions where the answer shows whether someone can actually do it.

 

Pay less attention to the answer itself and more to how someone hesitates. The strong candidates regularly said "I don't know that yet, I'd want to find out first." The weak candidates had a confident answer ready for every question, immediately.

 

Questions per layer

 

  • Business insight: "Describe a process you recently investigated. What did the manager say, and what turned out to be different once you spoke to the people doing the work?"
  • Technical execution: "What happens in your system when the input isn't what you expected? Show me how you log and catch that."
  • AI expertise: "Give an example of a situation where you deliberately did NOT use AI, and why."

 

 

Grid of identical tiles with one differing tile highlighted, symbolising selecting the right candidate
Most candidates look alike, until you push further.

 

 

The same test applies to regulation. The EU AI Act classifies AI applications by risk, and requires human oversight exactly at the high-risk points (European Commission, 2026). Ask yourself the same question a regulator would: where in this process does a human need to keep watching, and has the candidate already thought about that.

 

You don't have to find this triangle in one person yourself. With a Fractional Chief AI Officer, we work embedded in your team, building in your own production environment, and leave the knowledge behind in your organisation.

 

That's also why we never split these three layers across one person on a project. An engagement always gets the combination of business insight, technical execution, and AI expertise, so you're never dependent on one individual's judgment of what works and what doesn't.

 

 

Frequently asked questions

 

What is a Forward Deployed AI Engineer?

 

A Forward Deployed AI Engineer works embedded with a client and builds AI solutions that run directly in the production environment, instead of advising remotely. The term originally comes from Palantir. You can read more about the role in our earlier blog on what a Forward Deployed AI Engineer actually does.

 

Why doesn't a ChatGPT license for everyone deliver results?

 

A license gives you access to a model, not implementation in your processes and systems. Without someone who gets to the bottom of the process, builds it to be technically robust, and knows when AI isn't the solution, the time saved stays with a few enthusiastic individual users.

 

Should I hire an AI specialist on staff or bring one in?

 

That depends on how much AI implementation you need on a structural basis. Most SMEs don't need a full-time hire, but they do need someone who masters all three layers from this piece. A fractional or interim arrangement gives you that expertise without a permanent commitment.

 

How do you recognise whether someone can actually deliver AI implementations?

 

Test all three layers at once: can the person get to the bottom of a business process, can they build something that keeps working in production including exception handling and logging, and do they recognise when AI isn't the right solution. Pay less attention to confident answers and more to healthy hesitation. See the list of questions in this piece for the exact questions we ask ourselves.

 

What does it cost to bring in AI expertise?

 

That varies by organisation and by process, so we won't name a fixed amount here. The price depends mainly on scope: having one process built embedded is different from an ongoing Fractional Chief AI Officer role. Check the Fractional Chief AI Officer page for the setup.

 

Can't my own IT team do this?

 

Your IT team can often partly cover layer 2, the technical execution, especially if there's already development experience in house. Business insight into the specific process and AI expertise are usually missing there, simply because that isn't their day-to-day work and most IT teams don't have time to build that up structurally. That's why embedded, temporary reinforcement tends to work better than building everything in-house.

 

What's the difference between an AI consultant and an embedded engineer?

 

A consultant advises from the sidelines and delivers a report or a roadmap. An embedded engineer builds alongside you in your systems, in production, and leaves behind a working result instead of just advice.

 

How long does it take before an AI implementation delivers results?

 

That depends mainly on how messy the process and the data already are before you start, so we won't name a fixed timeline here. What we can say: a process that's already well documented and lives in one system moves noticeably faster than a process fragmented across five separate apps.

 

 

Want AI expertise in your organisation, without doing the search yourself?

 

You don't have to find this triangle in one person yourself. We work embedded with your team, build in your own production environment, and leave the knowledge behind in your organisation.

 

View Fractional Chief AI Officer

 

Read more articles

From insight to impact.
We translate AI oportunities into practical profit for your business.
z
z
z
z
i
i
z
z