A forward deployed engineer is a software engineer who works inside your company's daily operations instead of taking requests from the outside. The job is to find the work your people still do by hand, build software that does it, and put that software live in the systems you already run.
Most of what you will read about the role is written for engineers who want the job, or by an AI vendor selling its own engineers to large enterprises. This post is for the other side of the table: a COO or CEO at a company that does not sell software, trying to decide whether this kind of help fits. The Gnar Company provides forward deployed engineers as a small team of U.S.-based senior engineers, not a single hire, so we will be specific about what we have seen work and where it does not fit.
What is a forward deployed engineer?#
A forward deployed engineer is an engineer who sits inside a company's real work, with its real systems and data, and is judged on whether a problem gets solved. The title was popularized by Palantir, which used it for staff by 2009. Wikipedia defines the role more narrowly, as an engineer who works for a product company and helps put that product to work at a client. This post uses the broader sense: an engineer embedded in a company's systems and data, building software alongside the people who will use it.
The easiest way to see the role is next to the three things buyers usually confuse it with.
| Kind of help | Who decides what gets built | What you have at the end | Best when |
|---|---|---|---|
| Forward deployed engineers | They work it out with your people | Software running in your systems | You know AI should help but not where |
| Staff augmentation | You do | More hands on your existing plan | You already have a clear plan and a backlog |
| AI consultant | They recommend, you decide | A plan, usually built by someone else | You need a strategy and have builders ready |
| An AI vendor's own forward deployed engineers | Mostly the vendor's product | That vendor's tools, set up for you | You have already chosen the vendor |
McKinsey put the difference well in its October explainer. A consultant was traditionally paid to recommend. A forward deployed engineer has to work in the client's own systems and leave behind a working product, though one of the three McKinsey leaders interviewed says the two roles are merging. That last part is the test. Ask whether the team that writes the plan can also build it in your systems.
Why is everyone suddenly selling forward deployed engineers?#
Because AI tools are easy to buy and hard to put to work, and the big AI companies have noticed. In 2026, Anthropic and OpenAI each set up forward deployed groups, AWS put $1 billion into a new forward deployed unit, and Microsoft committed $2.5 billion and 6,000 employees to its own. They are aimed mostly at large enterprise customers.
The figures come from AWS's announcement and CNBC's reporting. AWS said its $1 billion Forward Deployed Engineering organization will embed engineers inside customer teams to build and deploy AI. Two days later, CNBC reported that Microsoft would embed 6,000 employees with clients in a new company called Microsoft Frontier Co., and that Anthropic and OpenAI had set up their own forward deployed groups in May.
Our read of those announcements: a license does not change how a business runs. Someone has to sit with the people who do the work, find the steps worth changing, and wire the AI into the systems they already use. We covered what happens after the licenses are bought in Everyone Has a License. That's Not AI Adoption.
For a mid-market distributor, manufacturer or insurer, those units are built mostly for large enterprises, and each one is run by a company that sells its own platform.
Whose forward deployed engineer should it be?#
A vendor's forward deployed engineer is there to get you using that vendor's product well. An independent team starts from your problem and picks whichever tool fits it. Both can work. The question to settle first is whether your problem has already been chosen to fit the product, or the product will be chosen to fit the problem.
Three questions sort it out fast:
- Is the model already chosen? If yes, the vendor's team knows that model best. If no, you want someone who will tell you which one fits each task.
- Is the problem already defined? If it is, a vendor's team can start building on it. If you do not have one yet, ask any team how it will find the first one with you.
- Who is the work for after they leave? The vendor wants its product used. You want the work done and your team able to run it.
Gnar's own position is on the record: we are a Claude Select Services Partner and use Claude by default, and if another AI fits a task better, we use that one. Tell any provider you talk to that you expect the same answer.
When does a company that doesn't sell software need one?#
You need one when you have paid for AI and nothing in daily operations has changed. The usual signs are licenses few people open, test versions that never go live, people retyping the same data between systems, and a board asking for an AI plan that nobody inside has the time or the skills to write.
Use this as a checklist. The more of these are true, the stronger the case.
- The board wants AI results and there is no plan. Someone has been asked to "find AI use cases" on top of a full-time job.
- You pay for AI tools few people use. The licenses renew every year. Usage reports stay flat.
- AI test versions never go live. A demo worked on one laptop, then stalled when it needed to touch the ERP.
- People retype the same data all day. Orders come in by email and someone types every line into the ERP. Prices live in spreadsheets and get keyed in by hand.
- Your data lives in many tools that do not agree. Two reports from two systems give two different numbers, and only a few people know which field is right.
- Your own engineers are fully booked, or you have none. The people who could build this are keeping the current systems running.
The fourth item is the easiest one to spot. On Gnar's own forward deployed engineering page, the first example is typing emailed orders into an ERP. Nobody thinks of it as a project.
When you do not need one#
You do not need forward deployed engineers for a normal software rollout with a clear scope, or when nobody inside owns the process that would change. In that last case, forward deployed work produces software that nobody adopts.
If your own team has the capacity and the direction, you do not need us. We will tell you that on the call. Be suspicious of any provider who never says it.
Here is a simple decision rule.
| Your situation | What to buy instead |
|---|---|
| Clear plan, backlog written, not enough engineers | Staff augmentation |
| A packaged tool that already does the job | The tool, plus its normal setup help |
| You need a strategy and have builders ready | A short strategy engagement |
| No owner inside for the process | Fix ownership first, then come back |
| You know AI should help and not where, and nobody can build it | Forward deployed engineers |
An AI tool that reads order emails changes the job of the person who used to type them. If nobody with authority over that job is in the room, the tool will be built, tested and quietly ignored.
What does a forward deployed engagement look like?#
A good forward deployed engagement starts with a round of interviews with your own team. The team talks to the people who do the work and writes down how each task really gets done. Every idea is scored on what it saves and what it costs, and the top one gets built inside your systems. The people who will use it sign off before it goes live.
Here is how Gnar runs it, step by step.
- See how the work gets done. This is Compass, which runs 6 to 8 weeks at a fixed price. We interview your leaders and the people doing the work, and write down how each task gets done today.
- Rank every idea. Each task is scored on what it saves, what it costs to build, and whether your data is ready.
- Scope the first build. You end Compass with the first build scoped at a fixed price. Building is a separate decision, made later, with us or anyone else.
- Build the top task first. If you go ahead, we build it, test it and switch it on. The AI reads from your ERP and other systems and writes back only in the ways you allow, with a record of every action it takes.
- Hand it over, or build it together. Either we hand it over finished and your team runs it, or two to four of your people work next to ours and learn as we go. Everything we build belongs to you, code included.
That fourth step is where AI test versions usually stall. A demo on a laptop does not need permissions, an audit trail or a person to approve what it does. A tool your order desk relies on needs all three.
What it looked like at Counter Culture Coffee#
Counter Culture Coffee knew it wanted AI and did not know where to start. In an AI strategy and roadmap engagement, Gnar held 15 or more interviews, mapped every system around its NetSuite ERP, and found 79 AI and automation opportunities. Each one was scored on the same five measures, and the roadmap shows $1.5M in potential savings across the top 10 initiatives.
The five scoring measures in the case study were financial return, operational efficiency, how hard it would be to build, data readiness and cultural readiness. Counter Culture ran on NetSuite, Shopify and Zoho, with spreadsheets doing much of the supporting work.
Two details in the case study are worth more to a buyer than the savings figure.
First, the process tested its own guesses. Coffee buying looked like a market-timing opportunity at the start. A full year of contract data showed the team was already handling that well, so the recommendation changed to a single, live view of coffee contracts, importers and warehouse stock. A team that only looks for places to put AI would have missed that.
Second, the work was sequenced so people inside could own it. The roadmap ended with 34 projects ready to start and 8 already underway, led by five internal champions. That is what you want at the end of the first phase: named owners for the first projects.
How do embedded engineers work with your own team?#
Embedded engineers should report into your team through a named person. At Vermont Mutual, a senior Gnar engineer joined as the lead React engineer through a named product manager, with the role written down before day one. There were weekly one-on-ones with the project manager and monthly check-ins with our Head of Client Service.
The Vermont Mutual engagement was an embedded engineering engagement, not an AI project and not a forward deployed one. It was a rebuild of the insurer's quote application for its brokers. It shows one narrow thing: how an outside engineer fits inside a team that already exists.
It also started with a decision about which framework to use. Vermont Mutual was leaning toward one front-end framework. We compared three of them on complexity, learning curve, how strong each one's tools and community are, and one question most comparisons skip: which one makes it easiest to hire and keep engineers. The client's own prep work, detailed user flows and screen designs, gave our engineer real screens to build from.
The software was not the only result that lasted. The engineering team kept an agile way of working that it now runs itself. James Wong, Director of Product Management at Vermont Mutual, put it this way: "They've been able to integrate with our team. We don't view them as a third-party at all." That is the bar to hold any embedded engineer to.
What should you ask before you hire forward deployed engineers?#
Ask who owns what gets built, what the AI is allowed to see and change, and what your team can run after the engineers leave. A good provider answers all three in writing before work starts. Then ask how the first phase is priced, and who on your side signs off before anything goes live.
Here is the full list to take into a first call.
- Who owns the code and where does it live? The answer should be you, in your own accounts.
- What will the AI be able to see and do? You should decide that one system at a time. For example, look up an order without seeing prices, or fill in an ERP entry that waits for a person to approve it.
- Is there a record of every action it takes? If the AI changes something in your ERP, your team should be able to see what, when and why.
- Which AI model, and who picked it? Ask whether they would recommend a different one if it fit better.
- How is the first phase priced? A fixed price for the first phase means you know the cost before work starts. Open-ended hourly work at this stage leaves the risk with you.
- Who on our side signs off? The people who will use the tool should approve it before it goes live.
- What happens when you leave? You want written instructions, a trained owner, and code your team can change.
- Who exactly is on the team? Senior engineers, named, and where they are based.
Ask the provider to describe a project where they told the client not to build something. If they cannot name one, they will build whatever you ask for, and that is not what you are paying a forward deployed team to do.
