Forward-deployed engineers are necessary now for early-stage AI companies because workflows are entirely new, but long-term companies should productize the workflows and stop relying on FDEs, otherwise they become glorified consulting firms.
Asha argues FDEs are being overused. They're necessary at early-stage AI companies because nobody knows the workflows yet—FDEs embed with customers to learn and pave them. But once the workflow is known, it must be productized; relying on FDEs long-term just produces a glorified consulting shop. ✦ AI generated
Asha · a16z Podcast · 2026-07-31 · original ↗
starts at this moment · 21:53
“maybe this is like a a spicier take of oh are application layer companies just for deployed companies that are kind of doing the last mile of work”
for deployed engineers are necessary or newly necessary for early stage AI companies because the workflows are new... with AI products nobody knows what the workflows are because nobody's used these things before so a for deployed engineer in this case is honestly just embedding with the customer to learn the workflow for the first time... uh but long term, I think they should just be building product... once you know what the workflow is, if you can productize it, you should productize it and then become the typical company with these scaling properties of a tech company. And if you can't do that, then you're just building a glorified consulting truck.
verbatim transcript · starts at 21:53
21:53is that for deployed engineers are necessary or newly necessary for early stage AI companies because the workflows are new, right? If you're building a SAS company 5 years ago, most SAS products are pretty well explored, right? like you roughly know what the user is trying to do and your job is maybe come with a slightly cleaner workflows but broadly you know what the user is trying to do
22:19with a design app or a CRM or something like that because those workflows have been explored with AI products nobody knows what the workflows are because nobody's used these things before so a for deployed engineer in this case is honestly just embedding with the customer to learn the workflow for the first time as the customer learns the workflow for the first time and they're kind you know, kind of paving the road
22:44like you they're kind of laying out the track as they see which way the train is going in a way. >> Uh but long term, I think they should just be building product, right? Like once you know what the workflow is, you should not be relying on four deployed engineers anymore because once you know what the workflow is, if you can productize it, you should productize it and then
23:04become, you know, typical company with these scaling properties of a tech company. >> Yeah. And if you can't do that, then you're just building a glorified consulting truck. >> Well, I'd love to dig into this more because I know when we started working together, probably almost exactly three years ago, and you guys landed on this idea, there were two things that were relatively contrarian that now feel kind
23:23of standard. The first was when you started an AI customer service, a lot of people were like, that's a G GPT rapper. And we talked a lot about like why that's not the case. And then the second thing you did was say like, hey, we actually want to do the work ourselves, like we don't want to just be a software platform. And now we have the term for