Forward deployed engineers: map the process first

"Become a $1M/yr FDE." That's the title of a recent episode of The Startup Ideas Podcast. FDE stands for forward deployed engineer. It's a good title. The data tells a smaller story.

Demand is real. Job postings for forward deployed engineers on Indeed grew by 800% between January and September 2025. Pay is strong, not magic. One industry analysis puts the median base salary at about USD 174,000, with total pay at AI labs between USD 350,000 and 550,000. The episode's own maths for the million is a share of the value: deliver USD 10M, keep 10%.

So skip the salary. The useful part is the method behind it. It explains why most AI projects stall. And it applies to a 60-person firm as much as to a US enterprise.

The guest is Vasuman Moza of Varick Agents, a firm that embeds forward deployed engineers in large companies and rebuilds their processes around AI agents. A forward deployed engineer is an engineer who works inside the customer's business, not at the vendor's desk.

Host Greg Isenberg pushes for concrete examples, and Moza brings numbers from client work. The details are altered. Read the numbers as direction, not as a benchmark.

What you'll learn

• Why the documented process is never the real one
• The four buckets every process step belongs in
• Why agents belong inside your CRM or ERP, not next to it
• What a first project delivers, in numbers

An agent is only as good as the process map under it

That's the thesis. Moza's version is shorter: don't apply AI. You can't put it on like a coat of paint. If nobody has written down how the work really flows, the agent automates a guess.

So the map comes first and the agent second. The rest of this article is the proof, from the origin of the problem to the numbers.

Why do most AI pilots stall?

Most AI pilots stall because they automate the documented process, and the documented process is not the real one. The real one lives in people's heads, in exceptions and in loops nobody drew. An agent built on the official version fails at the first exception.

The pattern is well measured. MIT's GenAI Divide report found that about 95% of corporate generative AI pilots fail to deliver returns. The authors blame the gap between the tools and real workflows, not the quality of the models. In a Celonis survey of 1,620 business leaders, including Germany, Austria and Switzerland, 89% said AI must understand how their processes run to deliver results.

Moza's first example makes it concrete. A public software company with USD 5bn in revenue had its quote process documented in 7 tidy steps. His team ran process mining on the CRM.

The real process had 20 steps and 7 loops. 61% of requests went back to the start. Legal sent 12% back. In 30% of cases a new quote had to go through approval again.

None of that was on paper. In every company he sees, someone has been there for 20 years and just handles it. I call this fragmented context: product knows one part, sales another, and every agent starts from zero. It's the same reason a CRM funnel is not your real sales process.

It also explains why so many firms here are stuck at step one. In Germany, 57% of companies now use AI, yet 9 in 10 say they're only at the beginning.

How a forward deployed engineer maps a process

I count five steps in his method. Most of the work happens before anyone builds an agent.

1. Interview the people. Start with one department. Ask why each step exists, who really decides, which step is theatre and how often exceptions happen.
2. Mine the systems of record. His team runs process-mining agents on the CRM or ERP for three to four weeks. Which records come in, who corrects them, where do they go next?
3. Read what exists. Old documentation, chat threads, spreadsheets. Sometimes outdated, sometimes good.
4. Sort every step into one of four buckets. Delete it. Turn it into plain code, when it's a simple if-then rule. Give it to an agent, when it needs judgement and you have history to learn from. Or keep it as a human decision, when a mistake is expensive.
5. Baseline before you build. Cycle time, exception rate, cost per case. Without a baseline you can't prove anything later.

No single source is enough. A large company has ten years of CRM history. A small one has mostly heads. The interviews without the data give you opinions, and the data without the interviews gives you half the picture.

Step 4 is where the value sits. Moza cites Michael Hammer, whose 1990 article in Harvard Business Review told companies to redesign their processes instead of automating them.

The point he takes from Hammer: speed up each of 20 steps and the process may not get faster, because the time sits between the steps. That's the handover between teams. No agent fixes a handover that shouldn't exist.

The split is less agent-heavy than the hype suggests. A write-up of Varick's method describes a typical redesign: of 8 steps, 4 get automated, 3 keep a human in the loop and 1 stays manual.

His timeline is short. 4 weeks for the audit and the first proofs of concept. 4 weeks to build. Then a before-and-after review 3 and 6 months later. The finished map does a second job too: it's the brief for the agent, the same way a good ticket is a context container for agents.

Do I have to replace my CRM or ERP for AI agents?

No. The agents that work run inside the systems you already have. They read and write in your CRM or ERP, and they ask for approval in the chat tool your team already uses. A migration pitch loses the room and delays the result by years.

Moza is blunt on this. Clients tell him about ERP moves that took several years and several million dollars, in one case around USD 10M. Nobody wants a second round. So his agents mine the CRM and act in the CRM, and a human approval is a message in Slack. Staff need no retraining, because nothing on their screen changes.

That makes the system of record the real tool. It holds the history an agent needs to judge a case. What you want from it is context, not just data.

Two more choices from the episode. First, he separates chat assistants from background agents. A background agent does the same job every time without being asked and only pings you when it needs a decision. His estimate: an assistant gives people 10 to 20% faster output, a background agent 70 to 80%.

Second, most steps don't need the newest model. He benchmarks every workflow against several models and picks per workflow.

One point for DACH readers. He has seen no demand for on-premise hardware at his clients, banks and pharma firms included. His firm routes the models through the large cloud platforms, with terms that rule out training and data retention.

Do you need to hire a forward deployed engineer?

Probably not at first. A forward deployed engineer combines three skills: understanding how the work gets done, shipping production code with audit and security, and knowing what a model can be trusted with. You can grow that inside your team by starting with one process.

Moza says people who are strong in all three are rare. Most have one or two. A fourth skill sits on top: explaining it all to senior leadership.

• The process. How do Salesforce, NetSuite or Dynamics really work, and what should the function look like?
• The code. Agents that call those systems, with an audit trail, governance and security. That's agentic engineering discipline, not a demo.
• The AI layer. Which model for which step, evals to test it, and a rollback when an agent takes a wrong action.

His starter exercise takes four days and uses your own life as the test case. List every app that holds your stuff, and which one wins when two disagree. Pick 20 things you did last week.

Write one of them down step by step, with every exception. Sort the steps into the four buckets. He'd give the same playbook to a company that wants to grow its own FDEs.

My addition: then do it for one real process in one team. One process, one owner.

What does process re-engineering deliver in numbers?

In the accounts payable case from the episode, 17 process steps became 7. Cycle time fell from 24 days to 6. The cost per invoice dropped from USD 31 to USD 6. The share of invoices that pass without an exception rose from 18% to 87%.

Read that last number again. Before the project, 82% of invoices took an exception route. That's not a missing agent. That's a broken process.

Moza says it himself: this gain is process re-engineering, and it's not all about agents. The mapping took two to three weeks of interviews and process mining.

Nobody designs such a process. It grows. In another example, five portfolio companies on the same ERP ran the same kind of process in 12, 9, 15, 18 and 13 steps.

One caveat. These are a vendor's own numbers, from single clients, with details changed. So check them against a published case.

Moza points to Thrive Holdings, which buys accounting and IT services firms and puts engineers inside them. It owns more than 70 businesses. Its tax agents have processed over 7,000 returns at 98% accuracy and cut preparation time by more than 30%. Different firm, same pattern: engineers inside the business, process first.

Where this works, where it doesn't, and the trap

✅ What shines. High-volume, rule-heavy flows with a system of record and years of history: invoices, quote approvals, reconciliations. There's a clear owner, a measurable baseline and a visible result within months.

❌ What doesn't shine. Small firms with nothing written down and no system of record. There's no history to mine, so the interviews carry everything. Personal assistant agents don't shine either. Moza sees no governance yet for letting them run company processes.

⚠️ Warning. Keep people on approvals and payments. An agent that pays every invoice that looks legitimate is a gift to fraudsters.

And discount the margin maths of AI roll-ups. A Stanford and BetterUp study found that 40% of employees receive AI output that looks polished but lacks substance. The cost: about USD 186 per person per month. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027. The reasons: rising costs, unclear value or weak risk controls.

Back to the million. Nobody pays it for knowing agents. If anyone pays it, they pay for knowing the process.

The four buckets are a plain description of how I think teams should work. I call it Get Multiplayer: humans set goals, decide and approve. Agents prepare and do the repeatable work. Shared goals and shared context keep them working together.

The process map is that shared context, written down. AI doesn't fix an unclear process. It makes it faster and louder.

If you want one build like this per issue, subscribe to The Science of GTM newsletter.