Here's the key correction to the usual framing: Bavor explicitly says you can sell without a forward-deployed team. So an FDE isn't a universal requirement or a thing every enterprise buyer demands. It's better understood as an important catalyst — a high-touch deployment motion that fits certain enterprise AI contexts. This piece explains what that motion actually is, based on what Bavor said, and then, clearly labeled, our own analysis of why it's powerful but hard to scale.
A note on sources
Two kinds of content follow, and I'll keep them separate.
Transcript-derived means Bavor said it in the episode: Sierra borrowing from Palantir's forward-deployed approach, starting a forward-deployed team in early 2024, customers using that help in different ways, the vendor driving while the customer rides in the passenger seat for the first version, applications informing the platform, and leaders personally reading Black Friday and Cyber Monday conversations.
LensUp analysis means our editorial reasoning about why this motion works and where it breaks down. It is not Bavor's claim and not from the transcript. I'll label it as such. Any customer or revenue figures I attribute to Bavor or the episode, and I keep them off to the side rather than build on them.
Where the FDE idea comes from
The forward-deployed engineer role traces to Palantir, where engineers embedded on-site to work a customer's data into something usable. Bavor describes Sierra borrowing elements of that approach and standing up a forward-deployed team in early 2024.
The point of the role is simple. An agent that answers questions is a demo. An agent allowed to take actions on your systems is a production commitment. Closing that gap is customer-specific work, and it's largely model-agnostic — it depends on your data and your rules, not on which base model is running underneath.
Vendor drives, customer rides shotgun
Bavor's framing of the first deployment is worth borrowing directly: the vendor drives, and the customer is in the passenger seat for the first version. The vendor builds v1 while the customer's own people watch, understand, and correct it as it takes shape.
He also notes that customers use this help in different ways — it's not one fixed template. Some lean on the forward-deployed team heavily; others less so. That variance is the whole reason Bavor can say you can sell without the team: the motion is a catalyst for some accounts, not a gate for all of them.
Applications inform the platform
The other thing Bavor emphasizes is that the applications inform the platform. Work done deploying real agents for real customers feeds back into what the underlying product becomes. Delivery isn't just a cost center bolted onto a product — it's a source of discovery about what the platform needs to do.
Today's version of this: if you're building anything customer-deployed, keep a running log of what your delivery people hand-build per account. The patterns that repeat are your next product features. That's the mechanism Bavor is pointing at.
The Black Friday anecdote — craftsmanship, not a spec
One concrete story: leaders at Sierra personally read Black Friday and Cyber Monday conversations. Bavor offers this as a craftsmanship-and-trust example — the people responsible for the product actually looking at what it said to customers during the highest-stakes window of the year.
I want to be careful here. This is not evidence of a formal certification pipeline or a specified eval process. It's a story about caring enough to read the transcripts by hand when the stakes are high. Read it as trust and craftsmanship, which is how Bavor framed it — not as proof of a checklist you can copy.
Why intelligence isn't the missing ingredient
Start from the naive question. If the base model is already smart enough to reason well, why does deployment still take hands-on work per customer?
The answer follows in one step. Intelligence isn't what's missing. What's missing is specific to each company: your data doesn't live in clean tables an agent can read, and your rules about what an agent may do — refunds, cancellations, escalations — are yours, not the model's. A smarter model helps with reasoning. It does nothing to know your schema or your liability. That's why this work is customer-specific and model-agnostic, and why it survives across model generations.
This much is a reasonable reading of Bavor's own emphasis: the hard part is fitting the agent to a particular customer's world.
LensUp analysis: powerful, but hard to scale down
Everything below this line is our analysis, not Bavor's claim.
The FDE motion is powerful precisely because it removes the buyer's implementation risk. The vendor drives, owns v1, and gets the agent live — that's real value for a large enterprise that can pay for high-touch delivery.
The tension is scale. High-touch delivery carries a human cost per account. At large enterprise deal sizes, that cost is easy to absorb. Push the same hands-on motion down to small deals and the economics get harder, because you're carrying delivery labor against much less revenue. This is our reasoning, not a figure from the episode — and it's exactly why Bavor's point that you can sell without the team matters. If the motion were mandatory at every price point, it would be a scaling problem for the whole category.
If the episode cites customer statistics — for example a share of the Fortune 50, or customer revenue figures — treat those as Bavor's or the episode's claims about Sierra specifically, not as proof the high-touch motion scales down to smaller buyers. Large-enterprise logos can pay for white-glove delivery. That says little about a self-serve price point.
What compounds
Also our analysis: the durable asset from all this delivery work isn't the headcount, it's the artifacts. This lines up with Bavor's own point that applications inform the platform. The connectors, the templates, the deployment patterns — if the product team absorbs them, the marginal cost of the next account drops. If it doesn't, you're running a services firm with a model attached.
So the honest distinction for anyone copying the motion: copy the artifacts, not the bodies. The compounding lever is turning delivery work into product, which is exactly the loop Bavor describes as applications informing the platform.
FAQ
Is a forward-deployed engineer required to deploy enterprise AI?
No. Per Bavor, you can sell without a forward-deployed team. It's a high-touch deployment motion for certain contexts, not a universal requirement.
Who invented the forward-deployed engineer role?
The role is associated with Palantir's forward-deployed approach. Bavor describes Sierra borrowing elements of it and starting its own forward-deployed team in early 2024.
Does a smarter model remove the need for this work?
Our analysis: no, because the work is about your data and your rules, which are customer-specific and model-agnostic. A better model raises reasoning quality but doesn't know your schema or your liability.
Is the Black Friday transcript reading a formal eval process?
No. Bavor presents it as a craftsmanship-and-trust anecdote, not a certification pipeline.
Next steps: three things to do tonight
① Map your ontology by hand. Open your ticket DB or CRM and write down, in plain English, the object model an agent would need — what's an entity, what links to what. The friction you hit is the customer-specific work.
② List your action space. Write down every action you'd let an agent take on its own, and for each, what it affects and what should trigger a human. If the list is hard to finish, that's why acting agents need setup.
③ Log what delivery hand-builds. Start a running list of anything a person builds per account. The repeating patterns are your platform features — the "applications inform the platform" loop, in practice.
One real question to sit with: on your side of the table, is high-touch delivery cost falling as your artifact library grows, or is delivery still your ceiling? That's the disagreement worth having.