There is a role that enterprise software has always needed but rarely named: the person who sits with a customer, understands their problem from first principles, and builds the solution without handing it off four times along the way.

In AI, that role finally has a name. Forward deployed engineer. And I do it.

What "forward deployed" actually means

The term comes from Palantir, where forward deployed engineers (FDEs) were embedded directly with customers rather than working behind glass in a product org. The premise was simple: the gap between what a customer says they need and what they actually need is enormous, and the only way to close it is presence. You learn by being there.

In enterprise AI, this gap is wider than in any previous wave of software. Most organisations know they want to use AI. Very few know how to turn that into a working application. The failure mode is not bad technology. It is a requirements vacuum. Teams greenlight a project, then discover they never agreed on what the output should look like, how it fits into existing workflows, or what good even means for their use case.

A forward deployed AI engineer exists to prevent that failure.

What I actually do

I collapse the traditional project pipeline into one continuous, accountable loop. On any given engagement I am doing requirements gathering with stakeholders, running design thinking sessions to surface the real problem underneath the stated problem, designing the system architecture, and then writing and shipping the application.

A design thinking workshop board with Empathise, Define, Ideate, and Prototype phases showing colour-coded sticky notes and how problems are mapped before code is written
A design thinking workshop board with Empathise, Define, Ideate, and Prototype phases showing colour-coded sticky notes and how problems are mapped before code is written

This is not a generalist pitch. It is a deliberate structural choice. When the person who gathered the requirements is also the person designing the system and writing the code, there is no translation loss. The application reflects what the customer actually said, not a three-step game of telephone between a BA, a solutions architect, and a dev team.

The skills that matter in this model are not just technical. Deep listening. Knowing when a customer's stated requirement is actually a symptom, and being willing to say so. Then: application architecture, AI integration, API design, cloud infrastructure, evaluation, and iteration. Both halves are load-bearing.

The kinds of problems I work on

Enterprise AI application problems tend to cluster around a few patterns: building internal tools that give non-technical teams AI capability without a developer in the loop, adding AI functionality to existing products where the hard part is not the AI but everything around it, and replacing slow manual knowledge work with applications that are fast, auditable, and actually trusted by the people using them.

A production enterprise AI knowledge search application showing AI-generated answers with confidence scoring, source attribution, and document results in a dark-mode interface
A production enterprise AI knowledge search application showing AI-generated answers with confidence scoring, source attribution, and document results in a dark-mode interface

The organisations I work with are usually past the should we explore AI stage. They have done a proof of concept. Something worked well enough to create expectations, but not well enough to ship. Or they shipped something and it is underperforming. That is where a forward deployed AI engineer earns the engagement: in the translation from this demo was impressive to this is running in production and delivering measurable value.

Why the architecture has to be right

Enterprise AI application system architecture diagram showing the client layer, API gateway, services, AI pipeline with RAG and retrieval, evaluation layer, and data stores
Enterprise AI application system architecture diagram showing the client layer, API gateway, services, AI pipeline with RAG and retrieval, evaluation layer, and data stores

AI applications fail in ways traditional software does not. A broken integration returns an error. A poorly designed AI application returns a confident, plausible, wrong answer and nobody catches it until trust is already damaged. Building well requires someone close enough to the domain and the end users to know the difference throughout development, not just at kickoff and delivery.

Forward deployment is not just a staffing model. It is a quality mechanism. Proximity to the customer's context is how you build enterprise AI applications that actually work.

If you are evaluating this kind of engagement

The right fit is an organisation that has real AI ambition and does not want to staff and manage a full internal team to get there, or that has an internal team but needs a specialist embedded alongside them to move faster and with more depth.

If you are trying to move from idea to working application without losing the thread between requirements and reality, that is the problem a forward deployed AI engineer is built to solve.

Continue the Discussion

If you are evaluating a forward deployed AI engineering model for your team, I can help you assess fit, scope, and delivery approach. Book a CTO consultation.

You can also connect with me on LinkedIn for a deeper engagement discussion.