What is a forward deployed engineer? A buyer's guide
Where the forward deployed engineer role came from, how it compares with software, consultants, and a full-time hire, and what to ask before you sign.
King & Company
In short
A forward deployed engineer is an engineer who works inside one customer's business and builds what that customer needs, using the customer's own systems and documents. The role began at Palantir and has been adopted by AI vendors to get their products into use. For a firm buying AI work, it fits when the problem is still loosely defined and depends on the firm's own material, and the things to check are who owns the output, where the work runs, and whether your people can run it afterward.
A forward deployed engineer is a software engineer who works inside one customer's business, on that customer's systems and documents, and builds what that customer needs. Whether that is the right way to buy AI work depends on who employs the engineer and who owns what gets built, and the job title alone tells you neither.
This guide is written for a firm owner or operating partner weighing four options: buy a software product, hire a strategy consultant, hire a full-time AI person, or bring in an embedded engineer. We are a forward deployed engineering firm, so we have a stake in the answer, and we have tried to say plainly where the model is the wrong choice.
What a forward deployed engineer is
The plain description is an engineer who sits with the customer instead of with the product team. They read the real files, watch how the work gets done, and build against it.
An Anthropic job posting for the role, which has since closed and is archived on an investor's job board, gives a fair picture of what the job looks like at an AI company. It describes an engineer who "embeds directly with our most strategic customers," and its responsibilities include building "production applications with Claude models" within customer systems and the instruction to "Deliver technical artifacts for customers like MCP servers, sub-agents, and agent skills that will be used in production workflows."
Two things in that description matter to a buyer. The work happens inside the customer's systems, and the output is a set of working artifacts.
Where the role came from
Gergely Orosz traced the history in The Pragmatic Engineer in August 2025. The role was created at Palantir in the early 2010s, where it was originally named "Delta," and up until around 2016 Palantir had more forward deployed engineers than conventional software engineers.
The same article quotes Palantir's own explanation of the difference. A product developer's focus is "one capability, many customers," while a Delta's focus is "one customer, many capabilities." That one line is still the clearest definition available. A product engineer builds a feature for everyone. A forward deployed engineer takes one customer's problem and builds whatever it requires.
Why AI brought the role back
AI models are general, and a firm's work is specific. The distance between the two is filled with the firm's own material: its past deliverables, its templates, its naming habits, the things a senior person corrects in a junior's draft.
Anthropic's Economic Index report from September 2025 makes the point from usage data. It says that deploying AI for complex tasks "might be constrained more by access to information than on underlying model capabilities," and that businesses "may need to restructure how they organize and maintain the information that frontier systems rely on."
That is work someone has to do inside the business, which is why AI vendors started hiring for it. The Pragmatic Engineer article quotes an OpenAI job advert that describes the role as embedding with customers to "co-develop solutions to tackle real problems in often undefined or evolving problem spaces."
Smaller firms report less AI use than larger ones. A Census Bureau article on its Business Trends and Outlook Survey, published in May 2026, reported that 37% of firms with at least 250 employees used AI in their business operations, against less than 20% of firms with four or fewer employees. The same article says that over the period from December 2025 to May 2026, AI use increased among firms with at least 20 employees and did not change significantly among firms with fewer than 20.
Four ways to buy AI work, compared
| Option | What you receive | Where it works well | Where it falls short |
|---|---|---|---|
| Software product | A tool built for many customers, with a subscription | A common task that a mature product already handles | Work that depends on your own templates, documents, and habits |
| Strategy consultant | An assessment, a roadmap, recommendations | Deciding where to invest when leadership disagrees or the options are unclear | Someone else still has to build, and the recommendations were not tested against live work |
| Full-time AI hire | An employee who builds for you indefinitely | A steady queue of work and a manager who can direct and review an engineer | The first year, when the queue is unproven and nobody at the firm can judge the output |
| Embedded engineer | Working systems built against your real work, and people trained to run them | A problem that is not yet well defined and depends on your own material | Tasks a product already does well, or firms with no one who can give the work an hour a week |
The rows describe the typical case, and individual firms in each category vary. The table is most useful as a list of what to ask each kind of provider.
When an embedded engineer is the right choice, and when it is not
The model fits when you cannot yet write the specification. A brokerage team that wants a lease abstract in its own format, checked the way its senior broker checks it, cannot hand that to a vendor as a requirements document. Someone has to sit with a stack of past abstracts and the person who signed off on them, and work it out. Our guide on how to build an AI workflow describes that process in detail.
It is the wrong choice when a mature product already does the job. If your need is meeting transcription, or a feature your accounting or CRM platform already ships, buy it. Paying an engineer to rebuild a commodity is a poor use of money, and a good firm will tell you so in the first conversation.
It is also the wrong choice if nobody on your side can take part. An embedded engineer needs the person who owns the work to correct drafts every week. Without that, the engineer is guessing, and you are back to buying a product built for the average customer.
Private equity sponsors weighing this model across several companies will find that case in how to repeat one AI build across a private equity portfolio.
Vendor forward deployed engineers versus an independent firm
At a product company, a forward deployed engineer exists to get that company's product adopted. There is nothing hidden about this. Andreessen Horowitz published the argument in June 2025 under the title "Trading Margin for Moat". It says that "enterprises buying AI are like your grandma getting an iPhone: they want to use it, but they need you to set it up," and advises startups to do that implementation work so they can become the system of work. Once workflows are established, the article says, these companies "possess 'moats' that allow them to increase prices."
That is advice to vendors about their own interests, and it is sound advice for them. A buyer should read it as a description of the trade. A vendor's engineer may do excellent work, and that work is built around the vendor's product.
An independent firm has no product to place, which changes what you should test. Ask who owns the output and whether the work runs in your own environment. If the answer to either is unclear, the independence is not doing much for you.
What an engagement looks like week to week
We can only describe our own practice here, and it should be read as how King & Company works and not as an industry norm.
We start by getting access to where the work lives and reading before the first session. After that we meet for one hour a week. Each week we bring a working draft of one workflow, built against the client's own documents. The person who owns that work corrects it, we tune it, and they leave the session using it. Most of the effort happens on our side between sessions.
Over eight to twelve weeks that adds up to a named set of working systems, a team that has been trained inside the build, and a plan for what comes next. For a brokerage team the named set might include lease abstraction, a first pass at a broker opinion of value, and a survey workbook. For a professional services firm it might be proposal drafting from a precedent library.
Questions to ask before you sign
These apply to any firm using the forward deployed label, including ours.
- Is the person who scopes the work the one who builds it? If a senior person sells and a junior team delivers, the understanding gained in scoping is lost at the handoff.
- Do you work in our environment, and does our data stay there? Ask which AI workspace the work runs in, whose account it is, and what leaves it. Our guide to secure AI workflows for confidential client data covers what to settle, and your own counsel or compliance lead should confirm the answer.
- Do we own every workflow, skill, and document, with no platform fee? Get this in the contract.
- Is training part of the build? A system only one outside engineer understands is a dependency.
- Is there a review step in what you deliver? Each workflow should say who checks the output and what they check. We cover the design in the human review step in an AI workflow.
- Can our own people read and change what was built? Ask to see an example of a finished deliverable and its documentation.
What you should own when it ends
At the end of an engagement you should be able to list what you have. That list should include the workflows and skills themselves, in your own workspace; written documentation for each one; the review step and its owner; and named people on your team who have run each system on live work.
If the engineer left tomorrow, the systems should keep running and your people should be able to adjust them. You can then decide whether to keep the firm on to extend the work, hire someone full time now that the queue is visible, or run it yourselves. If you want to talk through which of the four options fits your firm, get in touch.
Common questions
What does a forward deployed engineer do?
They work inside one customer's business, read the real documents and systems, and build software or AI workflows for that customer's specific work. An Anthropic job posting for the role described working within customer systems and delivering MCP servers, sub-agents, and agent skills for production workflows.
How is a forward deployed engineer different from a consultant?
A strategy consultant usually delivers findings and recommendations, and someone else does the building. A forward deployed engineer delivers working systems, built against the firm's real work. The useful test is to ask what you will be able to open and run on the day the engagement ends.
Is forward deployed engineering only for large enterprises?
The vendor version often is. An Anthropic job posting for the role, for example, described embedding with its most strategic customers. An independent firm can do the same kind of work for a smaller firm, including one with no engineer on staff.
Should I hire a full-time AI engineer or bring in an embedded one?
A full-time hire makes sense once there is a steady queue of work and someone at the firm who can direct and review an engineer. Before that point, an embedded engineer lets you build the first set of systems and find out how much ongoing work there really is.
Who owns what a forward deployed engineer builds?
It depends on the contract, so ask before signing. A vendor's engineer builds on the vendor's product, so ask what you keep if the subscription ends. With King & Company the client owns every workflow, skill, and document, with no platform fee.