What Is a Forward Deployed Consultant (FDC)?

A company buys a product because it expects a result: fewer delays, faster claims, a sales team that answers in hours. Between the purchase and the result sits a lot of work nobody bought: deciding what the result means here, working out what should be built, proving it works on the customer's own data, and getting people to use it. The forward deployed consultant is the role created to own that gap.

A forward deployed consultant (FDC) is a consultant employed by a product company who works inside a customer's organisation until the product produces the result the customer bought it for. The title travels with a second one, the forward deployed engineer (FDE). Most of the confusion about the role is about where one ends and the other begins, and about how much an FDC builds.

Where "forward deployed" comes from

Forward-deployed comes from U.S. military jargon, and Palantir popularised the forward deployed engineer role, using the title for staff by 2009. A forward-deployed unit is stationed near the action instead of at headquarters; a forward deployed engineer sits with the customer instead of with the product team. The term and all the roles that carry it are on what does forward deployed mean.

The idea spread with AI. In 2026, Anthropic, OpenAI, Amazon Web Services, Microsoft and Google Cloud announced divisions built around forward-deployed engineering. Selling an AI product to a large organisation turned out to need someone on the inside to make it work, and the consultant version of the title followed.

What an FDC does

monday.com's posting describes its forward deployed consultant running discovery, advising on process changes before building, building workflows, training customers, and leaving documentation so customers can run and extend what was built. In order, that is an engagement with a beginning and an end:

The end matters as much as the start. An FDC who leaves behind a team that cannot run the product without them has built a dependency. The handoff, with documentation the customer can follow, is part of the job.

What an FDC builds

The common picture of a consultant is someone who advises and leaves the building to others. The postings for this role ask for more. monday.com's posting asks for hands-on build experience, solutions built with agents and vibe-coded applications, and knowing when a deterministic automation is the better answer. Flexport's posting asks its forward deployed consultant to write Python and SQL, prototype supply chain models, and partner with forward deployed engineers to turn those models into production workflows.

AI assistance is what makes that range realistic for one person. Describing a tool in plain language and getting working code back has lowered the cost of a first version for people who were never software engineers. Anthropic reported in July 2025 that its lawyers built phone tree systems with Claude Code and its marketers generated hundreds of ad variations. For an FDC, the same shift means a prototype can sit on the customer's own data within days instead of waiting for an engineering slot.

This site's author works as a forward deployed consultant on generative AI solutions, and puts it this way:

I see the forward deployed consultant as a problem solver with access to intelligence. With AI assistance, an FDC can do some things brilliantly: rapid prototyping, UI and UX, proofs of concept and workflow engineering, backed by a working knowledge of AI and ML primitives, the software development lifecycle and systems architecture.

The phrase that matters is "access to intelligence". The FDC is the person in the room who can turn a question into something that runs, using models and coding agents to cover ground that used to need a team. What they build is a proof: enough to show the idea works on real data, with real users, before anyone commits to building it properly.

What an FDC needs to know

Building fast is the easy half. The FDC's distinguishing skill is deciding what should be built before building it. With AI products the choices before the build have multiplied: which parts of the work follow fixed rules, whether the answer exists somewhere and only needs finding, where a model's judgement adds value, how much an agent may do on its own, and where a person must stay in charge.

That is why the knowledge an FDC needs is structural rather than encyclopaedic. They need to know the primitives well enough to choose between them: a model, retrieval, tool use, an agent or a workflow. They need enough of the software development lifecycle to know what a prototype still lacks before it can ship, and enough systems architecture to see where the new piece will sit among the customer's existing ones.

The author's working rule is that clear rules go to automation, information that has to be found goes to retrieval, judgement goes to a model or a bounded agent, and high-stakes decisions go to a person.

The stakes are checked first: a task can follow clear rules and still be too consequential to run unattended. How much an agent may decide on its own is bounded autonomy, and where a person must still approve is human-in-the-loop design.

FDC and FDE: depth of ownership

Both roles work inside the customer, both work in ambiguity, and both move a problem toward something usable. The author draws the line this way:

What separates the FDC from the FDE is depth of ownership: the engineer goes deeper into building and operating the system, and the consultant stays broader across the problem, the workflow, validation, governance and adoption. The consultant has to be technical enough to turn an idea into something testable, and close enough to the business to ask whether it is the right thing to build.

Flexport's posting draws the same line from the employer's side: the consultant prototypes the models, and the engineers turn them into production workflows.

The line moves. In a small or AI-native team one person may do both; in a large deployment they are separate hires with separate managers. What stays constant is that an FDE who builds a perfect integration nobody uses has not delivered, and neither has an FDC who proves an idea the customer's systems can never support. That is why the two are hired as a pair.

How it differs from a traditional consultant

A traditional engagement is often judged by its recommendation: the analysis, the roadmap, the deck. An FDC is employed by the company that makes the product, works inside the customer's organisation, and is judged by whether the product produces the result. Flexport's posting makes that concrete by asking its FDC to track hard-dollar savings. The deliverable is something that runs and has been tested on real work, and the recommendation comes with it.

How far the postings go

Two postings and one company's report are a small sample, and titles vary between employers. The postings examined here support the core of the author's view: an FDC builds, prototypes with code or configuration, chooses between automation and AI, and hands production engineering to an FDE. They are quieter on interface design and the software development lifecycle, which appear here as the author's view of what the role can do well. Read any FDC posting for what it asks you to build; the range differs more than the title suggests.

Where AI makes the role harder

With an AI product, what gets built is less predictable. An agent configured during the engagement can take actions nobody scripted, and a coding assistant can change more of a codebase than anyone asked for. The FDC then needs a clear agreement about what is being built, what must stay untouched, and how delivery will be proven, before anything is handed to the agent. Tools are appearing for exactly that: GoATee lists forward deployed consultants first among the people it is designed for. It is a spec and delivery control layer around coding assistants, built by this site's author.

Whether a deployment is ready for real use at all is from prompt to production.

What this changes

If you are hiring an FDC, ask what they will build in the first two weeks, what result they will be measured on, and how the customer will run the product after they leave. If you are one, the deliverable is a proof that runs, a decision about what to build properly, and a handoff. If you are weighing the role, it suits someone who likes the problem as much as the technology, can learn an unfamiliar system quickly, and is comfortable being judged on what actually changed.