What Is a Forward Deployed Engineer

I keep seeing the term forward deployed engineer everywhere on my feed, and I have a feeling most people scrolling past it don't actually know what it means, or how someone breaks into it. So I brought my friend Voss onto the podcast to lay it out clearly. Voss runs Veric Agents, a company that implements AI across some of the largest businesses in the world, and he agreed to share the full playbook: what the role actually is, why it pays what it pays, and how you could build your way into one in 30 days.

This is for people who want the job title. It's also for anyone who wants to understand how to actually get value out of AI inside their own business, because the thinking behind this role is the same thinking that separates companies who get real ROI from AI and companies who burn through a budget and have nothing to show for it.

Why This Role Exists Right Now

Here's the starting fact Voss opened with: every company can now buy intelligence. A frontier model ships practically every week. Kimi, GPT, Claude, take your pick, and if you talk to fifty different enterprise clients you'll find they're all running some version of the same stack: Claude Code, Codex, Cursor, GitHub Copilot. The tools are converging.

If everyone has access to the same intelligence, intelligence stops being the advantage. The advantage moves to deployment: where you use it, how you use it, and why. That's the entire job of a forward deployed engineer. It's taking something general, a frontier model, and applying it specifically to one company's actual processes, in a way that fits how that business really runs. Every company is structured differently, even when they're doing the same thing. Two companies both doing accounts payable might have a ten-step process and a thirty-step process, one running Salesforce and Gong and Chili Piper, the other running HubSpot and Apollo and Clay. The edge belongs to whoever builds the best bridge between the general intelligence and that specific mess.

Where the Term Came From

Palantir popularized this. Voss has a window into it firsthand, he lived in New York for a few years and had several friends working as Palantir FDEs. Palantir built a software stack, an ontology, full of connectors and data links that let enterprises pipe their information into one unified interface. Their forward deployed engineers would then go sit on-site, whether that's a company, the military, or a government agency, learn the actual workflows, and build the dashboards and agents that solved the specific problem in front of them.

What Palantir really invented was consulting for the software age. The platform mattered less than how customizable it was, and the FDE was the person who did the customizing, in person, per client. The bet Voss and others are making now is that AI demands this a hundred times more than the data era did, because every company is going to need agents customized to how it actually works, not a generic dashboard.

The Three Stages of the Job

Voss broke the role into three stages, and the first one is the part people who live deep in tech tend to skip past.

Understanding the business reality. This means figuring out how work actually happens, not how it's documented. Voss gave a simple example that's more complicated than it sounds: an email arrives. That sounds like a clean trigger, until you find out it arrives from forty different senders, none formatted the same way, some data buried in a PDF, some in a screenshot, some in a forwarded thread with no consistent subject line. Half the process is exceptions. And usually, the real logic for handling those exceptions lives in one person's head, not in any document. If you ask that person what the first step of their job is, they'll say an email arrives, and they won't think to mention the ten judgment calls they make every time one actually does.

This is why FDEs go on-site as often as they do. It's not just about information access, it's about the relationship. Sit with someone for a full eight-hour shift instead of a scheduled one-hour interview, and you'll watch the undocumented parts of the job play out in real time. Voss compared it to how McKinsey consultants will sit with miners at an actual mine site rather than just interviewing them in an office.

FDE judgment. Once you understand the work, the second stage is deciding where intelligence actually belongs. Early in the AI wave, a lot of teams defaulted to throwing AI at everything, what Voss calls token maxing. That's part of why the MIT stat that 95% of generative AI pilots fail exists. The better approach: out of a ten-step workflow, maybe only three steps genuinely need model judgment, something non-deterministic like categorizing a lead. The rest can run on if-then logic and API calls. Deciding which is which, and being confident enough in that call to defend it, is where the FDE's technical background actually earns its keep.

Building the system. The third stage varies enormously by company. At Palantir, some FDEs barely write code, they're mostly configuring workflows inside the existing ontology, maybe some SQL. At other companies you're writing production code end to end. Either way, you need to genuinely understand the software, because when something breaks in production, it's your problem to diagnose and fix.

What This Actually Pays

I asked Voss directly what someone doing this in a city like New York could realistically earn. His answer: a lot. Base salaries starting around $150,000 with meaningful equity, and he's personally seen total comp go as high as a million dollars a year. He wasn't joking. This is, in his words, the hottest role in technology right now, both because of how hard it is to hire for and how much demand is chasing a small pool of people who can actually do it.

Why It's Rare: Art and Science

The reason it pays that well is that it requires two skill sets that rarely show up in the same person. Consultants from McKinsey, BCG, or Bain are typically excellent at the business side: workflows, incentives, risk, internal politics, getting people to actually adopt something new. Software engineers are typically excellent at the technical side: models, APIs, evals, guardrails, reliability. An FDE has to be the best version of both, not an average of the two. As I put it to Voss, it's like understanding art and understanding science, and being able to speak both fluently. Most people who are strong in one are only decent in the other. The overlap is small, which is exactly why the role is scarce and why it's compensated the way it is.

Selling the Audit First

One thing Voss was firm about: every engagement should start with a paid audit, not a jump straight to building. The audit is where you map out a department's actual workflows in full detail, the steps, the exceptions, the handoffs, and then hand back a prioritized map of what's worth automating and what isn't. Done well, it's worth more to a company than the fee they paid for it, and it builds the trust you need before you ever touch their systems. Voss's team originally called it an audit, and found the word created resistance, people hear audit and think of a tax audit. Rebranding it as a sprint solved that instantly. Small detail, real impact on how willing people are to say yes.

Once you're building, the same principle carries through: don't force a company to rip out systems they've spent years and millions of dollars implementing. Build on top of what they already have. If a client just spent two years migrating to NetSuite, telling them to abandon it is a losing pitch. Making NetSuite work better, connected to their Salesforce, their SAP, their Concur, is the pitch that gets a yes.

There's also a quieter dynamic worth naming: the person you're pitching to inside the company is thinking about their own career, whether this makes them look good or exposes them to risk. Help them get promoted by driving measurable value cost-effectively, and you become an easy yes. Threaten the systems they already championed, and you become a risk they can't afford to take on. Voss's advice for your first clients specifically: do the audit for free or cheap, prove value, and only start charging real rates once you have a track record. Your first few clients teach you more than you're worth to them, and that's fine.

The 30-Day Plan

If Voss had to compress everything he learned building his company into a month, here's how he'd spend it.

Week one: build one agent that completes a real loop. Pick a real back-office workflow, finance, HR, procurement, sales, get as granular as possible, and build something that can actually execute it, not just respond well to a good prompt. It should work even if you prompt it like an idiot. That means working through agent looping, tool usage, guardrails, context and memory, and an audit trail. The audit trail matters more than it sounds like it should: if you can't show a client exactly what the agent did and why, they will never trust it.

Week two: turn the demo into a system that can recover. This is where the engineering gets real. Defined JSON schemas instead of free-form text, schema validation, and serious attention to failure modes. Voss's framing stuck with me: there's only one way for something to go right and a thousand ways for it to go wrong. Build for the unhappy paths, not just the happy one, and the agent becomes worth something.

Week three: make it measurable and economically viable. Add retry logic, build a golden dataset for evals, and start testing whether cheaper models can handle parts of the task instead of defaulting to the most expensive frontier model available. Then measure the result against exactly three things: revenue uplift, risk mitigation, and cost savings. Those are the only three buckets that actually matter to a business.

Week four: defend the system like an FDE. Rehearse explaining what you built from two angles, as the engineer who made the architecture decisions, and as the VP who has to justify the investment. Then go pitch it to real businesses. They'll tell you, bluntly, whether you got the economics right or built the wrong thing. That feedback is worth more at this stage than almost anything else you could do.

By day 30, you're not certified and you don't have the title yet. But you have evidence, a real system with tools, guardrails, memory, and a defensible audit trail, and evidence is what gets you the first real shot.

Where This Is Headed

Voss made a point that stuck with me: on evals for non-deterministic tasks, like judging something as subjective as a presentation, you lean on as much historical data as you can gather to build a golden dataset, and then you bake in continuous human feedback, because even a good dataset needs to keep improving. The same logic applies to picking a model. Don't try to be model-agnostic on day one. Pick one ecosystem, whether that's OpenAI's agent building platform, Claude's agent SDK, or something else, and get genuinely good at it first. Model-agnosticism is a strength you earn later, once you understand what you're actually optimizing for.

This role didn't exist five years ago because the underlying capability didn't exist five years ago. Now there's real intelligence available on tap, and trillions of dollars are going to move as companies figure out how to actually use it. Nobody teaches this in school yet, and Voss doesn't expect that to change anytime soon. The people getting ahead right now are the ones treating it like Voss did: stop reading about it, and go build the thing.