The FDE is an operating model, not a job title

Most organisations do not lack access to AI. They lack the ability to fit AI into real work.

The model can summarise a document. The demonstration can answer questions. The prototype can call an API. The harder work starts when the solution meets inconsistent spreadsheets, old systems, undocumented approvals, data restrictions, overloaded teams and the exceptions that experienced staff handle without ever writing them down.

The forward deployed engineer, usually shortened to FDE, works in that gap. The role combines software engineering, solution architecture, product judgement, business analysis and hands-on client delivery. An FDE stays close enough to the business to see how work actually happens, and is technical enough to turn what they see into reliable software.

This series treats forward deployment as an operating model, not a fashionable job title. Organisations call the people who do this work many things: solution architect, consulting engineer, customer engineer, applied AI engineer, technical lead, product engineer. The title matters less than the accountability:

The forward deployed team is accountable for turning local business reality into working, measurable and supportable software, then feeding reusable learning back into the platform.

The last clause is the one that gets forgotten. If every client receives an isolated custom build, forward deployment becomes expensive consulting. If every client is forced into the same generic product, the solution may never fit the work. The model only works when it balances local fit with reusable capability.

Where this series comes from

The role is most associated with Palantir, which calls its forward deployed engineers "Deltas", as opposed to "Devs" who build the core product, and says it pioneered the position of embedding engineers directly with customers. AI labs have since adopted it. OpenAI's current FDE listings say its FDEs "lead complex end-to-end deployments of frontier models in production alongside our most strategic customers", and Anthropic advertises FDE roles in several cities. Andreessen Horowitz called it "the hottest job in startups" in a June 2025 essay on why AI companies are trading margin for moat.

The practical starting point for this series is a podcast: Greg Isenberg's episode "FDE: The $1M/Year AI Job Explained", published on 20 July 2026, with Vasuman ("Vas") Moza, founder of Varick Agents, which builds custom AI implementations on top of companies' existing software. Moza describes the work in three stages: understand the business through an audit or sprint, build evaluations that turn unpredictable AI behaviour into evidence, and deploy into the business while supporting adoption. That spine runs through the series.

Two notes on reading it. First, it is a creator podcast, and both sides promote their own offers: the episode description links Isenberg's FDE "blueprint" sign-up page and Varick's 30-day FDE roadmap. Treat the advice as practitioners' views with commercial interests, not independent research. Second, the million-dollar figure in the title is the episode's headline and the guest's own claim, not a salary benchmark. Where this series disagrees with or narrows the podcast, it says so.

The eight parts:

1. The FDE is an operating model, not a job title (this part)
2. The process map is usually fiction: discovering how work really happens.
3. Where should intelligence live?: which steps belong to rules, AI, automation or people.
4. The demo is the beginning: the evidence between a prototype and production.
5. Build into the business you actually have: integrating with the installed estate.
6. Sell the discovery, not the fantasy: scoping and commercialising the work.
7. One hero is not a delivery model: the team structure behind the role.
8. Build the capability in 90 days: how a person or an organisation starts.

The gap between a platform and a business outcome

Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative.

Sandveld Foods is a fruit and vegetable processor and distributor headquartered in Paarl, with about 1,400 staff, three processing plants in the Western Cape, and roughly 900 suppliers ranging from large packaging firms to small growers. Its accounts payable team of 11 clerks handles about 9,000 supplier invoices a month. Roughly one in five has an exception.

A year earlier, Sandveld bought an "AI invoice processing" product licence. The demonstration was convincing: clean PDFs went in, structured data came out. Six months later, the clerks were still re-keying most invoices, because the invoices that mattered were not clean PDFs, the exceptions were handled by rules nobody had written down, and the product had never been connected to the way Sandveld actually approved anything.

Nothing about the model was wrong. What was missing was the work in between. Someone had to decide:

• which business problem is worth solving;
• how the process works today, including its exceptions;
• which data and systems are involved;
• where ordinary deterministic software is enough;
• where AI judgement adds value;
• where a person must remain accountable;
• how the solution will be integrated, evaluated and supported;
• whether the measured outcome justifies the cost and the risk.

That is the forward deployed mandate. When Sandveld tried again, it worked with Ironbark Digital, a Johannesburg software company with an accounts payable exceptions product and a practice of embedding small forward deployed pods with its clients. The rest of this series follows that engagement.

What is forward deployment?

Forward deployment places technical decision-making near the environment where the software has to work. "Near" can mean physically on site, embedded remotely in the client's team, or deeply connected through regular workshops, access to real workflows and direct collaboration with the people who do the work.

An FDE is there to shrink the distance between four things:

1. the problem leadership describes;
2. the work employees actually perform;
3. the behaviour of the technical system;
4. the outcome the business can measure.

OpenAI's listings describe roughly this: engineers who own technical delivery from prototype to stable production, build full-stack systems, embed with customer teams, guide adoption, make delivery trade-offs, contribute code, and turn what they learn in the field into reusable tools and patterns. That is broader than presales and closer to product delivery than traditional advisory work.

What an FDE is not

The boundaries matter, because an organisation can relabel an existing role without changing how delivery works at all.

The strongest delivery model does not replace these roles with one superhero. It builds a cross-functional team with a clear forward deployed lead. Part 7 comes back to this, because it is where most organisations go wrong.

The two-direction mandate

An FDE works in two directions at once.

Into the client. The team adapts the platform to the client's workflows, systems, data, constraints and risk appetite.

Back into the product. The team turns repeated field needs into reusable connectors, deployment patterns, product features, evaluation packs and operating playbooks.

At Sandveld, the clearest example came out of discovery. Experienced clerks were accepting price variances of up to 2% on fresh-produce lines, because the weight a grower invoices rarely matches the weight the plant records on arrival. The rule was applied hundreds of times a month and written nowhere (Part 2 tells that story). For Sandveld, the pod wrote it down and implemented it. For Ironbark, it became a configurable tolerance setting in the product, so the next food client starts with it instead of rediscovering it.

If the second direction is missing, the organisation accumulates client-specific code and knowledge. Every engagement starts again. Margins fall, support fragments, and the platform team cannot see which field problems deserve product investment.

When the model fits

Forward deployment is useful when:

• the product is powerful but needs configuration, integration or workflow redesign;
• the process contains significant judgement and exceptions;
• data lives across several systems;
• value depends on adoption and operational change;
• the path from demonstration to production is uncertain;
• field learning can improve a reusable platform.

It is less useful when:

• the product is standard, self-service and needs little integration;
• the requirement is a known implementation with mature patterns;
• the vendor cannot maintain the customisations it creates;
• the client expects unlimited bespoke development inside a fixed product price;
• the title is being used to disguise under-scoped consulting or support work.

Sandveld's accounts payable fits the first list on every line. A team rolling out a standard expense-claim app does not need an FDE; it needs a competent implementation partner.

The real source of value

Moza argues that access to model intelligence is becoming broadly available, so the advantage moves to deployment. The direction is credible. "Everyone has the same intelligence" is too absolute: access, model quality, cost, data, infrastructure, regulation and engineering capability still differ, and in South Africa regional availability and rand costs differ too. The durable conclusion is narrower:

Model access alone does not create operating advantage. Advantage appears when the organisation combines appropriate models with proprietary context, sound workflow design, dependable integration, evaluation, adoption and continuous improvement.

Sandveld's first attempt had model access. Its second attempt had the rest. Our series From Private Endpoint to Production Capability makes the same point from the platform side: the platform is not the product.

The lifecycle at a glance

The series follows one lifecycle. Each phase has an output and a decision gate, and any gate can end in a well-evidenced "stop".

Executive questions

1. Does the role own a business outcome, or only produce prototypes?
2. Can the person or team write and operate production code?
3. Do they have direct access to users and process owners?
4. How is client-specific learning turned into reusable capability?
5. Who owns the service when the embedded team leaves?
6. Is the engagement building a platform or accumulating custom projects?

The short version

It is an operating model. The title matters less than who owns the path from local reality to working, supported software.

Work in both directions. Into the client for fit, back into the product for reuse. Missing the second turns it into expensive consulting.

Know when it fits. Judgement-heavy, exception-rich, multi-system work needs it; standard self-service products do not.

Advantage is in deployment. Model access is necessary and nowhere near sufficient.

Next: Part 2, the process map is usually fiction. See every part on the series page.

How CloudNala can help

We help organisations decide whether a forward deployed approach fits their AI ambitions, and then run it: qualifying the opportunity, embedding with the people who do the work, and taking a bounded workflow from discovery to supported production with the evidence to show what it achieved. For product companies, we help design the feedback loop that turns field learning into reusable capability instead of a pile of client-specific code.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Opportunity Sprint or write to us at consult@cloudnala.co.za