The other half doesn’t end. Delivery days change. Regions get added and dropped. Approval thresholds move. Pricing tiers get restructured. Suppliers get replaced, exceptions become policies, policies become exceptions. Every project I’ve worked on, across every industry, has the same property: the business keeps moving after the build is done, and the system keeps acting on the version of the business that existed the day it shipped.

Context is a live thing. It is not something you collect once and store. And it raises two questions that rarely make it into a project budget. Technically, how does an agent’s knowledge get updated and, more importantly, invalidated? And operationally, who makes that call, and through what interface?

To answer either, you have to start with why the model can’t just handle this itself.

Working memory is not memory

The context window gets described as the model’s memory so often that it’s worth being precise about what it actually is. The context window is the sequence of tokens the model can attend over in a single call. That’s all. Everything the model “knows” about your task, beyond what’s baked into its weights, lives in that sequence. When the call ends, it’s gone. The weights don’t update from talking to you. Nothing persists.

So the context window isn’t memory. It’s working memory, and it comes with three constraints that shape everything downstream.

The first is cost. Attention, in its standard form, works by letting every token look at every other token, which means the compute grows quadratically with sequence length. Frontier models increasingly interleave sparse and sliding-window variants, but in practice the scaling remains effectively quadratic. Double the context, quadruple the attention work. Inference engineering softens this with the KV cache: once a token’s keys and values are computed, they don’t change, so the runtime stores them and each new token only computes its own contribution and attends against the cache. That’s why inference has two distinct phases. Prefill processes your whole prompt in one parallel pass and determines how long you wait for the first token. Decode generates one token at a time against the cache and determines tokens per second. The cache itself is enormous, scaling with layers times heads times sequence length, which makes long-context serving as much a GPU memory problem as a compute problem. This is why context is priced the way it is, and why “just put everything in the context” is not a free architecture decision. It’s a metered one.

The second constraint is degradation. Even within the window, the model doesn’t use everything equally. Retrieval quality is empirically strongest at the start and end of the context and sags in the middle, and that positional effect has held across every model generation since it was first measured. There’s a second effect on top of it, now usually called context rot, where accuracy declines as the input grows even when the evidence sits in a favourable position. Stuff a hundred documents into a long window and you have not given the model a hundred documents. You’ve given it a well-lit beginning, a well-lit end, and a dim warehouse in between.

The third constraint is the one that matters most for this essay: no persistence. Whatever you load into the window evaporates when the session ends. A deployment that has to hold knowledge across weeks, months, and personnel changes gets nothing from the window itself. Cross-session continuity is not a model feature. It has to be engineered, outside the model, in the harness.

What actually gets bolted on

In practice, agent memory is a hierarchy of systems wrapped around the model, and each layer answers a different question.

The innermost layer is the in-context scratchpad: the running trajectory of the current task. It grows with every step, and because the model re-reads the entire trajectory on every turn, it gets compacted as it grows. Older turns get summarised, recent ones stay verbatim. Compaction is a craft in itself, because a summary that drops a load-bearing detail poisons every later decision that would have needed it.

Outside the window sits long-term memory, and it splits naturally into two kinds of store, because two kinds of knowledge behave differently.

Episodic memory is what happened. Events, decisions, outcomes, each with a timestamp. This is the time-series layer: traces and logs of the agent’s own behaviour and of the business it operates in. Which orders were processed, what was decided about the mismatched invoice in April, how the exception was resolved. Episodic memory answers “what did we do last time this happened?”

Semantic memory is what’s true. Entities, rules, procedures, the SOPs. Which regions we deliver to, what the approval threshold is, how a valid purchase order is structured. Semantic memory answers “what are the rules right now?” It’s the layer that most directly encodes the operational logic extracted during the build, and it’s the layer this whole essay is about.

At each step, retrieval pulls the relevant slice of both stores into the working window. And below all of it sits durable task state, the plain record of what’s been processed and what’s pending, which belongs in a database rather than in any context, because it has to survive crashes, restarts, and model upgrades.

None of this is exotic. Storage and retrieval are, at this point, solved-ish problems. The part that isn’t solved is the part that makes the whole thing safe to rely on.

Invalidation is the hard part

Here is the failure mode that should worry you more than hallucination. The approval threshold changes in March. The semantic store still says the old number. In June, the agent retrieves that rule, with full confidence and a clean provenance trail, and acts on it. Nothing in the system flags a problem, because from the system’s point of view there isn’t one. Retrieval worked perfectly. It retrieved the truth as of last year.

Stale memory retrieved with confidence is worse than no memory. No memory makes the agent ask. Stale memory makes it certain.

The engineering answer is truth maintenance, and it has three parts. First, every memory carries a timestamp and a source, so any retrieved fact can be traced to when it was true and where it came from. Second, contradiction triggers re-verification rather than silent preference. When a fresh observation disagrees with a stored rule, the system must not quietly pick one. The disagreement is the signal, and the correct behaviour is to surface it. Third, process-type memories get expiry dates. A rule about how approvals work is not a fact about the world; it’s a fact about an organisation, and organisations change. TTLs and scheduled re-validation force the question “is this still true?” onto a calendar instead of leaving it to luck.

All three mechanisms are buildable today, and parts of them are already shipped. Temporal knowledge graph memory stores, the current research direction for agent memory, attach validity intervals to every fact and invalidate the old edge when a new one contradicts it. But watch how they resolve the conflict: they prefer the newest information. That is a recency heuristic, not a truth decision, and it is exactly the silent preference the mechanism is supposed to avoid, automated. Which exposes what all three mechanisms have in common: every one of them ends in a question that the system cannot answer for itself. Is this still true? The timestamps tell you the rule is fourteen months old. The contradiction detector tells you the last three observations disagree with it. Neither can tell you which version is correct now. That call belongs to a person.

The world moved and the agent never heard about it. More slow deployment rot traces back to that than to any model limitation I can name.

The update flows in two directions

So the question stops being technical and becomes organisational: who owns the agent’s knowledge after the engineers leave?

The flow everyone plans for runs downward. The business changes something, and somebody updates the system. This is the flow that gets a paragraph in the handover document and then quietly dies, because the person who changes the delivery schedule and the person who can edit the agent’s rules are rarely the same person, and the path between them is exactly the kind of undocumented process the agent was supposed to eliminate.

The second flow runs upward, and it’s the one deployments rarely design for. It’s also the more interesting one. An agent that operates inside a process all day is in a privileged position to notice that the process has drifted. It keeps seeing orders from a region the rules say doesn’t exist. It keeps watching a human override the same threshold. The contradiction machinery from the previous section isn’t just a safety mechanism. It makes the agent a sensor for change. The agent can be the first thing in the organisation to notice that the world moved, provided there’s somewhere for that observation to go.

Both flows converge on the same requirement: a named person on the customer side with the standing authority to confirm changes to what the agent believes. And which person that is matters more than most deployments admit. The instinct is to give the role to whoever can technically operate the system, an admin, an analyst, someone from IT. But that person confirms changes to rules they don’t live inside. They can check that the edit is well formed. They cannot check that it’s true.

The person who can verify truth is the one who holds the knowledge, the operator who plans the deliveries, approves the invoices, works the exceptions. That person is rarely technical, and in most organisations they are the last person anyone would hand system access to. Which is exactly backwards. Confirming a change to the agent’s beliefs is a judgment about the business, not about the system, so the role has to be optimised for the knowledge holder, and everything about how the change is exposed to them has to bend to that choice. If confirming a rule requires understanding the rule engine, the wrong person will end up doing the confirming, and the deployment is back to the gap it started with. In every deployment, the agent’s knowledge either has an owner who can tell true from stale, or it drifts, and drift is the default.

The interface question

Which leaves the practical question I keep turning over: what does the owner actually touch? If the right owner is a non-technical operator, the interface stops being a detail and becomes the design constraint.

My deployments so far have used structured controls, mostly tables. Rules as rows, thresholds as fields. Structured data has real virtues for this job. It can be validated before it’s accepted, diffed so a change is visible as a change, timestamped per row, and edited by a non-engineer without the risk of quietly breaking something three paragraphs away. Documents are the opposite trade. They capture nuance and exceptions that tables flatten, but they can contradict themselves, they’re hard to invalidate selectively, and an edit in prose has no natural diff.

For a while I treated this as a choice between formats. I now think that’s the wrong frame, because it assumes the human edits the storage directly. The design I keep arriving at instead splits the layers. The interface is natural language. The storage is structured. The approval is the gate between them.

It works the same in both directions. Downward: the operator tells the agent, in plain words, that deliveries no longer go out on Fridays. The agent drafts the corresponding rule change, shows the diff against the current rule, and asks for confirmation. Upward: the agent notices the standing contradiction, packages it the same way, proposed rule, evidence, diff, and asks the same question. In neither case does anyone hand-edit a table, and in neither case does an unstructured note become live behaviour on its own. The table remains the single source of truth. The conversation is just how you write to it, and the confirmation is what makes the write legal.

I want to be honest that this is a design direction, not a pattern I can point to at scale. There are open problems inside it. How the agent should behave between noticing a contradiction and receiving a ruling. How to stop an approval queue from becoming the new bottleneck. How to keep the evidence attached to the rule so that next year’s owner can see why it says what it says. I don’t have finished answers. I have a strong opinion about the shape of the answer, which is that the human approves changes to the agent’s beliefs the same way the trust ladder has them approve the agent’s actions.

This doesn’t age out

Two objections come up whenever I talk about this, and they’re really the same objection. Context windows will get big enough. The labs will solve memory at the model layer.

Maybe both happen. Neither helps. A ten-million-token window is still working memory, and it still evaporates when the session ends. A lab-built memory layer still stores what it’s told and retrieves what it stored; it doesn’t know your approval flow changed in March unless something tells it. The invalidation problem isn’t a capability gap waiting on a better model. It’s a property of deploying any system with beliefs into an organisation that keeps changing, over a horizon of months and years, not sessions. Right now, and for any future I’d plan around, it gets solved in the harness, by engineering, with a human holding the pen.

We’ve collectively become good at the first extraction. The discipline that hasn’t formed yet is the second one, and the third, and the standing arrangement that makes them routine. Somewhere in every organisation that deploys an agent, there’s a rule that’s already wrong and a system that’s still sure of it. Naming the someone is the cheapest piece of engineering in the entire deployment.

Swap the ERP for any system an enterprise runs on and the story holds. Accounting packages, HR platforms, CRMs, ticketing systems. I have seen versions of that quote in most of them, and if you work anywhere near enterprise software, so have you.

It took me a while to understand that the quote was rational. It was the visible edge of an economic structure that has shaped enterprise software for three decades, and that structure is the reason the FDE role exists at all.

The economy of the gap

Off-the-shelf software covers the part of your business that generalises. Call it 70%. Payroll runs roughly the same way everywhere, so a vendor can build payroll once and sell it ten thousand times.

The remaining 30% is where your company is actually different. The approval chain that exists because of something that went wrong in 2016. The pricing logic that lives in a spreadsheet because no system could hold it. The Tuesday-morning export that one person runs by hand because two tools refuse to talk to each other.

Vendors never built that layer, and their refusal was the business model working as designed. One company’s weird workflow doesn’t scale, so it doesn’t get built. What filled the gap instead was a Frankenstein arrangement of the software you bought, the people patching around it, and the workarounds everyone stopped noticing years ago.

Around that arrangement grew an entire secondary economy. In ERP, software licensing represents only 20 to 30% of total cost; the rest is the everything-around-the-software. Implementation services typically run one to four times the annual licence fees. A Panorama Consulting survey found that only 7% of companies use their ERP as-is. The other 93% pay someone, at consultancy rates, over months, to bend the general tool towards their specific reality.

And the arrangement renews itself. Customisations sit so deep in these systems that every upgrade risks breaking them, which means every upgrade cycle re-bills the same work, which means the partner who understands your customisations becomes impossible to leave. You don’t pay for the field once. You pay for it forever.

The scale of this is easiest to see in a number that gets published as a triumph. IDC’s most recent Salesforce Economy study found that the partner ecosystem generated $6.19 for every $1 Salesforce earned, a multiplier projected to reach $6.84 by 2028. Read from the vendor’s chair, that is a thriving ecosystem. Read from the customer’s chair, it says that for every dollar of software you buy, more than six dollars of gap exist around it. And the projection has the gap growing.

For thirty years, that was simply what software cost. The weird 30% was never worth solving properly. Too small for a consultancy to build rather than bill, too specific for a vendor, too far down the internal roadmap to ever reach the top. So it stayed patched, and an industry got paid to maintain the patches.

Buildable, ownable, contested

What AI actually changed is the arithmetic on exactly that layer.

The cost of building bespoke software collapsed. Work that needed a team and a quarter now needs one person and a fortnight, sometimes an afternoon. Which means an enormous backlog of problems that were real but never valuable enough to solve has cleared the feasibility bar, all at once, across every company simultaneously.

Enterprises can see this happening and mostly cannot respond with headcount. By the time an internal AI department is scoped, hired and trained, the frontier has moved twice. Renting the capability from people who live at the frontier became the rational move, and the FDE is what that renting looks like. The role exists because the newly feasible needs a delivery mechanism.

But here is the part I find more interesting than the productivity story. Anything that becomes buildable becomes ownable. And anything ownable gets contested.

For thirty years, nobody fought over the bespoke layer because it was worthless as an asset. It was overhead, owned by nobody, living in operators’ heads and hand-run exports. The closest thing it had to an owner was the services partner, and even they only held the slice that touched the tool they serviced. Nobody held the whole workflow, and the fragment the partner did understand was precisely what locked you in.

Now that the layer can be built as real software, the question of who owns what gets built has an answer worth fighting for. And everyone has noticed at once.

The vendor pods build it and the vendor owns it. You get the outcome, they keep the asset, and the learning feeds a product that can eventually be sold to anyone, including the company you compete with. That anxiety is no longer hypothetical: TechCrunch reported last week that enterprises across insurance, fintech and healthcare are hiring their own FDE teams specifically to keep proprietary process knowledge away from the AI firms, on the theory that whoever holds your operational logic can one day compete with you.

The big consultancies have joined by renaming. The same billing model that maintained the patches now arrives wearing an FDE badge.

Enterprises themselves are standing up internal teams, and the job titles give the game away. Datasite is hiring Forward Deployed Engineers inside a Transformation Office, and “transformation engineer” is starting to circulate as a title of its own. When a role gets named after the outcome rather than the position, you learn what the buyer thinks they are purchasing.

And independent practitioners build the layer and hand it over, which is the model I have argued for since Hand Them the Keys.

Four claimants, one layer. This is also, I think, the real story behind the money. The billions committed to forward deployment this summer, the dedicated organisations announced weeks apart, make a strange kind of sense once you stop reading them as spending on deployment assistance. They are bids to own the bespoke layer of the economy. Land that sat unclaimed for thirty years because it was worthless is suddenly the most valuable real estate in enterprise software, and the fences are going up.

The vendors will happily absorb the maintenance cost of your bespoke layer, the way Google happily absorbs the cost of your inbox. The old economy charged you services fees for your weird workflows. The new one may charge you the workflows themselves.

Who should own it

The obvious objection is that all of this is services with a fashionable new title. I take the objection seriously, and I think the ownership question itself is what answers it. The services economy never forced you to ask who owns the bespoke layer, because the layer was a pile of workarounds that nobody would want. The fact that the question now has stakes is the proof that something structural changed.

So, where should ownership land? I don’t think there is one answer, and I distrust the people who have one. I think there is a decision rule.

If the workflow is commodity, let whoever builds it own it. Your expense approval chain is not your competitive advantage. If a vendor’s FDE can delete the workaround and you get the outcome, that is a good trade, and insisting on owning the result is sentimentality dressed up as strategy.

If the workflow is your differentiation, the reason you win deals or hold margins that competitors don’t, then the calculation inverts. Extracting that logic and building it is exactly what a good FDE does, and it is exactly why you should think hard about whose FDE does it. Handing a vendor the extraction means handing them your edge in a form that can be productised. It would be the most expensive field you ever paid for.

The problem is that most organisations have never sorted their workflows into those two piles, because for thirty years the sorting didn’t matter. The whole layer was unsolvable, so it was all just cost.

It matters now. The defaults are being written into contracts this quarter, while everyone stares at the salary numbers, and terms have a way of calcifying long before anyone intended them to be permanent.

So before the next pod arrives with a statement of work, it is worth asking the question the last thirty years never made you ask. Which of your weird workflows would hurt if your competitor could buy them?

Fixed outcomes, committed to before the work starts, on a timeline that leaves little room for the scope being wrong. That is a bold thing to offer, and the interesting question is why a company would be comfortable doing it. The answer depends entirely on what kind of business is underneath.

There are four ways the deployment work gets paid for. Experienced FDE leaders will have seen several of them, and probably argued about all of them. What I want to do here is lay them out side by side, because each one gives the FDE team a different job, and the differences only become visible when you look at where the money actually moves.

1. The meter pays

The first model belongs to the labs and the hyperscalers, and it is the one being discussed most loudly right now.

If your core business is metered consumption, the deployment is not a revenue line at all. It is acquisition cost. Anthropic has moved enterprise contracts off flat seat pricing to a lower headline seat price with token consumption billed at API rates on top. Once that is the shape of the business, the question of what to charge for the deployment stops being interesting. The deployment exists to install the meter.

You can see this in the AWS architecture itself, which puts a semantic layer inside the customer’s own AWS account and feeds a versioned knowledge graph that agents reason over. That is not a deliverable. It is a tap. Microsoft’s version, a two-platform structure designed to compound the customer’s proprietary data and workflows over time, is the same idea in different language.

Which is why offering fixed-outcome pricing costs them almost nothing. If the outcome lands, everybody is happy. If it misses, the semantic layer is still sitting in the customer’s account, the integrations are still wired, and the consumption still runs. The outcome fee is a rounding error against what flows through afterwards. It looks like risk transfer and it is closer to a promotional offer.

There is a smaller version of this model that shows up well below hyperscaler scale. A vendor that sells usage credits builds the solution at no charge, and in return asks the customer to commit to a consumption level up front. Fifty thousand in credits, say, purchased or contractually committed before the build begins. The deployment is still free on paper, but the customer has underwritten it. It is a sensible structure for both sides when it is priced honestly, and a quiet trap when the committed consumption was sized to fund the build rather than to match what the customer will actually use.

None of this is a criticism. It is a rational way to behave when you sell a meter. But if you run an FDE team inside a company that does not sell a meter, and you find yourself under pressure to match those commercial terms, it is worth knowing that you are being compared against a business that is not taking the same risk you would be.

2. The customer pays, and can see it

The second model is the explicit one, and it is less common than you would expect.

Sierra prices per successful resolution, at around a dollar fifty per case. Alongside that sit setup fees running between fifty and two hundred thousand dollars depending on integration complexity, with deployments taking three to seven months. The per-resolution pricing carries the narrative. The setup fee is where the deployment cost is actually recovered.

This structure has a lot going for it. It puts the build in front of the buyer as a real thing with a real cost, which means the conversation about scope happens while both parties are still holding a pen rather than six weeks into delivery. It also creates a clean internal boundary. The team doing the build is funded by a specific line on a specific contract, and you can tell whether the funding covers the work. When the assessment is wrong, it is visibly wrong, and the correction is a commercial conversation rather than a silent write-off.

The catch is that it requires a buyer sophisticated enough not to flinch at a six-figure setup fee, and a market position strong enough to ask for one. Plenty of companies would like to charge for implementation and cannot, because the competitor down the road is not charging for it.

3. Nobody pays, because there is barely a build

The third model is the one every product team says it is heading towards.

Fin charges ninety-nine cents per outcome with no integration fee, no setup fee, and no platform charge when it runs on an existing helpdesk. It can do that because it deploys in days rather than months. There is no deployment cost to recover.

This is the honest end state of productisation, and it is a real achievement rather than a trick. But notice what it implies. The pricing model is downstream of how much deployment the product needs. When someone tells you their pricing is simpler than yours, they are usually telling you something about their product surface rather than their commercial sophistication. And the categories where this works tend to have a narrow, well-bounded job to do. It has not yet happened in the messy middle of enterprise operations, and I am not convinced it is close.

4. The customer pays, and never sees it

Then there is the fourth model, which is where a large share of mid-market deployment work actually happens.

The shape is familiar. An FDE assesses how complex the solution is likely to be, that assessment maps to a tier, and the deal is quoted as an annual subscription in that band. Twenty thousand, forty, eighty, a hundred, invoiced monthly from the month after signature. There is no implementation line item. The vendor builds the thing, gets it running, and recovers the build across the term of the contract. One year locked, rolling into the next unless somebody cancels.

From the customer’s side this is clean. They see software pricing. They assume the number reflects the product.

From the vendor’s side, year one is underwater. You are spending the most expensive people in the company on a build you are not charging for, against a subscription that will take most of the contract term to get back to level. The margin is not in year one. It is in the renewal.

The bet hiding inside that structure is this. The model makes sense if you believe your solution is genuinely good enough to replace a person, or several people, at a lower cost than employing them. If that is true, the customer has no reason to ever switch it off. Cancelling means rehiring the work back. The renewal is not something you fight for each year, it is the default state, and the long recovery stops being risky and starts being patient. The whole model is a confidence statement about the product, dressed up as a pricing decision.

It also changes what the FDE team is for. If the money is in the renewal, then adoption is not a soft outcome that makes everyone feel good about the project. It is the entire commercial case. A deployment that technically works and goes unused does not just cost some goodwill. It costs the year you already spent. The slow business of getting a sceptical operator to route real work through the system stops being the unglamorous tail of the project and becomes the part that determines whether the account was ever worth signing.

Tanay Padhi framed the underlying economics well when we spoke: total cost of ownership for enterprise systems has always run at something like sixty to seventy per cent services and thirty per cent licence, and the companies now raising at software multiples are targeting somewhere between one and one and a half million dollars of revenue per FDE. The tiered subscription model does not make that services cost disappear. It moves it out of the invoice and into the margin, where it is harder to see and harder to argue about.

The price is set at the moment of least information

Whichever of the four you are in, they all rest on the same fragile thing.

The tier, the setup fee, the outcome definition, the consumption commitment. All of them are fixed at contract time, from a complexity assessment made before anyone has been inside the process. And the outcome has to be written into the contract as strictly as possible, because without a defined outcome nobody can tell when the work is finished. So you write it as tightly as you can, using what you know at the time.

What you know at the time is what the champion described. The operators, the people whose daily work actually determines how complex the build turns out to be, are usually not in the room yet. So the price and the definition are both set at the point of least information in the entire engagement, and everything that follows is either absorbing the difference or going back to the customer.

Going back is not fatal. When an assessment turns out wrong, you have the conversation, you reprice or you find the upsell, and sometimes that lands well because by then you have something working to show. But it costs credibility at exactly the moment you are asking for trust, and you only get to do it so many times with the same customer.

Stage changes what you are allowed to do

One thing I would tell anyone building an FDE team early: you have more room than you will ever have again, and you should use it deliberately rather than accidentally.

At a small company you care about revenue more than you care about the composition of revenue. You can take a build that was almost entirely custom and call it product licence, because there is no one to tell you otherwise and because you honestly intend to productise it later. That flexibility is real and it is useful. It lets you fund discovery out of customer money instead of investor money, which is a much better trade than it sounds.

The trouble is that it expires. At some point the revenue mix starts getting looked at properly, and the custom work you were booking as licence has to be recognised for what it is. Palantir spent years walking professional services down from around a quarter of revenue to something closer to a fifth, and built the entire bootcamp motion to reduce how much deployment each new customer needs. That is what deliberate looks like.

The moment you can no longer blur the line is a stage marker in itself, and it is worth knowing which side of it you are on before somebody else tells you.

There is one variable I have deliberately left out, which is who owns the budget on the customer side. Engineering-owned, go-to-market-owned and customer-success-owned deals do not price, scope or renew the same way, and I do not yet have a clean framework for why. What I am confident about is this. The commercial model your company runs was picked by somebody, under constraints that made sense at the time, and most FDE teams inherit it without ever being told what it commits them to. Finding out early is cheaper than finding out at renewal.

Before anything else, the obvious caveat. This volume has little to do with me being exceptional and a lot to do with me being findable. Between the FDE role and running FDE Hub, my profile sits near the top of exactly the searches recruiters are now running daily. Rory O’Brien observed earlier this year that FDEs are getting spammed while recruiters are “chasing a moving target of what the ideal candidate even is”. My inbox is simply where that observation became measurable.

So rather than treating the messages as noise, I started treating them as data. Thirty messages is a small sample, and a skewed one, since it over-represents whoever runs outbound at volume. But it is also something you cannot get from job boards or press releases: a direct reading of what the market thinks it is buying when it says Forward Deployed Engineer.

Here is what it revealed.

The market has a template, and the template is wrong

Two of the messages could have been written by the same person. Different senders, different companies, no connection between them, and nearly identical text: strong Python, SQL, data pipelines, customer-facing engineering. A third asked for deep expertise in Python, SQL, data engineering and system integrations, combining technical problem-solving with direct customer impact.

Somewhere in the past year, a default FDE job spec got written, and the market copied it. The trouble is what the template describes. Python plus SQL plus pipelines plus customer-facing is a data engineer who attends meetings.

What the template never mentions is the part of the job that determines whether a deployment survives. Nothing about discovery, or scoping, or sitting with the operators whose workarounds define how the process actually runs. Nothing about earning the trust to move a system from advisory mode to autonomy. Nothing about owning an outcome rather than a backlog. The skills in the template are real prerequisites, but they are the entry ticket, not the job. A market hiring against this spec will fill seats and then wonder why the deployments stall.

The title points in both directions at once

The stranger finding is that the label has come loose from the work entirely, and it drifts both ways.

One message pitched a Forward Deployed Engineer role that, on inspection, involved no customer at all. The job was building an internal AI platform: backend, cloud, Kubernetes, enabling other teams to deploy. Worthwhile work, and roughly the opposite of forward deployment. Someone had stapled the market’s hottest title onto an infrastructure requisition, presumably because it improves response rates.

Meanwhile, the most accurate descriptions of FDE work in the entire pile arrived under different names. One healthcare AI role, titled AI Product Engineer, was described as owning the whole thing: talk to users, write the code, ship it, no tickets, no story points. Another, titled Staff AI Engineer at a logistics scale-up, was end-to-end ownership of production agents inside a messy real-world domain. Both are closer to the craft this newsletter covers than most of the messages that used the actual words. One sender split the difference and hedged the title with a slash.

The purest specimen was an FDE role where Python was, quoting loosely, helpful but definitely not essential. To be precise about what is wrong there: Python does not define this role, engineering does. Being able to build is the floor everything else stands on, and fluency in a language like Python is the cheapest reliable signal of it. A sender can reasonably swap the language. A sender who declares it optional, without asking for any other evidence of engineering ability, has waived the floor itself. At that point there is no role behind the message, only a vacancy.

The practical lesson for anyone fielding these messages is to read each one twice. Once for the title, which tells you what the market currently rewards, and once for the work, which tells you what you would actually be doing. In this sample the two agreed less than half the time.

An industry has formed around the title

The messages themselves are only half the dataset. The senders are the other half, and they show a recruiting industry rapidly restructuring itself around a single job title.

One headhunter now describes himself, in his signature, as a Forward Deployed Engineering headhunter, with regional specialisation across Europe, the Gulf and Singapore. His message contained no role at all. He wanted to understand my motivations for a next move before any specific mandate entered the conversation. That is talent pooling: building inventory ahead of demand, which only makes sense if you expect the demand to keep coming.

A managing director at an executive search firm reached out about a leadership search, and the interesting part was what she wanted. Not my CV. My network. Visible practitioners are becoming sourcing infrastructure, a routing layer the search industry queries when it cannot find supply on its own.

Further down the chain sit the sourcers: research consultants at boutique agencies running outbound volume on roles they did not scope and will not close. One of these roles did not appear anywhere on the client’s own careers page, which means the person most distant from the work was the only person publicly attached to it.

And then the scene that summarises the whole season. A recruiter messaged me about a role building an agentic AI platform for enterprises. When I asked for details about the company and the role, the reply directed me to a five-minute AI prescreening call, with a link and a privacy notice. A human recruiter, hiring a human to deploy AI agents, delegating the first human conversation to an AI agent. Whatever your position on AI in recruiting, the loop has visibly closed.

Across all of this, one pattern held with almost no exceptions: message quality degraded with every layer between the sender and the actual work. The template spam came from the outermost layer. The single best message in the pile came from an in-house sourcer at a company standing up a new AI unit, and it described real forward-deployed work in specific terms: owning the customer engagement from adoption readiness through implementation, first hire on a founding team, a path into leadership. Proof that the role is perfectly describable, provided the person describing it sits close enough to it.

The inbox does not look like the headlines

The final finding is about whose demand this actually is.

The FDE story of the past two months has been told in billions: captive deployment organisations, thousands of embedded engineers, hiring announced by press release. Going by the headlines, you would expect an inbox full of hyperscalers.

The count in mine: one. A single message from one of the giants, describing an embedded builder bridging the gap between prototypes and production, language lifted almost directly from its public job descriptions. Accurate, credible, and alone.

The ratio says less about any individual inbox than about how these two markets hire. A handful of giants against hundreds of startups will always lose on volume. The giants also recruit through their own channels, in-house teams, referrals and hiring managers who are active on LinkedIn themselves, while the startup demand arrives through agencies and sourcers running outbound at scale. What fills an inbox is not the biggest demand. It is the most intermediated demand.

Everything else came from a different market entirely. European seed and Series A companies. A fintech hiring through an agency platform. A startup a few months past its seed round, whose recruiter presented its handful of early contracts as a sweeping global enterprise footprint. Several companies hiring their first FDE ever, in one case explicitly hire number one of a founding unit.

So there are two demands running in parallel. The headline demand is concentrated, capitalised and slow, hiring in the thousands through its own channels. The inbox demand is fragmented, small and immediate: companies buying their first forward deployed engineer, often without a settled idea of what one is, frequently through intermediaries who understand the role even less. The first market sets the narrative. The second is where most FDEs will actually end up working, and it is far messier than the narrative suggests.

Who teaches the market?

Thirty messages, one conclusion: the market has learned to say the words faster than it has learned what they mean. The demand is real at every layer, from the giants to the seed rounds. The definition has not kept up, and every layer of intermediation makes it worse.

That gap will close eventually, the way it closed for titles like site reliability engineer and product manager before this one. The open question is who does the closing. The companies, through expensive mis-hires that teach them what the role is not. The recruiters, as the specialists among them learn to tell forward deployment from data engineering with meetings. Or the practitioners, by being loud enough about what the work actually is that the template eventually gets rewritten.

My inbox suggests nobody has claimed the job yet.

On 30 June, AWS announced a dedicated Forward Deployed Engineering organisation backed by $1 billion, staffed in the thousands, sending pods of five or six engineers into customer environments on 45-day cycles. On 2 July, Microsoft went bigger: $2.5 billion for a new operating business called Frontier Company, embedding 6,000 industry and engineering experts at customers, with $1.2 billion of that earmarked for headcount alone.

That capped a six-week stretch in which OpenAI stood up a deployment organisation with TPG, Advent, Bain Capital and Brookfield behind it at a $4 billion valuation, and Anthropic formed a $1.5 billion services venture with Blackstone, Hellman & Friedman and Goldman Sachs.

A year ago, when I moved into this role, forward deployed engineering was barely known outside Palantir. Explaining my job at a birthday party took a while. Today, four of the largest technology companies in the world have put roughly $5 billion of committed capital behind it in six weeks, with OpenAI’s deployment company valued at another $4 billion on top. Gartner projects that 85% of tech providers will have an FDE programme as a core AI delivery model by the end of this year.

The demand side of this market is now settled. The supply side is the question nobody has answered.

Run the numbers

Microsoft wants 6,000 people embedded at customers. AWS says thousands. Salesforce has reportedly committed to hiring 1,000 FDEs. Postings on Indeed went from 643 in April 2025 to 5,330 in April 2026. The consultancies have piled in too: by one tracker’s count, Deloitte, Accenture, KPMG and BCG together post more FDE roles than any single product company except Google.

Set that against the existing pool.

When I analysed close to 2,000 FDE practitioner profiles for the State of FDE report, one pattern was unmistakable. The population of people with real years in this role is small, and it is overwhelmingly Palantir-shaped. The company had a decade-long head start, and until recently it was more or less the only place you could accumulate this specific kind of experience.

Where are those people now? The evidence here is anecdotal, but it lines up with what leaders in the space keep telling me. The practitioners with genuine depth, meaning multiple deployments across multiple environments and the scar tissue to prove it, mostly fall into two groups: they are already inside the companies that moved early, or they have gone independent and run their own shops. Not every experienced FDE is spoken for. But if your plan requires hiring a thousand of them this year, the maths does not work.

Experience in this role accumulates one deployment at a time. Demand grows by press release.

Manufacturing the role

So companies will do what companies always do when a labour market runs dry. They will manufacture the workers.

That happens in three ways, and all three are already visible.

The first is relabelling. Solutions architects, sales engineers and implementation consultants are being rebadged as FDEs, sometimes with the job description barely touched. The consultancy posting numbers are the clearest evidence. A firm that posts dozens of FDE roles in a quarter did not suddenly discover forward deployment. It renamed a practice it already had.

The second is retraining. This is where the big money goes. Microsoft’s $1.2 billion headcount budget explicitly includes AI-readiness training for existing staff, and the unit will be staffed primarily by people already inside the company. AWS says it will fill roles through a mix of external hiring and internal moves, which lands differently when you remember Amazon has cut more than 30,000 corporate jobs since October. A meaningful share of the new FDE workforce will be existing employees walked across an internal bridge.

The third is new pipelines. Companies in the training business will spin up FDE cohorts and certifications the same way they did for cloud, for data science, and for prompt engineering. Give it a year and there will be a certificate for this.

None of this is scandalous. Every discipline that grows this fast industrialises its own production, and Palantir itself never waited for experienced FDEs to appear. It hired sharp graduates and built them, and Priya Khandelwal made the case convincingly when we spoke about why new grads make great FDEs. Trainability is not the problem.

The problem is definitional. When a 6,000-person Microsoft unit, a Deloitte bench and a rebadged solutions architect all carry the same title, the title stops carrying information. Vlad Shulman warned about exactly this in our conversation earlier this year: once the term detethers from the original intent, candidates self-select against the label, employers hire against the label, and everyone ends up sailing wherever the wind blows.

Worth naming, too, what the industrialised version actually looks like. A pod of five engineers on a 45-day clock is a different animal from an engineer embedded in one customer for a year. The first optimises for repeatable delivery. The second optimises for learning, the thing that made the role valuable to product companies in the first place. Microsoft seems to understand the distinction, because its own announcement pointedly distanced the effort from the FDE label. At some scale, the honest description of what the hyperscalers are building is consulting with better tooling. That is a fine business. It is just not the same job.

The self-serve objection

There is a longer-term question sitting underneath the hiring one, and it deserves a straight answer.

The case against the role’s durability goes like this. FDEs exist to close the gap between a general product and a specific environment. Every deployment teaches the product something. The product absorbs the lessons, becomes more self-serve, and the gap the FDE was hired to close disappears. The role designs itself out of a job.

Per product, that is exactly right. It is also the point. The FDE who makes a product self-serve has done the job well, and the reward for doing the job well is that this particular gap no longer needs them.

Per economy, the logic inverts. Gaps are not a fixed quantity that gets worked down to zero. Every new capability that ships creates a new frontier of environments it does not yet fit, and the practitioners who closed the last gap move to the next one. The role is self-terminating per product and permanent in aggregate. That has been the pattern for every implementation discipline before this one, and nothing about AI suggests it breaks here.

If anything, the coming years look like they will add a category of work rather than remove one. The same Gartner analysts projecting 85% adoption of FDE programmes also project that 70% of enterprises will abandon agentic AI projects born from FDE-led engagements within two years. Read one way, that is an indictment of the whole model. Read another, it is a forecast of the workload. Thousands of systems are about to be built at speed, by pods on 45-day clocks, handed over, and left to drift as models change and upstream systems move underneath them. Somebody will have to go back in. The remediation wave has not started yet, and it will need people who understand why the first deployment decayed.

Which version survives

The question I keep turning over is not whether the role survives. Between the capital committed, the posting curves and even the abandonment forecasts, its survival looks assured for the foreseeable future.

The question is which version of it survives, and whether the word still means anything once the money has been spent. Take the original Palantir model: one engineer, embedded deeply in a single customer, feeding everything they learn back into the product. That version is scarce and slow to develop. The second version is the industrial one now taking shape at the hyperscalers, pods of five or six on 45-day clocks, built for repeatable delivery at volume. It is about to outnumber the original many times over.

There is a third version too, and it is the one I know from the inside: a single practitioner spread across ten or more clients at once, spanning logistics, insurance, finance, manufacturing and wholesale. It trades the depth of the year-long embed for a breadth nobody inside a single vendor gets to see. The same failure modes repeat across industries that have never spoken to each other, and recognising them early is the entire value. This version appears in nobody’s hiring plan, because it cannot be hired in bulk. It gets built one practitioner at a time, and increasingly it operates independently.

All of it will get called FDE. Only the first is what the term was coined for.

A year ago, almost nobody knew what a forward deployed engineer was. A year from now, everybody will have an opinion, and I suspect very few of those opinions will describe the same job.

It is the kind of brief that sounds like ambition and works like a trap. There is no version of that sentence an FDE can deliver, because there is no point at which it is finished. You could spend three years inside that mandate and still not be able to say the thing is done, because nobody defined what done would look like before you started.

Compare it to a real outcome. Get the time to process an exception down from two days to twenty minutes. Take a workflow that currently needs three people reviewing every case and get it to one person reviewing only the cases that genuinely need a human. Those have an end. You can stand in front of them and know whether you got there.

The difference matters more than it looks, because the FDE’s only reliable instrument for knowing they have finished is a feeling. And that feeling only works if the finish line was drawn in advance.

The loop

The work has a shape, and it repeats.

You arrive knowing almost nothing about the customer. Sometimes not much about the domain either, though that part is less important. The first weeks go into getting deep enough into how their operations actually run to find the highest-value problem you can solve, the one where the cost is real rather than just annoying. Then everything narrows onto solving it.

That stretch is intense and fast and completely absorbing. You are learning a business from the inside and building the thing that changes it at the same time, and there is nothing else like it.

And then you get there. The outcome lands. The numbers move. The people who were sceptical start using it without being asked.

And you deflate like a balloon.

There is a version of the next few months where you stay. You hold the account, you answer the questions, you make small incremental improvements, you sit in the standups. You can do this. Plenty of FDEs do. But it is not the work that pulled you into the role, and the flatness you feel is not a character defect to manage. It is information.

The case for moving on

Naval Ravikant has talked about getting bored easily, the pattern of finding a challenge, getting good enough at it, and then needing the next one. He landed on angel investing partly because it suited that wiring. The FDE role runs on the same engine. The appetite for a problem you do not yet understand is what makes you good at the front of an engagement, and it is the same appetite that makes the maintenance phase feel like wearing someone else’s coat.

This connects to something I have argued before, that FDE teams are an investment in discovery rather than a services business. If that is true, then an FDE’s time is close to the most expensive research budget the company has. Spending it on steady-state maintenance is less an act of loyalty to the customer than a misallocation of the one resource that exists to find the next thing worth building. The boredom is that budget objecting to being parked.

The case for moving an FDE on is not really about keeping them entertained. It is that every new engagement is another source of product input, and those inputs are the whole point. A new problem, a new operation, a new set of edge cases, that is where the patterns worth building into the product actually surface. The more times an FDE goes through the loop, the more of that signal they generate. Leave them on one account refining what already works and the stream slows to nothing. You are paying a discovery cost and getting maintenance in return.

Where the work actually ends

So where does the FDE’s job end.

Not at the demo. I want to be careful here, because it would be convenient to claim the work finishes the moment the solution technically functions and the boring part belongs to someone else. It does not. Adoption is the FDE’s job. Earning the trust that gets people to route their real work through the thing is the job, and it takes longer than the build and it is rarely fun. An outcome nobody uses is not an achieved outcome.

What is not the FDE’s job is everything after that. Maintenance. The steady-state support, the small fixes, the questions that have settled answers now. That should sit with a separate team, the way it did before we started blurring these lines, or increasingly with an agent that can absorb the long tail of small requests. The FDE got the customer to the outcome and made it stick. Keeping it running is genuinely different work, and it does not need the most expensive person in the building.

None of this is a prohibition. You can keep the FDE on the account. You can take the open-ended mandate and bill against it month after month. There is nothing wrong with any of that, and for some companies it is exactly the right business to be in. But it is a services business, and the honest thing is to call it one. The problem is never that an organisation does support work. The problem is an organisation doing support work while telling itself, and its investors, that it runs an FDE team. Once that happens the label stops meaning anything, and you lose the one thing the model was meant to buy you, which is discovery.

Worth saying that moving on does not have to mean leaving the customer. The next challenge is often inside the same organisation, a different process, a different outcome, a fresh problem worth the immersion. What it cannot be is the same solution on a drip.

Telling the difference

The danger in all of this becomes obvious the moment you say it out loud. Boredom is not a precise instrument. It can show up early, before the outcome is actually achieved, before any trust has been built, at exactly the point where the unglamorous adoption work begins. Following it then is not discipline. It is abandonment dressed up as temperament. The hard part is telling the two apart, knowing whether you have gone flat because the defined outcome is genuinely behind you, or because the fun part is over and the patient part has started. The first is a signal to move. The second is a signal to stay.

Which is why the defined outcome carries so much weight. It is the only thing that lets you trust the feeling at all. If you agreed up front what done looks like, and adoption was part of that picture, then the deflation afterwards is real data. If you never defined it, the boredom has nowhere honest to point, and you will either drift into permanent support or leave too early and call it instinct.

So the vague brief turns out to be the actual enemy. “Make us AI-native” does more than waste time. It removes the FDE’s ability to know when they are done, and a role that runs on knowing when you are done struggles to function without that line.

There is a simple test in all of this, for an FDE and for whoever runs the team. Look at the gap between an outcome landing and the FDE rotating onto the next defined problem. It should be short relative to how long the outcome took to reach. If they move on quickly, the model is working. If they are still on the same account a long stretch later, making small improvements, one of two things is true. Either the outcome was never defined, so nobody can tell it has been reached. Or it was reached, and the team has quietly become a services business that happens to use the word FDE.

Neither is fatal, and both are worth knowing. The deflation that follows a delivered outcome is the cheapest diagnostic you have for telling which one you are living in.

So the question is not really whether FDEs get bored. It is what your organisation does when they do.

The argument underneath it is one I keep circling in my own writing. The moment a demo works is the moment everything looks solved, and it tends to be the most dangerous point in the whole project, because the jump from “works when I drive it” to “works when real users do” isn’t a matter of polish. It’s a different problem entirely, and evals are how you bridge it. I’ve written before about the unknown unknowns problem, how the hardest part of this work is knowing when a system is quietly wrong. What follows is the disciplined engineering answer to exactly that. It goes deeper into the mechanics than my usual essays, the metrics and the tooling and the gate thresholds, and if you’re not the one wiring up the harness you can skim those and still take the shape of it. The shape is the point. Over to Kranthi.

There’s a moment in every AI project where the demo works. The retrieval is pulling relevant chunks, the model is generating coherent answers, and the stakeholders are nodding. This moment is dangerous.

It’s dangerous because the gap between “works in a demo” and “works in production” is not a linear improvement problem. It’s a category shift. In a demo, you control the inputs, you cherry-pick the questions, and you evaluate by gut feel. In production, real users ask unpredictable questions against messy data, and you evaluate by numbers you’ve committed to in advance.

The eval lifecycle is the structured process that bridges this gap. OpenAI’s enterprise whitepaper sketches it in a single table. Let’s build the full architecture.

Stage 1: Retrieval Evaluation

Retrieval Evals

Each stage has its own metrics, its own evaluation set, and its own continue/refine/stop gate. The lifecycle repeats at MVP, pilot, and production scale — with the evaluation set roughly doubling at each stage.

The question: Does the system reliably find the right information?

This is where most AI products fail first — not because retrieval is hard to build, but because retrieval is hard to evaluate well. A retrieval system that returns plausible results will pass casual inspection. A retrieval system that returns the right results for edge cases is what separates a demo from a product.

What you’re measuring:

Recall — of all the documents that should have been retrieved, what fraction did the system actually find? Low recall means the system is missing relevant information. For a Q&A agent over company docs, this might mean missing the updated policy while retrieving the obsolete one.

Precision — of all the documents retrieved, what fraction are actually relevant? Low precision means the model’s context window is polluted with irrelevant material, degrading downstream generation quality.

Mean Reciprocal Rank (MRR) — is the most relevant document appearing first, or buried in position five? Models pay more attention to what appears early in context. If your best document consistently ranks third, your answers will be worse than they should be.

How you build the evaluation set:

Start with 50-100 representative queries drawn from actual user conversations (or realistic simulations). For each query, a domain expert labels which documents should be retrieved. This labeled set becomes your retrieval ground truth.

This is tedious and irreplaceable. Automated approaches — using an LLM to judge retrieval relevance — are useful for scaling evaluations but unreliable for building the initial ground truth. The domain expert knows that “Q3 revenue guidance” should retrieve the board deck, not the press release. The LLM doesn’t know your organization well enough to make that distinction.

The gate decision:

Continue if recall ≥ 0.85 and precision ≥ 0.75 on your evaluation set. Refine if metrics are between 0.60 and 0.85 — this usually means adjusting chunking strategy, embedding model, or retrieval parameters. Stop if recall is below 0.60 — the retrieval pipeline needs fundamental rework before downstream evaluation is meaningful.

Track token costs at this stage. Retrieving too many documents burns context window space and money. Retrieving too few misses information. The right balance is specific to your use case.

Stage 2: Summarization and Grounding Evaluation

The question: Does the system synthesize clear, consistent, useful, and cited answers? Did it follow the right steps and access the right data?

This is the stage where the whitepaper’s description — “evals on traces/logs + SME review” — is most dangerously compressed. “SME review” alone can mean anything from “my colleague glanced at five outputs” to “three domain experts independently rated 200 outputs on a structured rubric.” The difference in quality assurance is enormous.

What you’re measuring:

Faithfulness — does the answer only contain claims that are supported by the retrieved context? An answer can be correct according to the model’s training data but unfaithful to the retrieved context, which means it’s hallucinating in a way that’s invisible to the user. This is the most important metric in the entire eval lifecycle and the one most teams measure poorly.

Relevance — does the answer actually address the question? A faithfully grounded answer that doesn’t answer the user’s question is useless.

Completeness — does the answer cover all the relevant information from the retrieved context? Partial answers erode trust over time even when they’re technically accurate.

Citation accuracy — if the system claims “according to document X,” is that claim actually in document X? Citation errors are trust-destroying because they’re verifiable — a user who checks a citation and finds it doesn’t match will never trust the system again.

How you build the evaluation:

For each query in your evaluation set, have domain experts write the “gold standard” answer — the response a knowledgeable human would give. Then compare model outputs against these references.

Automated faithfulness evaluation is one of the areas where LLM-as-judge approaches are genuinely useful. Have a separate model (not the one generating the answer) check whether each claim in the output is supported by the retrieved context. Tools like RAGAS, DeepEval, and TruLens provide frameworks for this, but the key insight is: use a different model for evaluation than the one generating answers. Models are unreliable judges of their own outputs.

The gate decision:

Continue if faithfulness ≥ 0.85, relevance ≥ 0.80, and citation accuracy ≥ 0.90 on a sample of 200+ queries. Refine if faithfulness is between 0.70 and 0.85 — this usually means adjusting the system prompt to enforce stricter grounding, or improving the retrieval stage to provide better context. Stop if faithfulness is below 0.70. A system that hallucinates in 30%+ of responses is not ready for any form of user testing.

Stage 3: Guardrail Evaluation

The question: Does it stay within approved data, tone, and safety guidelines?

Guardrails get treated as an afterthought in most AI projects — the safety review that happens the week before launch. That’s backwards. Guardrail failures are the ones that make the news, generate legal liability, and destroy user trust in ways that no amount of accuracy improvement can repair.

What you’re measuring:

Topic boundary compliance — does the system stay within its defined scope? A legal Q&A agent that starts offering medical advice has failed a topic boundary guardrail, even if the medical advice happens to be accurate.

Tone and brand consistency — does the system’s voice match organizational guidelines? A customer-facing agent that suddenly becomes casual or sarcastic when asked difficult questions has a tone guardrail failure.

Safety filtering — does the system refuse or redirect harmful, offensive, or manipulative inputs? This isn’t just about explicit toxicity — it includes prompt injection attempts, jailbreaking, and social engineering.

PII handling — does the system avoid exposing, generating, or echoing personally identifiable information? This is both a safety and a regulatory requirement.

How you build the evaluation:

Create an adversarial test set. This is distinct from the representative test set used in stages 1 and 2. Adversarial tests specifically probe boundaries: out-of-scope questions, prompt injection attempts, requests for information the system shouldn’t have, edge cases where tone guidance is ambiguous.

A strong adversarial test set has 100+ cases across these categories, built by people who actively try to break the system. This is one area where “red teaming” (having humans try to elicit harmful outputs) provides signal that automated evaluation cannot replicate.

The gate decision:

Continue if guardrail violation rate < 0.5% on the adversarial test set and < 0.1% on the representative test set. Refine if violations are between 0.5% and 2% — usually by tightening the system prompt, adding output filters, or restricting tool access. Stop if violation rate exceeds 2% on the adversarial set. Safety is not a gradient.

Every threshold in these three gates fits on one page: the continue, refine, and stop cutoffs, the failure signature for each gate, and the tooling for each. Download the Eval Gate Cheat Sheet

The Lifecycle Repeats at Every Scale

Here’s what the whitepaper mentions but doesn’t emphasize enough: this three-stage evaluation runs at every deployment gate, not just once.

MVP gate: Run all three stages on your evaluation set. Small scale (50-100 queries for retrieval, 200 for summarization, 100 adversarial). The goal is to validate the architecture, not achieve production quality.

Pilot gate: Re-run with production data from pilot users. The evaluation set should now include real queries you didn’t anticipate. Expand the adversarial set based on actual user behavior. Introduce latency and cost measurements — a system that takes 30 seconds per response won’t be adopted regardless of accuracy.

Production gate: Full evaluation suite plus continuous monitoring. This is where the eval lifecycle transitions from a build activity to an operational responsibility. The same metrics you used to gate deployment now become the SLOs your team monitors daily.

The whitepaper’s “once proven in a narrow scope, the same checks repeat at pilot and production scale” is correct, but it undersells the expansion that happens at each gate. Your evaluation set should roughly double at each stage. Your adversarial set should incorporate everything users tried during the previous stage. And your automated monitoring should replace the manual SME review that gates earlier stages.

The Tooling Stack

You don’t need to build this from scratch. The eval tooling ecosystem has matured significantly:

Retrieval evaluation: RAGAS and DeepEval both provide retrieval metrics out of the box. LangSmith and Arize Phoenix offer tracing that connects retrieval to downstream generation quality.

Faithfulness and grounding: RAGAS faithfulness metrics, DeepEval’s hallucination detection, and custom LLM-as-judge evaluations using structured prompts. Braintrust and HumanLoop provide platforms for managing evaluation datasets and running automated evals at scale.

Guardrails: Guardrails AI, NeMo Guardrails (NVIDIA), and Lakera Guard for safety filtering. LangFuse for observability and trace-level analysis.

End-to-end: LangSmith, Braintrust, and Arize Phoenix each provide integrated platforms that span all three stages, with tracing, evaluation, and monitoring in a single tool.

Pick one end-to-end platform and supplement with specialized tools where needed. The worst outcome is building a custom evaluation framework from scratch — you’ll spend months replicating what these tools provide on day one.

The Real Lesson

The whitepaper frames evaluation as Phase 4 — something that happens when you build products. That’s wrong. Evaluation is the connective tissue that links every phase.

Your Phase 1 data access decisions determine whether you can build a retrieval evaluation set. Your Phase 2 fluency programs determine whether you have SMEs capable of writing gold-standard answers. Your Phase 3 prioritization determines whether you’ve chosen use cases where evaluation is tractable.

The eval lifecycle isn’t a step in the process. It’s the process.

Most of the time, that is a reasonable thing to ask for, and a reasonable thing to build. Replication has a clear before and after, the value is easy to point at, and nobody has to renegotiate how the work is organised. I am not going to pretend that kind of project is beneath anyone. A lot of real value gets delivered that way, and for many problems it is exactly the right call.

But it is worth noticing what you are copying when you copy a process.

Most steps were built for people

A process is a record of the constraints that existed when it was designed. Someone could only hold so much in their head, so the work was split across three roles. Information could not move between two systems on its own, so a person was placed in the middle to carry it across. Nobody trusted the output of the first step, so a second step was added to check it. Over the years these accommodations harden into the way it works, and after long enough nobody remembers that most of them were answers to questions about human capacity rather than questions about the work itself.

The clearest version of this is almost a century old, and it is one of the most studied episodes in the history of technology. When factories first electrified, many of them simply swapped the large central steam engine for a large central electric motor and changed nothing else. The machines stayed lined up along the same shafts and belts, arranged for a building that had a single source of power in the middle. The productivity gains everyone expected did not arrive. They came later, once a generation of managers stopped treating electricity as a quieter steam engine and put a small motor on each machine, which meant the machines could finally be arranged around the flow of the work rather than the location of the engine. Economists have a name for the gap between having a technology and getting the gains from it, and electrification is the example they reach for. The power had been available for decades. The reorganisation was the hard part.

We are doing the early version of this now. We are dropping AI onto the spot where the old engine used to sit and asking why the numbers are not better.

The bigger win, and why it is rare

The projects I am proudest of are the ones where the customer gave me room to do more than replicate. The brief in those cases was larger than making a step faster. It was closer to a standing invitation: look at this end to end, and tell us which parts of it still need to be here. When that happens, the most useful answer is often that a step should not be automated at all, because it should not exist. The check that was added because the earlier step was unreliable is not needed once the earlier step is reliable. The handoff that existed to move data between two systems disappears when the same agent can read from both. You are not speeding the step up, you are removing it.

That is where the real gains live, and it is also the thing customers are slowest to allow.

I have learned not to read that reluctance as timidity. Removing a step is a far larger commitment than automating one. Automating a step leaves the shape of the work intact and gives everyone an easy way to roll back if it goes wrong. Removing a step means someone now owns the risk that the step used to cover, and it usually means crossing into another team’s territory, or touching headcount, or explaining to an auditor why a control is gone.

Some of those steps are there for reasons that are not visible from the outside. A lot of what looks like waste is scar tissue. The reconciliation, the second sign-off, the manual review that feels redundant, each one is often the residue of a specific time something went badly wrong, and the step is the organisation’s memory of it. You cannot tell from the outside whether a step is a relic of an old constraint or a guardrail protecting against a real failure. The only way to know is to understand why it was put there in the first place. That is why the room to redesign a process has to be earned rather than assumed. You get it by being right about the small things first, by showing you understand the work well enough to know which fences are safe to take down.

So the ideal and the reality sit some distance apart. In an ideal engagement, the customer hands you the whole process and the freedom to question all of it. In a real one, you start by automating the step you were asked to automate, and you earn the right to ask the larger question slowly, if you earn it at all.

The same logic, one level up

What is true of a single process is becoming true of whole companies.

A company being built now, with these tools assumed from the start, does not carry these accommodations inside it. It does not have the three roles that exist because one person could not hold it all, or the team whose entire job is to move information between systems. It is designed around what the technology can do, the way the rebuilt factories were designed around the flow of work. It has no old layout to defend.

An incumbent is the opposite. It is made almost entirely of steps that were shaped around people, accumulated over decades and defended by the teams who run them. Automating those steps one at a time makes the company faster at doing what it already does. It does not change the layout. A competitor that never had the layout in the first place can move in ways that bolting AI onto the old structure cannot match.

I want to be careful here, because the story of the AI-native upstart eating the incumbent is one that technology people have told many times, and it has disappointed at least as often as it has come true. Incumbents have things that are hard to copy: distribution, data, brand, the trust of customers who would rather not switch, and in regulated work a moat a newcomer cannot wish away. The displacement, when it comes, is usually slower and more partial than the people predicting it expect, and the incumbents that come out ahead are very often the ones that adapt, precisely because they can pair the redesign with assets a newcomer does not have.

But adapting and bolting on are not the same thing, and the distance between them is the whole story. The companies that treat this as a chance to redraw the layout will pull away from the ones that treat it as a faster engine for the layout they already have. That is less a prediction about which names survive than a prediction about which behaviour wins.

What this means if you do this work

If you build and deploy this kind of system for a living, that distance is the most important thing happening to your role, and it is worth sitting with what it implies.

Every established company now has a version of the same project in front of it, and it is not really an “add some AI” project. The harder version is this: work out which parts of how we operate were answers to old constraints, and rebuild around the parts that are left. That is an enormous amount of work, and it is exactly the kind of work that does not fit a product bought off a shelf, because the answer is different inside every organisation.

For most of corporate history, work like that meant hiring a consultancy, spinning up an internal team, or bringing in an agency, because the building itself took a lot of hands. That has changed. One engineer who is good at this, with the tools we have now, can carry what used to need a room full of people. The redesign that needs doing keeps growing while the cost of the person who can do it keeps falling, and that is usually what a wave looks like before it arrives. You are right in its path.

But demand is not the whole of it, and it is worth being honest about which version of this role is the one that matters. The building is turning into the easy part, the piece the tools increasingly handle on their own. What stays scarce is the judgement to look at how a company works and see which parts of it no longer need to be there, and the standing to take them out. The engineers who define this field will not be the ones who automate the fastest. They will be the ones who know what to delete.

You did plasma physics research at Cornell and presented at the American Physical Society. That is a long way from where you ended up. What pulled you away from physics?

You do all sorts of things early in your career. My first jobs were at an office supply store and being a soccer referee. But physics was the thing I fell in love with first. It was my favourite subject in high school, and I thought computer science was fun but more of a toy. You could make cute little programs, but I did not directly see it as a way to have a massive impact on the world. That was 2010, and I had not really been exposed to the world of startups or how fast tech could move.

So I went to Cornell as an engineering physics major. Plasma research was genuinely cool, the extremes of it, insane temperatures and conditions you cannot find anywhere in the world but can create with science, and then studying what happens as a result.

The turning point was a conference in Denver where we presented some of our work. The median age in the room must have been in the sixties, and there was not a lot of energy. The growth potential of the field, where it was heading, did not feel as promising as tech. Around the same time I got an internship at Google and saw the pace the company was moving at and scale of impact. That energy was hard to ignore.

You also spent a year at Oxford studying computer science and philosophy. That combination is uncommon in tech. Is there anything from the philosophy side you still use?

First, I have a pretty basic understanding of philosophy. But Oxford is one of the renowned places to study it, and part of what drew me in was the sense that I would never otherwise get to do something like that.

I do think philosophy and tech overlap more than people realise. A lot of the ideas around existential risk and effective altruism came out of that world. Nick Bostrom ran the Future of Humanity Institute at Oxford, and those ideas were a big part of the early discussions and culture at OpenAI, and arguably part of what led to Anthropic. My understanding is that a lot of Anthropic’s founding arc traces back to ideas in the sphere of existential risk and effective altruism, which came very directly from philosophy. So a company like Anthropic exists, in part, because of ideas from philosophy that found their way into tech. There is more overlap there than people give it credit for.

Leo’s path into FDE did not run through Palantir, the way many do. It ran through founding a company.

You are a former founder, not a career FDE. What about Ramp made this the right place to land after building your own company?

What I have found is that former founders often make excellent FDEs. As an early-stage founder you are talking to customers, building the product, and figuring out what to build. As an FDE it is very similar. You are talking directly to customers, working on unshaped and ambiguous problems, deciding whether to hack something together or build something robust, and doing a mix of customer, product, and engineering work. The tie between FDE and entrepreneurship is close in both directions. It is a strong fit for former founders, and it is also good training for anyone who wants to found a company later.

As for Ramp specifically, I had followed the company for a couple of years and had a lot of respect for it. It was one of the fastest-growing organisations I had seen, founded in 2019 and at an enormous valuation within a couple of years. By the time I had stepped back from my startup and was thinking about what to do next, I wanted to be somewhere that was going to grow, in an environment that rewards ambitious individuals, and where I could still draw on my startup experience. If I had gone to big tech or somewhere more mature, I do not think I would have been able to use everything I had learned, and I do not think I would have grown the way I have.

I am extremely bullish on the company’s trajectory and on what it offers ambitious builders. If your direct aspiration is to found a company, go and do that first. But if you want to see what high-calibre execution looks like, or you are early and do not yet have the conviction to start your own thing and want to build the skills and experience, and maybe meet a future co-founder along the way, this is a strong place for that.

A large share of FDEs at Ramp are former founders. That looks deliberate. What does founder experience give people that you cannot get from senior engineering experience alone?

It is less the fact of having been a founder and more what it implies about your character, skills, and motivations. The thing I care about most, and that a lot of people are thinking about now, is intrinsic drive. How genuinely motivated are you to achieve a business or customer outcome? That is hard to assess in an interview, so one of the best signals is what someone has actually done. Starting a company from scratch, and especially getting any traction, usually says something strong about ownership and motivation. Those are the characteristics that make people effective in front of customers, because they are driven to solve the customer’s problem and build good technology rather than just complete a task.

Ramp’s FDE function has grown from a handful of engineers to fifteen or twenty. I asked what changes at that size.

You have scaled the team from around five to fifteen or twenty. What do you have to pay attention to when you scale an FDE function?

My view is that FDE has emerged as a way to grow a B2B business, particularly through delivery to large customers. You cannot serve thousands of customers with dedicated humans, so the model is built around contracts large enough to justify dedicated engineering time. Scaling looks different at every organisation. Palantir is the extreme and the most mature.

Ramp’s FDE function is a little different from the more traditional version. We are oriented around unblocking our largest customers and helping us reach product-market fit in enterprise, rather than embedding a single engineer inside one customer for three to six months. Because we sit close to core product, it became impossible for everyone to be productive across the entire surface area. Ramp has a couple of hundred engineers, and no one can know every surface. So the way we scaled was to split into areas of specialisation and embed engineers in each. One team focuses on bill pay and procurement, another on the core card and reimbursement and expense experience, another on reading and writing data from Ramp in a low-effort, high-automation way.

Most leaders I speak to are trying to scale non-linearly, not just by hiring more people. Is there anything you can share about how you are approaching that?

The way you scale is by scaling with tokens, not headcount. Any time a human is doing something through their own cognition, you want that documented, you want the context available, and you want the read and write interfaces available to an agent, so that an agent can eventually do the work the human was doing. The fundamental requirement is getting context into a single place. We are heavy Notion users at Ramp, and I am excited about the shift from FDEs doing a lot of manual work to agents doing tasks on our behalf.

One concrete example. Every customer blocker or request for FDE involvement comes through a single Slack channel called FDE-Requests. In the past, someone from solutions or sales would write up notes and post them, and then we would wait, sometimes a day or two, for an FDE to pick it up, understand it, scope it down, and figure out what was needed. Now we have a Notion agent that searches our knowledge base, looks at past requests, categorises the new one, asks clarifying questions, and tags the submitter. We are starting the scoping process with an agent immediately.

To use a driving analogy, this is not full self-driving. It is closer to going from a manual to an automatic transmission. We are a long way from full autonomy on the request process, but that is the direction we are working towards.

In that fully automated world, what does an FDE actually do?

There will be plenty for FDEs to do. I am not worried about that yet. The first real challenge is managing the quality and token efficiency of agentic systems, and that architecture is not easy. Building high-quality agentic systems still takes real engineering. Agents do not just go and solve the world’s problems. You need people who understand how to do engineering well to craft and guide them. Eventually they may become stable enough that many people stop thinking about them, the way I do not think about TCP, IP, or DNS anymore. The internet just works, and we move on to the next problem.

The way the pipeline would look is a request comes in from solutions or sales, gets scoped down by an agent that is good at the back-and-forth of figuring out exactly what is being asked, possibly producing documents that go to the customer. Once you know the minimum viable request, another agent can scope the technical work by looking at the product roadmap, specs in flight, and where the feature would live in the codebase. Then a coding agent can execute and validate the change. You can imagine no human involvement from the moment a request comes in through to the feature being live. I think that is six to twelve months away.

Leo also runs Ramp’s Agent Developer Platform. He was clear it is separate from FDE, though it grew out of it.

You run the Agent Developer Platform too. How did that come about?

It is a little separate from the core FDE function, though it has roots there. On the FDE team we interfaced heavily with the developer API because we built on top of the platform, so we had a lot of opinions about it. I took on the developer API team about a year ago. It was clear that AI was going to massively change how you work with programmatic interfaces, so we started investing early in MCP and built our MCP server over a year ago. We ran experiments, including one a few months back where we had an agent try to run its own little business and use Ramp to pay for things. Those experiments into the boundaries of what the developer platform could be turned into what we now call the Agent Developer Platform. It happened gradually, and it originally came from FDE.

What changes when the customer interacting with the product is not a human but an agent?

It will still be a while, but we are seeing it more and more. MCP usage on Ramp has skyrocketed in the last six months. For about a year there were a lot of people building on MCP and almost no usage, but with Claude adoption took off. Having a good API is becoming a necessity. If you do not have one, you risk becoming obsolete.

At the same time, the interfaces humans see will become much more custom. If you think about the modalities for consuming information, audio has clear limits, text has limits too, and a two-dimensional visual representation on a screen is a very powerful interface that is here to stay. Humans will keep using software, but the experiences will become richer and far more specific to what the individual actually needs. A lot of the tedium people feel with software today, clicking through a checkout flow, waiting for something to load, should start to disappear.

Leo also invests and advises, mostly among founders he knows. I asked what he tells them about FDE.

You are an investor and advisor as well as an operator. What do you tell founders when they start thinking about an FDE team, and what do you pay attention to in the startups you work with?

Investing is a small part of my mind space. It started the way it usually does. Once you start a company and get some traction, your startup friends emerge, you exchange notes, you hire early employees who care about the world of startups, and many of them go on to found companies themselves. A lot of my first investments were friends and former early employees starting their own things. Living in San Francisco, you meet a new founder almost every day, so it is a fairly normal path.

The other part is knowing how much it means in the early days to have someone understand and support your vision. One of the first people who really believed in me and my co-founder back in 2020 was Ali Partovi at Neo, which has grown into one of the most impressive early-stage firms, early in companies like Cursor and Cognition and Kalshi. Having someone with some experience and standing say they get it, that they think you can do it, and then make introductions, meant a lot. Part of why you invest later is to pay that forward.

On FDE specifically, it is just a well-established business model now. If you are doing B2B, the biggest growth levers tend to come from landing large contracts, and that naturally puts you on the path to having an FDE function.

Most readers of this newsletter are still getting familiar with the role. Why do you think FDE is going to spread across so many companies?

It is the trend of the last year or two, and trends can change, but from what I can tell every early-stage B2B company with any enterprise ambition is creating something like FDE. They might call it something different. It is some combination of what large customers expect, how software is delivered, and how much easier coding agents have made the actual building. That mix of industry dynamics and the evolution of tech has created the role, and the growth has been an absolute explosion. I think it is roughly a hundred times year over year.

We finished where we started, with the path that got him here.

Last question. You have moved across physics, high-frequency trading, search, teaching, founding, FDE, and agents. Do you have a theory for why you have crossed so many domains, or did you just take what felt right at the time?

I actually don’t think my background is nearly as extreme as some people I’ve met, like a former colleague who dropped out of college, worked on video games, then high-frequency trading, then AI. I do not think my path is a wild outlier. Everyone is on their own path to find a place where the work aligns with their skills and values, and it took me a while to find what I was most passionate about. I have found something I feel I’m thriving in and highly aligned with now.

It is a big journey of self-discovery. Some people genuinely love big tech, the stability, the consistency, working on a specific set of problems that do not change dramatically over time. There is a wide range of archetypes for what people look for, and everyone should be seeking out the one that fits them, especially early on. Explore, and then exploit later.

Leo Mehr is Director of Engineering at Ramp, where he leads Forward Deployed Engineering and the Agent Developer Platform.

The coating project

We are working on a project in aerospace right now. The client receives metal parts that need to be coated according to a long list of industry specifications. Each part has its own attributes. The job is, given a part and the relevant specifications, to produce the exact sequence of steps to coat it correctly. A human engineer verifies the output before it lands in a system that walks factory workers through the steps on the shop floor.

I built it as a workflow.

Collection stage pulls the part attributes and the library of relevant specifications. Transformation stage does the structured extraction, the cross-referencing, the validation. Decision stage produces the ordered steps that get routed for human review. There are LLM calls at specific points where the work demands them. Everything else is deterministic.

It works. The client is happy with it. But sitting with it now, I think it probably should have been an agent.

The reasoning step is where the actual work happens. The combinations of part attributes and applicable specifications are too varied to enumerate, so the matching requires real judgement. I built deterministic plumbing around an LLM call that was making the only genuinely hard decision in the system, and then I added retrieval and validation layers because I wanted to verify each step in isolation. The result is more rigid than the underlying work needs to be.

An agent version would have given the model the tools to query specifications when it needed them and the room to iterate on partial matches. It would have been harder to verify. It would have shipped slower. And it would probably have been a better fit for the shape of the problem.

The direction of my errors

This is not an isolated case. If I am being honest about the direction of my errors, I have built workflows that should have been agents. I have not built agents that should have been workflows.

The cause is conservative bias. When I started building these systems, the models were less reliable, and every additional degree of freedom felt like risk. So I leaned toward deterministic flows with LLM calls at very specific points where I could verify each step. The systems shipped, the systems work, but some of them are more rigid than the problems they were solving.

I think this is also the bias I see most often in other practitioners. Engineers tend to over-constrain. We trust deterministic code more than probabilistic reasoning, and we reach for the workflow because it is easier to debug, easier to explain, and easier to defend in a postmortem.

That bias is becoming out of date faster than I would like to admit. The models today are reliable enough that some of the determinism I wrapped around them is doing more harm than good. It adds latency, it limits flexibility, and it papers over the fact that the genuinely hard part of the system is the reasoning step.

What changes now

If a coating project landed in my queue today, I would still draw the same shape. Collect the attributes, gather the relevant specifications, produce ordered steps, hand to a human. That part does not change.

What changes is how much determinism I would wrap around the reasoning stage. The question I would ask first is whether the work inside each stage is actually deterministic, or whether it requires reasoning over input I cannot fully anticipate. For the matching stage on coating, the answer is reasoning. That should have told me to give the model more freedom, not less.

The threshold for what counts as reasoning territory moves with the model. The systems I built when the models were less capable were workflows because I did not trust the models with more freedom. Today I would build some of them differently. The pace of model improvement now means architectural decisions in AI have a shorter shelf life than the projects that produced them. The build always has a sequel, and the sequel arrives sooner than it used to.

That framing is correct as far as it goes, but it’s also a tell. Frontier model capability has started to look an awful lot like a commodity, and the labs know it. Lock-in is the next move, and a multi-billion-dollar FDE army inside customer environments is the cleanest way to get it.

Capability is commoditising

There are at least half a dozen frontier-class models now, from OpenAI, Anthropic, Google, Meta, DeepSeek, Qwen, Kimi, and a few others, that swap places on benchmarks every few months. They’re all good. The marginal difference between the best model on a given task and the second-best is usually within the range of what a slightly better prompt or a slightly better retrieval pipeline would close anyway.

The economics tell the same story. Inference costs for equivalent quality are falling at something close to an order of magnitude per year. Anthropic’s gross margins came down to around 40% in 2025, from a projected 50%, and their break-even isn’t on the horizon until 2028. None of the frontier labs are profitable yet, and the unit economics on their consumer subscriptions are visibly under strain.

The Claude Code regression saga earlier this year is the cleanest community signal of where this is heading. Anthropic eventually traced the issue to three product-layer changes affecting Claude Code, the Agent SDK, and Cowork, while the underlying API was unaffected. Despite the post-mortem explanation, for me, Opus 4.6 was the peak, and the experience has felt downhill ever since Opus 4.7 shipped. The point is that we don’t actually know what we’re being served on any given day. The wrapper changed, and the people paying for it couldn’t tell. That isn’t unique to Anthropic. It’s the structural condition of paying a subscription for a service whose internals you can’t see.

When capability stops differentiating, and customers can’t fully trust that the thing they bought yesterday is the thing they’re getting today, the strategy has to shift. The play becomes embedding so deep in customer workflows that switching becomes painful even when it looks economically obvious. Microsoft did this for thirty years. The model labs are doing it on a compressed timeline.

Most enterprise AI work doesn’t need a frontier model

This is the part that doesn’t get said often enough. Most of what we actually deploy at enterprise clients isn’t frontier work. It’s classifying inbound emails into one of four categories. Extracting line items from invoices and matching them against purchase orders. Drafting first-pass replies to support tickets. Summarising call transcripts into action items. Routing tasks between systems. Reading a sales order and turning it into the right ERP transaction.

Almost none of this requires Opus 4.7 or GPT-5.5. A 7B to 70B open-weight model handles all of it well enough, and the gap between “well enough” and “best in class” usually shows up nowhere except in a benchmark sheet. The frontier earns its keep on a small slice of genuinely hard problems: novel agentic workflows, complex multi-step reasoning, edge cases that haven’t been seen in training, low-resource languages, long-context retrieval where every percentage point of accuracy compounds. In my work at Lleverage, across logistics, wholesale, manufacturing, insurance, and finance, that hard slice is maybe 5% of what actually lands in production. The other 95% is workhorse stuff that an open-weight model trained six months ago handles without anyone noticing.

I’ve been running Qwen, Gemma, and Mistral on my own hardware over the last few months. Not in production for any client yet, but enough to form a view. For the kinds of tasks I’d typically reach for a frontier API to do, they’re not quite as good, but they are good enough for the work most enterprises actually need done. Good enough is the only threshold that matters in production, and the gap to good enough closes faster every quarter.

A return to owning the machine

There’s a useful parallel here to the first wave of enterprise computing in the 1970s. The trailblazers were the companies that bought IBM mainframes when nobody else did, brought the machine in-house, built applications around it, and accepted the operational burden of owning the silicon, the workloads, and the upgrades. That model gave way to client-server, then to the cloud, where compute became something you rent. For two decades, owning the machine felt like an artefact of an older era.

I think AI is going to bend that line back. The companies that take this transformation seriously will, increasingly, buy ready-made machines for running LLMs and treat them as a core piece of their infrastructure, the way an earlier generation treated their first AS/400 or their first VMware cluster. Not for everything. But for the routine workloads that already touch sensitive data and don’t need a frontier model in the first place. The hardware exists in 2026 in a way it didn’t a year ago. NVIDIA’s DGX Spark, Apple’s M-series workstations, Lenovo’s ThinkStation PGX, AMD’s MI-series, and a handful of other options have made on-premise inference economical at a scale that wasn’t true even twelve months ago. A Quad DGX Spark setup runs roughly 18 to 20 thousand dollars and pays for itself in three to seven months for any team whose API spend regularly exceeds three to five thousand dollars a month.

The interesting consequence is that once you own the machine, the model running on it becomes a choice rather than a dependency. You can swap Qwen for Mistral for Gemma without re-implementing anything around it. The vendor relationship moves from the model layer down to the silicon, and silicon competition is, historically, a much healthier kind of competition than software lock-in.

The questions clients have started asking line up with this shift, even when nobody at the table uses these words. Where does the inference actually happen, on what continent, under what jurisdiction. Whose audit logs can you request. Whether anyone can promise the model isn’t being retrained on the data you’re sending it. A year ago these questions came mostly from engineering teams curious about latency. Now they come from procurement and compliance, and they tend to surface around the IT security review when somebody finally reads the fine print. The regulatory direction of travel reinforces the same shift. The EU AI Act’s high-risk obligations land in August 2026. France and Germany have launched a sovereign AI initiative with Mistral and SAP. The UK established a Sovereign AI Unit with up to £500 million of funding in mid-2025. The questions aren’t an early signal anymore. They’re the direction the rules are moving in.

Who actually does the wiring?

This is what explains why a $4 billion deployment company makes strategic sense even when frontier capability is commoditising. The bottleneck in enterprise AI isn’t the model. It’s everything around the model. The ERP that has no API. The operator whose tacit knowledge is the only documentation of how the process actually runs. The firewall rules that need re-negotiating with an implementation partner who left the client three years ago. The compliance team that needs to sign off on what data leaves which jurisdiction. The change management work that gets a sceptical operator to trust an agent’s output for the first time.

That’s the work. It’s what I’ve written about in almost every post on this newsletter. It’s unglamorous, slow, deeply context-dependent, and impossible to automate away. And it’s exactly what FDEs do. The reason OpenAI is willing to pay $4 billion to staff up an in-house FDE army is the same reason every AI company serious about enterprise revenue has been quietly building FDE teams for the last three years. The model is becoming the cheap part. Wiring it into a working system isn’t. The lock-in critique still applies, of course. Once an OpenAI engineer has spent six months inside a customer’s environment, mapping systems and building agents tightly coupled to OpenAI’s specific APIs, switching to a different lab stops being a model swap and becomes a re-implementation. That’s by design. It’s the same playbook every enterprise software vendor has run since SAP.

Which surfaces the bigger question. Who actually executes this transformation, across all these companies, globally?

Every mid-sized manufacturer, wholesaler, insurer, and logistics operator on the planet has to go through their version of what their bigger counterparts went through with the move from mainframes to client-server, and then again with client-server to cloud. The big four consultancies took the bulk of those last two waves. McKinsey, Bain & Company, and Capgemini being on the OpenAI Deployment Company cap table suggests they intend to take this one too. They have the relationships, the brand, and the procurement preference baked into thirty years of enterprise IT decision-making.

The trouble with that answer is that the work this time is more technical, more bespoke, and more dependent on the kind of context that doesn’t transfer well from one consultant’s slide deck to another. It’s FDE work. And there aren’t anywhere near enough FDEs on the planet to do it for every company that needs it. The OpenAI Deployment Company is starting with 150 engineers. Anthropic’s vehicle will scale similarly. McKinsey can throw people at projects, but the gap between a generalist consultant who knows the AI talking points and someone who can actually wire an agent into a customised ERP is real, and it’s a gap that doesn’t close in a quarter.

So who actually does it? The labs are betting on their in-house FDE armies, the consultancies on the relationships and bench they've built over thirty years, and the market is probably bigger than both put together. The question I'm sitting with isn't who wins. It's who gets the work done for the companies neither side is structured to serve.

I sit down with the customer to scope it. Within a week we’ve narrowed the wide outcome into something we can actually deliver in a meaningful timeframe. Then the pushback comes. “But you said you’d solve our whole invoice problem.” Not in those words always, but that’s the shape of it. The customer bought one thing. We’re now describing a smaller thing. Someone has to absorb the gap, and that someone is usually us.

This has happened often enough across our portfolio that it’s not a one-off. It’s the shape of a problem.

And the problem isn’t really at the scoping stage. The damage was done weeks earlier, before any FDE was in the room.

Every decision made in pre-sales compounds. A use case framed too widely in the sales call becomes a contract framed too widely. A contract framed too widely becomes a kick-off with mismatched expectations. A kick-off with mismatched expectations becomes a project that spends its first month renegotiating what it’s supposed to be. By the time you reach delivery, you’re not building. You’re recovering.

So we changed how we start.

Get an FDE in the room early

The first move was to stop letting sales scope alone.

This idea came from a recent conversation I had with Rahul Agarwal at Medplum, who runs his FDE team as what he calls sensors in the field. He described a rotating delegate system where one FDE each week is on the hook for early-stage sales calls, answering the “can it do X” questions across all prospects. The point isn’t to assign that FDE to any of those projects. It’s to make sure FDE thinking is in the room before the deal hardens.

We adapted this for our team of four. Every week, one of us is the rotating FDE. They join all pre-sales calls in the 30 to 70 per cent probability band. Below 30, it’s too speculative to spend FDE capacity on. Above 70, the project is real enough that we want a dedicated FDE rather than a rotating one. The 30 to 70 band is the window where the customer is serious but the scope is still soft, and that’s the window where an FDE can change the trajectory.

What does the rotating FDE actually do on these calls? They ask better questions than a salesperson would think to ask. Not because salespeople aren’t smart. We’re all chasing the same outcome, which is the biggest value we can credibly deliver. The difference is that an FDE can sharpen where that value actually sits, given what’s possible and what’s optimal to build first.

There are four things we want answered before a deal moves forward:

1. What does the process look like end to end today? Walk me through a single transaction, from trigger to completion. What systems are touched, what decisions are made, and by whom. This is the question that surfaces the gap between the label the deal was sold under and what’s actually going on.

2. Where does the data live, and who controls access? Which systems are involved. Cloud or on-premise. Are APIs available. Is there an external IT partner managing any of this. Integration risk and IT-partner dependency block more projects than anything else, and you want to know about both before you sign.

3. Who actually does this work every day? Can we speak to the operators, not just the champion or sponsor. How many people touch this process. Champions know what they want. Operators know how it works. You need both, and you need to confirm access to the second early.

4. What does success look like in three months? What specific outcome would justify the investment. How will the customer measure it internally. This forces them to articulate something concrete, and gives us a yardstick to scope against rather than an open-ended engagement.

The rotating FDE isn’t promising delivery. They’re often not even going to be the one delivering. The value of the rotation isn’t continuity. It’s that the customer hears these questions early, and the team gets to flag concerns before they get baked into a contract.

Dedicate an FDE before the deal closes

Once a deal crosses 80 per cent likelihood of closing, the rotation ends and one FDE takes ownership. Sometimes that’s the rotating FDE who’s been in the calls. Often it isn’t. What matters is that ownership transfers cleanly, and that it happens before the deal officially closes rather than after.

The reason for that timing is simple. The week between contract signature and project kick-off is wasted week. If a dedicated FDE is named once a deal looks close to certain, they can start absorbing context while the commercial paperwork moves in parallel. By the time the contract is signed, the FDE has been in the late-stage calls, has read whatever documentation exists, and is ready to run the kick-off.

Run the kick-off before doing anything else

The kick-off isn’t where work begins. It’s where we explain what work begins, and what we need from the customer before it does.

The kick-off has two jobs. First, set expectations for the engagement: what we’re building, what we’re not building, how we’re going to work together. Second, hand the customer their list. Credentials for the services we need to integrate with. Test environments we can break without consequence. Ground truth sample data, real cases the system should handle and real cases it currently gets wrong. A high-level overview of the process from the people who actually run it. Named partners in IT who can unblock us when we hit access issues, because we will hit access issues.

The customer then has one to two weeks to deliver that list. Nothing else happens in the meantime.

This sounds rigid and it is. The reason it’s rigid is that the cost of starting without the list is enormous and invisible. You begin building against assumed integrations, you discover the assumptions are wrong in week three, and now you’re rebuilding while explaining why the timeline is slipping. Or you start without ground truth data and ship something that works on the synthetic examples and falls over on the real ones.

If the customer can’t get us tool access in two weeks, that’s also information. It tells us something about how their organisation moves, and it predicts how the rest of the project will go.

Spend one to three days on site

Once the materials are in, we go on site.

The duration depends on the complexity of the process, which usually correlates with the contract size. One day for something narrow, three for something with multiple stakeholders and handoffs.

What we do on site is shadow. We sit with the operators who currently do the work. We watch them do it. We interview the champion, but we don’t only talk to the champion, because champions know what they want and operators know how it actually works. We ask questions that probably feel obvious to them and reveal things that aren’t obvious at all. Why do you check this twice. What happens when this field is blank. Who do you call when the system is down. Is there a spreadsheet on someone’s desktop that this depends on.

There’s no shortcut for this. Calls don’t surface it. Documentation doesn’t capture it. The tacit operational knowledge that determines whether a project succeeds is in people’s hands and habits, and you have to be next to them to see it.

A common worry is that this is paternalistic, or that customers won’t want us in their offices. In practice the opposite is true. Customers are usually relieved to have someone take their process seriously enough to sit with it. The ones who don’t want us on site are usually the ones whose projects we should be more cautious about anyway.

Define the scope

Only now do we write the statement of work.

By this point we’ve been in pre-sales calls, we’ve owned the project for two or three weeks, we’ve received everything we asked for, and we’ve watched the work happen. The scope we now write is grounded in that, not in the wide framing from the sales call. It defines what we will deliver to call the engagement complete, broken into specific capabilities with timelines and an estimated FDE budget. That’s the document the customer signs off on. Reaching the end of it is what ends the project.

Internally, alongside the full scope, we pick a first slice. Something inside the scope that we can deliver end-to-end in roughly a week, so the customer starts getting real value almost immediately. It might be ten per cent of the total scope, sometimes thirty, occasionally more. The exact size matters less than the shape: it has to be end-to-end, it has to run on real data, and it has to be something an operator can actually use rather than a demo we click through ourselves.

That first slice is deliberate. The point is to get something in front of operators that they can poke at, react to, complain about, and start building habits around. A live solution processing real data teaches us more in a week than months of planning. It surfaces the integration edges, the undocumented system behaviour, the IT-partner responsiveness, all of it, while there’s still time to do something about it. From there we keep building against the agreed scope, with each iteration landing in something the customer is already using.

Wide scoping at the start kills upsell. If phase one was framed too broadly and underdelivered, there is no phase two. A scope that’s well-defined and well-delivered is the only reliable path to the second engagement. Customers don’t buy more from teams that disappointed them on the first thing. They buy more from teams that shipped something useful in the first month and earned the right to do harder things.

What we’ve seen so far

We’ve run two projects through this full sequence. That’s not enough to call it proven, but it’s enough to notice that both have started cleaner than projects we ran the old way. Less mid-project reframing. Less of the conversation that begins with “but I thought you were going to do.” Faster path to a deliverable that an operator can actually use.

We’re going to keep running it and refining as we go. The four questions the rotating FDE walks into a call with will keep evolving. The criteria for what makes a good first slice are still being learned. The tradeoff between rigour and speed at the front of the project will keep adjusting.

But the underlying bet feels right. Everything that’s unclear early compounds. Every assumption left unexamined in pre-sales becomes an argument in week six. The leverage isn’t at delivery, where most teams focus their energy. It’s at the start, where most teams aren’t even paying attention.

Scope is a contract, not a conversation. The work we do before the build is the work that decides what the build will be. Clarity early is the cheapest part of the project. It’s also the part most likely to be skipped, because nothing seems to be happening when you’re waiting on credentials or sitting in a sales call you’re not going to deliver. But that’s exactly when the project is being decided. The build is just where the decision becomes visible.

You’ve now worked as an FDE at two quite different companies. How do the roles compare?

There are a lot of differences, and part of it boils down to the fact that Actively is an AI-native company that started as AI-native. Rippling is a SaaS company that’s existed for a while and is moving to be AI-forward. It is very much AI-forward now, but the archetypes are very different.

You see a lot of AI-native companies that are smaller, younger, newer, that emerged in the past two or three years and employ FDEs. And then there are these SaaS giants that have pivoted to be more AI-forward over the last couple of years. Rippling is an example. Ramp, Salesforce, Databricks and Snowflake all have FDEs now. These are companies that existed for years before AI adoption was the thing.

The role differs quite a bit between the two. At a smaller AI-native company the day-to-day work is heavily agentic, heavily focused on building the AI product itself. At a larger company it’s AI-focused too, but you’re also building custom code on top of a mature platform for a particular customer. The platform is more mature, so you can.

At a younger company you also do a lot more pre-sales POC work, because the company is still trying to find its footing. At Rippling there isn’t really time for that. There are already so many customers and a robust sales motion that handles winning the deal. Your job becomes filling in gaps in the product for a given customer, rather than putting time and effort into convincing someone to sign.

At Actively you had a 100% pilot-to-paid conversion rate. What does it actually take to get a pilot to convert?

The main purpose of a pilot is to prove out ROI. And with AI that can be tricky. You can talk about boosting productivity, or boosting revenue, or moving some other metric. But at the end of the day it needs to tie back to the P&L. You’re paying us X, we’re netting you Y, and Y needs to be much greater than X for you to be convinced to buy.

The customer is usually evaluating other tools in the space at the same time. So the path you take as an FDE is not just implementing the thing. Before you even implement it, you decide on the metrics with the customer. If we can prove out this percentage increase on this productivity or revenue metric, that is the success criterion for this POC.

It’s hard to measure AI workflows. You can’t just run the pilot for a month and at the end say, here are the reports. It has to be something you track from the beginning. Some metrics are genuinely impossible to track, but as much as you can, you need to be forthcoming with the numbers. It’s less of a technical problem than it is about managing customer expectations and building trust in the fact that you’re both looking at the same metrics.

On the POC itself, do you prefer to go narrow and end-to-end, or wide with a big magical moment?

Narrow and end-to-end, almost always. You prove out one part of the product that truly works, with measured metrics against it. You acknowledge there are other parts of the product that will have tangible or intangible benefits over time, but you have one clear thing to measure against.

The risk with going wide is that you don’t actually end up proving ROI, because that isn’t how the product will be used in practice. You can also build something so bespoke to one person’s workflow that it just doesn’t generalise. Starting narrow also sets up the next conversation. If you delivered something concrete in a week, it’s easier to make the case for what five weeks would look like.

How do you handle context gathering? No FDE I’ve spoken to has managed to collect everything up front.

I don’t think the answer is getting 100% of the information you want up front, and I don’t think it’s unique to being an FDE. This is a customer success problem that’s existed for as long as companies have been working with each other.

It does become easier in the age of AI. If the customer is already using AI tools, or has a bunch of documents scattered everywhere, you can ingest it, build a vector database, index it, and get somewhere. But the business end of it is never a technically hard problem. It’s that they don’t know what to send over, and we don’t know what they have unless we ask for it.

The approach I like is separating it into high-level and low-level. You have an initial high-level discussion to determine feasibility, scope the work, and agree on an architecture. Once you have that, you have enough confidence to move into implementation, where the nitty-gritty details surface.

A common one is approval processes. A lot of them are very unique to a business. It’s not even based on roles, it’s “Samantha is the approver here.” And what happens if Samantha leaves? Who knows. That kind of data isn’t something you can scope up front. You just have to know, going in, that someone is approving this, and build to that shape. You figure out who the someones are later. By asking the big questions you get 80% of the way there. The last 20% is what’s painful, and it just sits in the tail of the project.

When is a project actually done? How do you close the loop without endless scope creep?

This was something we had to figure out at Actively, because we would never stop. At Rippling we realised we needed a harder boundary, otherwise the model doesn’t scale.

The way you solve it is the way any SaaS product tends to solve it. Contracts and guidelines that outline the scope. This is what we are going to deliver. Once we deliver it, your problem should be solved. The initial scope becomes a document both parties sign and are beholden to. It works the other way too. If we don’t implement what we said we were going to, you can hold us accountable.

Whether the scope document is pre-commercial or post-commercial doesn’t really matter. I’ve talked to FDEs at other SaaS companies and it varies a lot. There is a difference in how much leverage you have in that conversation depending on the stage of the company. A larger, more established player can push back on scope in a way that a seed-stage company doing forward deployed work simply can’t, because they don’t yet have the leverage.

The FDE job description tends to read like a unicorn spec. Kanav spent almost three years at Amazon before moving into the role.

What was the hardest part of that transition, coming from a core software engineering background?

Two things stood out. The first was context switching. Whatever size of company you’re at, as a core software engineer you have layers of separation from the customer. PMs, sales, customer success, sometimes your own manager. That shielding lets you dive into your technical environment, and that’s what it was for me at Amazon.

As an FDE you might be on one customer call right now, another half an hour from now, and you have that half an hour in between to code something. You never get to truly lock in. That’s a hard skill to master, and I don’t think you fully can. Humans have a context window, like agents do. You try to minimise context switching where you can, but you also have to build the muscle of doing both parts of the job.

The second thing was interfacing with customers directly. You think there’s always a layer of separation, where you have to be professional because you’re representing the company. But true discovery happens when you’re fully comfortable with the customer and they’re fully comfortable with you. Being able to embed in their process, learn their business immediately, pick up the nuances of it, and ask the right questions to get them to open up. That’s a muscle I had to build over time.

On the depth question, Palantir is famous for sending FDEs to embed with one customer for months at a time. That’s obviously not feasible at most AI companies. How do you think about depth versus breadth?

Unfortunately, it isn’t really something you get to decide as a company or as an individual. It’s decided by account size, by ACV, by ARR. It becomes a question of economics. Whether you can afford to embed a whole FDE into one customer’s workflow.

Palantir is one of one. As you move to AI companies, or AI-forward companies, the FDE almost always has to manage multiple implementations in parallel. With the Palantir model, you have the advantage of learning one business really deeply. With the multi-customer model, you want depth but you also need breadth. Over time breadth becomes more important, as does the ability to pick up new things about new businesses quickly.

If you’re dealing with a large enterprise tech customer versus a big restaurant chain versus a retail store, their workflows differ drastically. You have to be able to pick it up and embed in all of them at once. You probably won’t reach the same depth as someone working on a single project. But that isn’t within the control of an individual. It’s dictated by the economics of the situation.

We’re software engineers by training and we tend to aim for close to perfection, but the role doesn’t always allow it.

It’s something you have to get used to while using AI products anyway. A lot of traditional software is deterministic. AI products mostly aren’t. You can make parts more strongly typed, you can build strict guardrails around certain components, but as a whole, software is moving in a non-deterministic, directionally correct direction. That has to be good enough. Even if most of your end-to-end solution is deterministic, one probabilistic link makes the whole solution probabilistic.

You’ve described the FDE role as a kind of founder bootcamp. Why?

I’ll call on what one of the co-founders at Actively used to say. There are really only two things that make money if you think about it abstractly. Building things and selling things. Engineering and sales. The FDE role sits right in the middle of that.

A founder goes through a process where they’re building a product and also doing customer discovery. Who wants this, what are their pain points, what would help them do things faster, or eliminate manual work. You figure that out in the customer discovery part, but you also have to immediately tie it back and build it. That’s what I feel like I do every day, whether it was at Actively or now at Rippling.

At both companies I’ve had the benefit of a sales team and a core product team supporting me. My job is to create the link between them. Because of that link I’ve learned a huge amount about the sales process that I never would have as a core software engineer, and a lot about building things I wouldn’t have picked up in sales. And it isn’t only sales. It’s marketing, customer success, RevOps. All these teams I converse with and learn from, whose workflows I end up observing. The same thing on the engineering side. It isn’t just building. It’s making product management decisions, small ones, but real ones, to build the software correctly.

You do a little bit of everything. And as such, it helps you build the skills to run your own company one day.

Anything you’d want other FDEs to keep in mind?

The role is still rapidly changing. If you discount Palantir and look only at the AI world, the oldest FDEs at AI companies are maybe a year in. Everyone is still figuring out processes. Part of the job is understanding that this is a role filling a gap that exists right now. AI makes it easier to build software and easier to talk to customers, so I think the role is here to stay. But what the FDE role looks like now versus a year from now could be very different. The core products we use and the industry we’re in are changing that fast.

Kanav Bhatnagar is a Senior Forward Deployed Engineer at Rippling, where he’s on the founding FDE team building out the function from the ground up. He was previously an FDE at Actively AI and a software engineer at Amazon.

The playbook for scaling a team used to be pretty simple: revenue goes up, headcount follows, hire enough people to cover the volume, then hire more to manage the people you just hired. Everyone understood the math, boards expected it, and forecasts were built around it with almost no questioning of the underlying assumptions.

That model is broken, and I don’t think it’s coming back.

Let me tell you about a project I saw running at every enterprise I worked with over the last decade. None of this will be new to you.

They called it different things: company ontology, knowledge graph, single source of truth, shared data model. Different vocabulary, same project: get the entire organization operating from one common language. Product called them “customers.” Finance called them “accounts.” Customer Success called them “clients.” Legal called them “counterparties.” Four words for the same human being, living in four different systems, with four slightly different definitions of what counted as active, churned, or at risk.

The result: most of the coordination overhead in a large company isn’t strategic, it’s definitional. You’re not having a meeting to make a decision; you’re having a meeting to establish what the numbers even mean before anyone can start making a decision, then scheduling a follow-up because someone pulled a different number from a different system, and by that point the actual work has been sitting untouched for two weeks. This is the information layer that runs through humans because there was no other place for it to live.

AI (properly implemented) has changed the cost of fixing this dramatically. You don’t have to perfectly unify every system before you start getting value; you can build a working model of how your organization describes itself, connect it to your preferred AI provider, and the CS manager who used to spend three hours hunting down renewal data and the QBR template to copy from, can query it and create the deck in four minutes. The constant “hey, what’s going on with X” that accounted for 40% of most people’s communication overhead largely disappears. That’s the setup. Here’s the framework that actually determines whether any of it matters.

The four tiers. Embarrassingly simple, almost universally ignored in the right order.

1. AI it.

Try this first, always, even when you’re confident it won’t work. The attempt is the point, because even when it fails it usually tells you something useful about the underlying process that you didn’t have explicit language for before.

What this looks like in practice for anyone in post-sales or implementation work: drafting account health summaries, generating first-pass renewal risk assessments, summarizing call transcripts into action items, building the skeleton of a QBR deck, triaging incoming tickets/customer requests by urgency and category, writing the first draft of a playbook that a human then edits. The output isn’t always usable. An 80% draft that takes two minutes still beats a blank page that takes two hours, and more often than not, the 20% gap is specific and fixable rather than fundamental. When AI fails at a task, the failure is almost always informative: it’s pointing at the part of the process that was never clearly defined in the first place.

The biggest mistake here is treating “it didn’t do it perfectly” as a verdict. It’s not a verdict; it’s a data point about the process.

2. Automate it the old way.

Rules, triggers, scripts, workflows. Pre-2023 thinking, still valid and still underused for anything deterministic. If the output of a process is predictable given a set of inputs, a human should not be the mechanism that connects them.

Most organizations have already paid for this capability and aren’t using it. If a support ticket comes in with a specific keyword from a customer in a specific segment, it should route automatically. If an account’s health score drops below a threshold, something should happen without anyone manually noticing and then manually deciding to act. If a contract hits a 90-day renewal window, the motion should start on its own. These are not complex problems; they’re rules that nobody built because defaulting to a human was easier than writing the rule once.

The 90% of SaaS tools you’ve already bought are effectively capable of doing this, or were designed to. Salesforce workflows, HubSpot sequences, Zendesk triggers, Gainsight playbooks. The access is there. The will to sit down and configure it usually isn’t. That’s the actual gap, and it’s a choice gap, not a technology gap.

And increasingly, tier one can handle the setup and configuration of tier two for you, which blurs the line between them.

3. Write a better SOP.

If a human genuinely has to do it, at least make it repeatable, trainable, and documented well enough that the next person doesn’t have to rebuild it from memory. The teams that are hardest to automate are almost always the ones that never wrote anything down; you can’t AI a process you haven’t described, and you can’t automate a workflow that exists entirely inside one person’s head.

These SOPs matter beyond the immediate documentation value: they’re the training data for whatever comes next. Every process you document today is a process you can hand to an agent later with something approaching confidence. The teams skipping this step aren’t just making their lives harder now; they’re making the transition to tier one harder when it becomes unavoidable.

4. Throw a person at it.

Hire someone, add headcount, default to humans. This is the right call for a narrow set of things. Judgment calls where someone needs to be personally accountable. Relationships where trust is the product. Situations where the context is too specific and too recent for any system to have it. An enterprise renewal going sideways because of an executive relationship problem is a tier-four problem. A QBR deck is not.

The problem isn’t tier four existing; it’s that it became the default for everything, including work that isn’t complex, high-stakes, or relationship-dependent. Tiers one and two were either never seriously attempted, or when they were, expectations were miscalibrated and solutions were designed by humans who assumed human involvement was necessary, which is a surprisingly hard assumption to challenge when you’re the human doing the designing.

For most of the last decade, tiers two through four were the real options, and the mature move was knowing which tier a problem belonged in. That’s not quite the situation anymore. Tier one is now a mandate, coming loudly from every CEO in every all-hands, which is not a strategy; it’s a mandate, and mandates without methods don’t produce what the people issuing them want. The organizations that actually get there are the ones where individuals built the habit before anyone told them to. Tier two is still valid and underused, especially now that the technical barriers to accomplishing them are effectively non-existent. Tiers three and four are becoming the exception, and the only work that should land there is work that has genuinely exhausted the first two.

I think this is where it’s heading: the healthiest org you can show an investor is one where 70% or more of your headcount is built around humans (employees) talking to other humans (customers/suppliers). The remaining 30% is the rest of the org, and even that number gets blurry, because as AI absorbs more of the operational and analytical work, roles like engineering, marketing, and product naturally spend more of their time interfacing with customers too. The metric I’d start watching: what percentage of your people woke up today and actually talked to a customer? That number should be going up.

The scaling playbook isn’t gone; it’s just running on different assumptions. Start stress-testing AI against your own work, not because your company told you to, but because every attempt builds a reflex that’s going to matter for the rest of your career. Even when it fails, especially when it fails, you learn something about the process you didn’t know before. That muscle comes from repetition, not mandates.

That’s pretty much the whole job now.

Rory O'Brien is an advisor and fractional CXO for seed to Series B startups, with 15+ years scaling post-sales and customer experience organizations. He previously served as VP of CX at HappyRobot and Tonkean, where he built and scaled FDE/Implementation, deployment strategy, and customer experience teams. You can find him on LinkedIn, Substack, and X.

To set the scene for readers who don’t know Medplum, what do your FDEs actually do day to day?

Medplum is an open source healthcare toolkit for developers. We make a set of Lego blocks for the most common healthcare applications, mostly EHRs, the systems doctors and nurses use to document clinical notes and order lab work and prescriptions. There’s a whole new breed of digital health companies building these at scale, fifty states, tens to hundreds of thousands of patients a month, but only for a narrow slice like specialty pediatrics. They need bespoke solutions. We took what a standard EHR does, exploded it into modules, made them open source, and let developers at these companies put the pieces together for their care model.

The hard part for our customers is making all those choices. Our FDEs have to be highly technical because they’re working with developers on the other side. You can’t just be a product person. A lot of our daily interactions are, “what is this error message, why didn’t my lab order go through to the lab.” But they also have to be good with people. Each of our FDEs supports between five and ten customers. We don’t send a team to a customer. One FDE supports many.

We didn’t found the company saying we’d have engineering, product, FDE. We don’t actually have a product team right now. The FDE function was born out of necessity, which I imagine is true for most companies hiring FDEs.

Most FDEs I speak to work directly with operators. Yours work with engineers who are building products for operators. How much harder does that make it to surface the tacit operational knowledge healthcare is famous for?

It’s a real challenge. The ideal is that engineers are our day to day but we have direct access to operators too. In healthcare there are two flavours. There’s clinical staff, the doctors and nurses doing care. And there’s an operational layer doing scheduling and billing, making sure patients move through the workflow. We want to get to both, or at least have a champion who can give us ground truth on the actual workflow.

Our engineering counterparts are strong developers but they’re often new to healthcare themselves. They don’t always know the right questions to ask. And when you do talk to operators, they describe how they currently do things, not how things should or could work. A lot of doctors at digital health companies aren’t doing it as their day job. They work in a hospital during the day and take telehealth visits on their off days, so when you ask them to design a system they bring all the baggage of their day job into the company.

So there’s a balance. We have to earn the right to talk directly to product or to clinical, but we also don’t want to get sucked into talking to ten physicians ourselves. Someone has to own the synthesis, and someone is always going to be unhappy with the result. We’d rather the customer’s internal stakeholders own that decision, with us guiding them based on best practice.

The reason that synthesis question is so loaded is that at Medplum, the FDE team is also doing the work a product organisation would normally do. I asked Rahul to walk me through how that actually functions.

Your CEO Reshma has talked publicly about Medplum running without traditional product managers, with the FDE team being how customer reality gets into the product. How does that actually work?

We probably won’t have PMs for at least another year. I’m not saying never, but FDEs are sensors in the field. They’re with customers every day, so they have a strong understanding of what customers need.

The challenge is combining those needs into generalised feature requests rather than building a hundred features that look almost identical, where this one is the way customer one wanted it and that one is the way customer two wanted it. That’s part of the argument for keeping core engineering separate. They have to build things that are general purpose by necessity. The organisational challenge is the connective tissue between FDE and core engineering.

Everyone has access to all code bases. FDEs are encouraged to contribute to the core. There’s no gatekeeping. It’s a division of labour.

The core engineering team has a weekly standup, and we send one rotating delegate from the FDE team to it. The FDE team does pre-work the day before to collate all the burning issues from customers and stack-rank them into one unified list across all features and all customers. The point is to avoid the anti-pattern I see at other places where every FDE is advocating for their own customer at the expense of others. If everyone goes directly to engineering and throws a ticket over the fence, the squeakiest wheel gets the grease. “Oh my God, this customer needs this tomorrow, this one is a high revenue deal, we need to do this thing that we all know is a bad feature.”

We make intentional tradeoffs among the FDEs. I know this customer is upset, but I will take the heat. We can talk about workarounds until the right thing is built. The unified list also gives the whole team visibility on what’s being requested. So if you hear a request that sounds like one from another customer, you have the familiarity to say, that feature is already in development, the thing in flight will suffice.

That’s how we do reconciliation without product managers. We might need PMs in a year as the team grows and these meetings stop scaling. But adding another layer is just another game of telephone between customer, FDE, and engineering. We’re trying to reduce telephone, not add to it.

One of the failure modes I hear about is core engineering and FDE turning into adversaries. How do you avoid that?

It’s a real anti-pattern. Core engineering starts to think FDE is always asking for everything tomorrow, because customers ask for things on customer timelines, not six-month timelines. The FDE team starts to think core is too slow, too much exploration.

The rotating delegate is partly an empathy-building exercise. Everyone gets exposure to engineering, inside their standard processes. You have to understand the trade-offs. If we did this the quick and dirty way, here’s what we lose. As a leader, you can say these are the same function with different responsibilities, but the teams have to actually trust each other. The FDEs need to understand that even if their customer needs something tomorrow, a hacky implementation has long-term costs. Core engineers need to understand that not everything can be perfectly designed, that there are real commercial factors and real customer pain. Even when customers aren’t doing things the way we’d like, they’ve made certain choices and we have to support them within a framework.

The other piece is the narrative inside the company. Even if it’s not true, the story can develop that FDEs are lower-quality engineers, body shop. Keeping the technical bar high is one defence against that. It’s easier said than done because you’re already asking for people skills and product judgement on top of engineering. But the bar matters.

You’ve got a public repo, a Discord, an issue tracker, paying customers and enterprise contracts running in parallel. Where does the FDE responsibility actually start in the customer lifecycle?

It’s a bell curve where the tails extend to infinity, but there’s a middle. We have a delegate to the sales process the same way we have one to engineering.

The sales process for an enterprise platform like ours has distinct phases. The first is, “hi, how are you, is this even a fit.” Salespeople handle that. Then there’s a technical capabilities Q&A. “Can it do this, how would it handle that?” I call it the “can Medplum do X?” phase. The important thing is that it’s stateless. It’s more about us than about the customer. So in that phase we have a rotating FDE on the hook for whatever calls come up that week, just to answer can-it-do-X questions across all prospects.

As we get deeper into the funnel, around a seventy per cent chance of close, we pre-assign a dedicated FDE. That’s before the deal actually closes, because close itself is fuzzy. There’s close-a-pilot and there’s close-for-real. By that seventy per cent mark things get stateful. You have to know a lot about the customer’s care model, their business model, their legacy system, their migration challenges. So we assign the dedicated FDE then, and by the time real building starts that person is already ramped up. Earlier than that, when they’re just kicking the tires, it’s too noisy to pre-assign.

Once the deal closes and the project starts, how do you make sure you have enough context to build the right thing?

That is the fundamental challenge. You need to get all the way into the belly of the beast of the customer, really understand what they want, what they need, even when they’re not asking for it. The key skill is telling them what they should be building (based on our experience), not just what they asked for.

The methodology we use is what we call our enterprise workshop. It works under the assumption that you’re not going to know everything. The goal isn’t to spend three months gathering all the context. You won’t, you never will. The goal is to prove that our product solves a problem in a very short time. We target one to two weeks.

When I tell customers we’re going to pick one thing and build it in two weeks, people lose their minds at first. “That’s too small. We’re a core system of record, we expected Medplum to solve all these problems.” But three months is forever. People dilly-dally until the last month anyway. They’re slow to respond, slow to get you information. By reducing the scope to one or two weeks, it forces customers to think smaller, and to actually pick one problem instead of saying everything is high priority but nothing is actionable. Decision-making on the customer side is the slowest part of all this. We can always match or exceed the customer’s energy.

The problem we pick has to be end to end, from user to back end, not three back-end features with no user input. And it has to be something better than their existing system, not a re-implementation. I want to focus on why they came to us in the first place. Their old system can’t do X, that’s why they’re considering us, so let’s work on X first.

Sometimes in two weeks we can’t get real usage, but we did force their engineers to talk to their clinicians and to their ops team. It sounds paternalistic, but I think of it as the connective tissue. Now they know how to build on Medplum, and they know who needs to be consulted for the rest. Over the following months they’re often already accelerated by that connective tissue alone.

If you were hiring your next FDE tomorrow, what’s the signal that matters most? And how much does healthcare background matter?

We assume no healthcare background. I had none before I started this company. My co-founders did, which was essential as a founding team, but we don’t require it.

When we hire we think about slope versus Y-intercept. We’re looking for high-slope people who have demonstrated they learn fast, that they’re motivated to own a whole thing and eat pain. They don’t have a lot of preconditions about what their work looks like.

Give me an example of someone who showed that.

A few stories. We have one person who was in an engineering department at their previous company and had been told not to talk to customers. Just focus on your job, head down. They learned a customer was suffering, disregarded orders, went and built the feature, and then built the internal buy-in for the broader migration. When the thing shipped and they wanted to follow up, the customer manager said that’s someone else’s job. But they wanted to break the mould and actually solve the problem.

Others came from more traditional sales engineering or solutions backgrounds and volunteered for the hardest customers. There are always little bugs at go-live, and they were the ones running into the fire. With others you just see them going beyond their job description. Even when they handed something off to a salesperson, they followed up to make sure the problem actually got solved, not just that they did their job.

A lot of leaders starting FDE teams now don’t have an FDE background themselves. What’s your advice to them?

I get the question a lot. Is FDE product, sales, engineering? There are different ways to make it work, but my bias is towards engineering. Treat it as an engineering function. Putting the team structurally inside engineering is one defence against the cultural anti-patterns. Keeping the technical bar high is another.

The rest is in the messaging. I deliberately use the terms division of labour and separation of responsibilities. These are the same function with different jobs to do, not different tiers of engineer. A leader can say that, but the teams have to actually live it, which is why the rotating delegate exists. It’s as much a trust-building ritual as it is a process.

Hiring is one thing. Keeping good FDEs is another. People don’t talk enough about retention. How do you keep someone who’s an excellent engineer, a good communicator, and has product instincts, when on paper they could do anything?

At least once or twice a month when I address the team, I remind them that FDE is basically founder school at Medplum. You’re going to be so pluripotent. You’re working on sales, you’re at the head of commercial conversations, you’re doing tech, you’re doing product. You’re already doing all the functions. If you put your founder hat on, even if you’re not an expert in all of them, you’ll have enough familiarity to go found your own company, hire those roles, and have judgement over them.

So it makes the good ones really hard to retain. If they’re good they’re going to go off and do their own thing at some point. I have to price that in and just keep hiring. We haven’t had churn on this dimension yet, but I’m not holding my breath. In some ways we’d want it to happen, to know we’re providing an environment that grows people.

I had this problem when hiring FDEs myself. Everyone I grew up with at Palantir has founded their own company. I can’t get my best FDEs to come work for me because they have their own companies.

The other thing that helps is that because we hire more for slope than Y-intercept, we can accept slightly more junior candidates than we would on the core engineering side. That creates a real opportunity for mentorship. We’ve defined an FDE lead role and an FDE mentor role. New FDEs need to hit the ground running. If I’m putting them in front of a customer in two weeks, they have to own those customers within the first one to two weeks. There’s a lot of content knowledge involved. Rather than me teaching them everything, senior FDEs mentor junior FDEs. So we’ve built a progression in, where you’re responsible not just for your own customers’ outcomes but for your mentee’s outcomes too.

Anything else you wanted to share?

One thing on AI and agentic coding. The question I always get is whether that means FDEs can be more or less technical because of the coding tools. I’m coming down conclusively on more technical. If an FDE is technical enough to actually read our codebase and understand the architecture, not just talk about it, they can sometimes ship a small bug fix in between meetings. We just got off the call, we already filed the fix, and because we’re open source we can point them to the PR. As a developer tool, there are so many small one-off things, and shortening that cycle is where the delight comes from.

Rahul Agarwal is co-founder and COO at Medplum. He’s hiring FDEs in the San Francisco Bay Area.

I’m trying something new on FDE Hub. Alongside my own writing and interviews, I want to start sharing work from other people writing about Forward Deployed Engineering and adjacent roles. There’s a small but growing group of us thinking and writing about this craft, and the more we can cross-pollinate, the better for everyone trying to figure out what this work actually is.

First up is Prasad Rao, who writes Big Tech Careers. Prasad spent years as a Principal Solutions Architect at AWS and has been covering the Solutions Architect and FDE roles from the angle I don’t really touch on FDE Hub: how to break in. His audience is largely engineers and architects looking to level up their careers, and his pieces on the AI FDE role have been some of the clearest writing out there on what these jobs actually require on paper.

I write a lot about what FDEs do once they’re in the role. Prasad writes about how to get there in the first place. The two perspectives complement each other well, and I think his piece below is one of the most useful things you can read if you’re either considering an FDE role or trying to understand what hiring teams at the big AI companies are actually looking for.

Over to Prasad.

— Milos

This is a follow‑up to my earlier article on transitioning from Developer/Architect to AI FDE roles. In that piece, I argued that the knowledge gap is smaller than you think if you already work as an Solutions Architect (SA) or Software Engineer (SWE).

In this article, I go one level deeper: I analyze what AI Forward Deployed Engineer–style roles actually look like at five of the most sought‑after companies—OpenAI, Anthropic, NVIDIA, Databricks, and Salesforce—and distill the skills you really need to break into them.

You’ll notice a pattern: the core skills are the same, but each company has its own weightage for each of these skills that they look for in candidates.

The Common DNA: What All AI FDE Roles Expect

Before we pick apart company‑specific nuances, it’s worth summarizing the shared core of these roles.

Across these five companies, an AI FDE is expected to:

• Embed with customers or strategic internal teams, not just sit in a central platform group.

• Own end‑to‑end delivery: discovery, design, implementation, deployment, and post‑go‑live iteration.

• Work directly with modern LLM tooling: RAG systems, agents, vector stores, observability, and cost controls.

• Translate messy business requirements into durable technical systems and then back into business value.

• Operate under ambiguity, time pressure, and partial information.

As you can see, these are combination of SA, SWE and AI skills including both technical and behavioral skills.

OpenAI: Deep AI Fluency + Full‑Stack Ownership

Positioning: OpenAI’s forward‑deployed roles skew toward high‑stakes, high‑impact deployments with customers who are building on top of frontier models. The expectation is that you act as both a product engineer and a field architect.

What they really test for:

• LLM depth, not just API usage

  • Solid understanding of tokenization, context windows, function calling, system prompts, rate limits, and failure modes.

  • Ability to choose between RAG, fine‑tuning, and prompt‑engineering tradeoffs and justify them with cost/latency/quality reasoning.

• Full‑stack + infra skills

  • Comfortable shipping production systems: backend (Python/TypeScript), basic frontend (React/Next), infra (Docker, K8s, cloud).

  • Can design data pipelines for logging, analytics, safety signals, and feedback loops.

• Customer‑facing ambiguity handling

  • You walk into “we want AI” conversations and shape them into concrete use cases, milestones, and guardrails.

  • You’re comfortable saying “no” to unrealistic expectations while offering a simpler path that still delivers value.

How to prepare for OpenAI‑style FDE interviews:

• Build and ship at least one real product on OpenAI APIs (not a toy chatbot): for example, a workflow assistant with RAG, role‑based access, analytics dashboard, and guardrails.

• Be ready with case studies that show: discovery → design tradeoffs → shipping under constraints → post‑launch iteration.

• Practice explaining LLM tradeoffs to a non‑technical VP in simple language.

Current FDE open roles at OpenAI

• https://openai.com/careers/search/?q=FDE

Anthropic: Safety‑First Applied AI + Long‑Term Customer Stewardship

Positioning: Anthropic’s forward‑deployed engineers lean heavily into applied AI with a safety and reliability lens. You’re expected to think about not just “does it work?” but “does it behave safely and predictably under pressure?”

What they really test for:

• Applied AI engineering with a safety mindset

  • Familiarity with Claude‑style models, safety policies, red‑teaming concepts, and failure‑mode thinking.

  • Ability to design flows that mitigate prompt injection, abuse, and misuse scenarios.

• Structured reasoning & evaluation

  • Designing evaluation harnesses, test datasets, and metrics for “quality” beyond simple accuracy: helpfulness, honesty, harmlessness.

  • Iterating on prompts and policies in a structured, data‑driven way.

• High‑trust, long‑term client relationships

  • You’re more steward than “hit‑and‑run” implementer; you help customers evolve their AI maturity over months, not just ship a single feature.

  • Strong written communication: architecture docs, safety considerations, decision logs.

How to prepare for Anthropic‑style FDE interviews:

• Build at least one “safety‑aware” AI feature: think moderation, red‑teaming tools, or evaluation dashboards that track failure modes, not just latency.

• Prepare stories where you caught risks early (data misuse, policy issues, security gaps) and navigated them with stakeholders.

• Practice walking through how you’d design an AI system for a regulated domain (finance, healthcare, gov) and what safety levers you’d include.

Current FDE open roles at Anthropic

• https://job-boards.greenhouse.io/anthropic?keyword=FDE

NVIDIA: Systems‑Level Performance + AI Infrastructure

Positioning: NVIDIA’s forward‑deployed/architect roles are closest to AI infrastructure and performance engineering. Instead of “which prompt?” the conversation is often “which GPU, which optimization, which deployment pattern?”

What they really test for:

• Strong systems & performance orientation

  • Comfortable reasoning about GPU utilization, batching, concurrency, throughput, and cost per token or per request.

  • Understanding of how model choices, quantization, and deployment frameworks impact latency and cost.

• Platform and ecosystem fluency

  • Familiarity with NVIDIA’s AI stack (CUDA basics, Triton, TensorRT, NIMs, etc.) is a strong plus.

  • Bonus points for comfort with multi‑cloud deployments and hybrid/on‑prem setups.

• Architect‑level customer guidance

  • You can sit with a customer’s infra team and co‑design reference architectures that fit their budget, latency needs, and compliance constraints.

  • You’re credible in conversations with both CTOs and senior infra engineers.

How to prepare for NVIDIA‑style FDE/architect interviews:

• Take an existing LLM application and run simple performance experiments: batching, caching, model size swaps; document how these affect latency/cost.

• Learn at least one NVIDIA‑branded component end‑to‑end (e.g., deploy a small model using Triton or a NIM‑style setup) and be able to explain the architecture.

• Prepare a “customer workshop” style narrative: how you’d guide a bank or telco from “we want AI” to a GPU‑backed architecture.

Current FDE open roles at NVIDIA

• https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite?q=Forward+Deployed+Engineer

New to Big Tech Careers? Join 26,000+ subscribers to elevate your tech career through behavioral skills!

Databricks: Data + GenAI + Enterprise Platforms

Positioning: Databricks’ AI Engineer / FDE roles sit at the intersection of data platforms and generative AI. Think “build AI on top of the lakehouse and ship it into customer workloads.”

What they really test for:

• Data engineering + GenAI hybrid

  • Strong skills in Spark, SQL, and data modeling, combined with hands‑on experience building RAG/LLM apps.

  • Ability to design retrieval over large enterprise datasets, not just a handful of PDFs.

• Platform thinking

  • You don’t just hack a one‑off script; you build reusable patterns that can be productized or repeated across customers.

  • You understand how feature stores, governance, and lineage matter for enterprise AI.

• Field engineering & enablement

  • You can work side‑by‑side with a customer’s data team, co‑building notebooks, pipelines, and MLflow/observability setups.

  • Strong skills in making complex architectures understandable through diagrams, demos, and “day‑2 operations” docs.

How to prepare for Databricks‑style FDE interviews:

• Build a full RAG system backed by a real data lake: ingest docs, create embeddings, store in a vector DB, expose as an API, and add monitoring.

• Practice telling the story of a data‑intensive project: ingestion → transformation → governance → AI feature → monitoring.

• Be ready to whiteboard how you’d integrate Databricks with a customer’s existing warehouse, BI tools, and downstream apps.

Current FDE open roles at Databricks

• https://www.databricks.com/company/careers/open-positions?department=Professional%20Services&location=all (search for FDE)

Salesforce: AI Agents, Business Workflows, and Enterprise “Last Mile”

Positioning: Salesforce’s AI FDE roles are deeply tied to AI agents and business workflows inside the Salesforce ecosystem. The emphasis is on customer outcomes, not just model sophistication.

What they really test for:

• Workflow‑centric AI design

  • You can map sales, service, or marketing workflows and decide where AI agents add value: drafting emails, suggesting next best actions, summarizing cases, etc.

  • You understand how to chain tools, data sources, and prompts into reliable “agentic” flows.

• Ecosystem fluency

  • Enough understanding of Salesforce platform primitives (objects, flows, Apex, integration patterns) to wire AI into real orgs.

  • Comfortable mixing declarative tools with code and external AI services.

• Elite customer‑facing skills

  • You spend a lot of time with business stakeholders: directors of sales, heads of service, program managers.

  • You can peel back the layers of “we want an AI bot” into root business problems and define measurable outcomes.

How to prepare for Salesforce‑style FDE interviews:

• Build an “agentic” AI prototype around a business workflow: e.g., an AI that triages support tickets and drafts responses while logging everything into a CRM.

• Practice explaining AI capabilities in pure business language: pipeline impact, CSAT, handle time, revenue lift.

• Prepare examples where you shaped requirements, pushed back on purely “flashy demo” ideas, and delivered something that actually moved metrics.

Current FDE open roles at Salesforce

• https://careers.salesforce.com/en/jobs/?search=forward+deployed+engineer&pagesize=20#results

Skill Map: How the Five Companies Differ

Here’s a simple way to visualize the emphasis areas. All five require all of these skills, but the “dial” is turned up differently.

Use this to target your preparation. You don’t need to be equally strong on everything to start; you need one or two companies where your natural strengths line up with their focus areas.

A 6–8 Week Targeted Plan for These Five Companies

If my earlier article was about “closing the general AI FDE gap,” this is the company‑specific version.

Weeks 1–2: Core LLM + One Deep Project

• Revisit LLM fundamentals and RAG.

• Build one serious end‑to‑end app and treat it as your “OpenAI/Anthropic case study”:

  • Backend API, basic frontend, RAG, observability, cost tracking, and a simple safety policy.

Weeks 3–4: Pick a “Platform Anchor”

Choose one based on your target:

• OpenAI: Build an end‑to‑end app on OpenAI APIs: for example, a customer‑support assistant with RAG over real docs, role‑based access, analytics dashboard, and basic safety/guardrail checks.

• Anthropic: Build a Claude‑based internal assistant (e.g., policy QA or contract reviewer) with an evaluation harness that tracks quality, safety failures, and red‑team prompts.

• NVIDIA: do a small performance‑oriented deployment, experiment with latency and throughput, document tradeoffs.

• Databricks: build a RAG system on top of a small lakehouse‑style dataset.

• Salesforce: build a workflow‑centric agent that automates part of a sales or support process (with a mock CRM if needed).

Weeks 5–6: Storytelling and Behavioral Prep

• Turn your projects into 3–4 crisp case studies: problem → constraints → decisions → results → lessons.

• Practice behavioral stories that highlight: discovery, production debugging, stakeholder management, expectation management.

• Tailor your resume bullets and LinkedIn to explicitly mention “AI Forward Deployed Engineer–style work” and name these companies as your target pattern.

If you already have SA/SWE experience, this plan is less about learning everything from scratch and more about relabeling and aiming the skills you already use daily.

The Bottom Line

AI FDE roles at OpenAI, Anthropic, NVIDIA, Databricks, and Salesforce are deep enough in AI and engineering to ship, and deep enough in customer reality to matter.

If you’re a seasoned SA or SWE, you’re already 60–70% of the way there. The remaining 30–40% is:

• Gaining AI fluency

• Picking 1–2 ecosystems to anchor on them (the focus of each of them is bit different)

• Learning to talk about your work through the lens of “forward‑deployed impact,” not just “feature delivery.”

  Thanks for reading FDE Hub! Subscribe for free to receive new posts and support my work.

When we onboarded our newest FDE at Lleverage, he was running his own client within two weeks. That’s not because we were reckless. It’s because FDE onboarding operates on a fundamentally different logic.

Ownership from day one

The core difference between onboarding an engineer and onboarding an FDE is that FDEs need to own things end-to-end from the very beginning. The unit of ownership isn’t a module or a ticket. It’s an outcome for a client.

The scope starts small, of course. A proof of concept. An extension to an existing solution. But even when the scope is small, the ownership is complete. You’re not fixing someone else’s bug. You’re figuring out what the client needs, how to build it, and how to deliver it.

When I started at Lleverage, my first two days looked like what we do when we begin any client engagement: gathering context. Meeting after meeting, absorbing everything I could about the sales process, the platform, the technology, existing customers, how the team operates. Two days of listening and asking questions.

On day three, a colleague from the sales team walked over. We need someone to run a PoC for a prospect. Can you pick it up? The demo was due in two days.

I said yes, obviously. You don’t join a role like this and hesitate when someone hands you a real problem to solve. But looking back, that moment was the best onboarding decision anyone made for me. It forced me to learn the platform not by reading about it, but by building something on it under a real deadline. I was paired with someone who could show me the basics, give me that initial push, and then I had to figure the rest out.

By the end of my first week, I was already picking up existing clients, maintaining their solutions, and starting to think about where those solutions could go next.

The layers underneath

What makes FDE onboarding uniquely dense is the number of dimensions you’re absorbing simultaneously. It’s not just “learn the codebase.” There are distinct layers, and they all matter.

There’s the platform itself: how you build on it, its capabilities, its constraints. There’s the project management side: how we track work, communicate progress, manage timelines across multiple clients. There are the clients themselves: their industries, their systems, their stakeholders, their particular expectations. And then there’s the internal layer: how the team works, how decisions get made, what the culture around quality and pace looks like.

A software engineer might absorb these layers over months, one at a time. An FDE has to take them all in more or less at once, because the moment you sit in a client meeting, all of these layers are active.

Calibration, not probation

When our newest FDE joined a couple of months ago, we followed the same instinct. He shadowed me on an existing client for about two meetings. Then he started picking up tasks. Within two weeks, we’d done the full knowledge transfer and he was in charge of that client relationship. By the end of his first month, he’d taken on a completely new client from scratch. He’s now onboarding with a third and fourth in his second month.

That pace might sound aggressive, but it reflects something important about how we think about onboarding. If you’ve done the hiring process right, you should be at least 95% confident that this person can do the job. The hiring process itself, its entire purpose, is to establish that baseline.

So the onboarding period isn’t a trial. It’s a calibration. You’re not figuring out whether someone can do the work. You’re figuring out how quickly you can increase scope, how soon they can handle bigger clients, more complex projects, more simultaneous engagements. The approach is to stretch people relatively quickly, to find out where their ceiling might be, without actually pushing them to a breaking point. That’s very different from the cautious approach of holding back responsibility because you’re worried about overloading someone.

Our newest hire came from a technical background, fresh from university but with a couple of years of building his own companies behind him. The entrepreneurial experience was a strong signal: someone who’s built products, talked to customers, handled the pressure of making things work with limited resources. That profile told us a lot. It was just a question of how quickly he’d adapt to this specific context. He adapted faster than we expected.

Staying close

How do you actually monitor all of this without micromanaging? For us, it starts with regular check-ins. Bi-weekly conversations between mentor and mentee, in addition to the normal managerial ones. Those check-ins are a mix of practical and personal: how are you feeling, what’s blocking you, but also let’s talk through this specific client situation.

Beyond the structured check-ins, physical proximity matters. I don’t mean this in a “remote work doesn’t work” way, plenty of FDE teams operate remotely and do it well. But in our case, sitting next to each other in the office made a real difference. I told my mentee early on that I don’t mind being interrupted. That I’m available for questions whenever they come up, within reason, but that it has to come from them.

That last part is deliberate. I’m not going to chase someone down and ask if they need help every hour. I make myself available, I show that I care, and then I let them come to me. There’s a practical reason for this: I have my own clients and my own work. But there’s also a diagnostic element. A big part of the FDE role is asking questions. When you’re with a client, you need to ask constantly, probe, clarify, push back on assumptions. You should never be embarrassed to say “I don’t understand, can you explain that again?” If someone is hesitant to ask their own mentor for help, that’s a signal. It might mean they’ll also hesitate to ask the client, and instead build something based on what they think they understood rather than what actually needs to happen.

In the early days, I sit in on client calls so the new FDE can shadow. One or two calls to observe the dynamic, understand how we communicate, see how conversations flow. Then they start taking over gradually: leading parts of the call, then running the whole thing while I observe, and eventually handling it independently.

The KPI through all of this isn’t code quality or technical elegance. It’s whether the client is happy and the solution is delivering value. That’s what’s measurable, and that’s what matters. If the solution works and the client sees results, the code behind it is secondary.

The gap we found

If I had to identify the one thing we got wrong, it’s that we didn’t spend enough time walking through existing solutions.

When I started, I got a broad overview of what was in production: the different clients, the different use cases, the general landscape. But the emphasis was, rightly, on the clients I’d be taking over. With our newest FDE, we did even less of this. We jumped straight into client work, gave him context on the solutions he’d be owning, and moved quickly.

It worked, but in retrospect, we left something on the table. There’s real value in sitting down with a new FDE and walking through a range of completed and in-progress solutions. How we typically collect data. How we handle integrations that aren’t native to the platform, where we’re relying on HTTP requests. How we move from development to production. How we manage credentials. When we use LLMs versus structured workflows versus full agentic setups.

These are patterns. And you only develop an instinct for them by seeing enough examples. Our mentee said it himself: seeing more of the existing work earlier would have accelerated him further. He was already moving fast. But that kind of pattern recognition, knowing that “oh, this new client’s problem looks a lot like what we already solved for another client,” saves real time and produces better solutions.

If I were redesigning the onboarding, I’d keep the same structure of short, focused sessions spread across the first week, anywhere from one to two hours each, covering different aspects of the platform, the solutions, and the workflow. But I’d add a dedicated track that walks through the architecture and patterns of existing solutions, not just the ones the new FDE is picking up. And I’d leave room between those sessions for them to explore on their own, to identify their own gaps and focus where they feel weakest.

When I started, for example, I was coming from six years of working directly with enterprise customers. I was confident in how I communicate with stakeholders, how I run meetings, how I manage expectations. But I was rusty with coding and building. So that’s where I put my own focus in those early days. Everyone’s profile is different, and the onboarding needs to accommodate that.

Good enough is good enough

One more thing that’s important to instil early, especially in a startup environment, is the idea that things need to be done well but not perfectly.

Every good engineer has high standards. That’s a feature. But in an FDE role, those standards need to be in service of the client’s outcome, not your own sense of craft. Sometimes you ship something that you’re not 100% happy with. The architecture isn’t as clean as you’d like. The edge case handling is functional but not elegant. If it’s delivering value to the client and it’s working reliably, then it’s good enough. Chasing perfection at the expense of pace is a luxury that FDEs, particularly in a startup, can’t afford.

This doesn’t mean you cut corners recklessly. It means you develop judgement about where the bar needs to be high and where good enough genuinely is good enough. That judgement, like most FDE skills, comes from exposure and repetition.

Still figuring it out

I’m not presenting this as a finished playbook. We’ve onboarded exactly one new FDE at Lleverage, and my own onboarding was only about nine months ago. The sample size is small. But the principles are becoming clearer with each iteration: ownership early, scope that grows based on calibration, proximity and availability, pattern recognition through exposure, and the confidence to stretch people when you’ve hired well.

I know a lot of FDEs read this newsletter, and I’m genuinely curious how your onboarding looked. Whether you were thrown into the deep end or eased in gradually. Whether your team had a structured process or figured it out as they went. And for those of you who lead or mentor FDEs, how you think about shaping someone into this role. I’d love to hear about it in the comments.

You studied CS and Applied Maths at Berkeley, went to Harvard Business School, spent five years at Palantir, and now you’re investing at Emergence. That’s a lot of different seats. How did FDE lead to venture?

When I was at Berkeley, the rite of passage for anyone studying CS was to go be a software engineer at Google or big tech. I had interned there and I didn’t really enjoy it. It was slow. The scope of your work tends to be very limited.

What excited me about Palantir was that I’d be responsible for spending time with customers, scoping out what they’re trying to do, and then just going and building it myself. A lot of the value came from hearing how customers were trying to do something with the product and where it failed, and then literally building something in the next two days and showing it to them. Sometimes completely from scratch. At that stage of my career, that felt like a really good learning opportunity for someone who wants to maybe one day start a business.

After five years, I went to HBS looking to start a company. I played around with a few ideas, and in that journey I met a bunch of VCs. I was a scout for a fund called Contrary, got a chance to intern at Notable Capital for about eight or nine months. During that period, I just enjoyed the day-to-day work enough that I ended up wanting to do it full-time.

There are trade-offs. When you’re deeply embedded in a specific problem as an engineer or PM, you only think about that one problem. You think about all the things that could go wrong and everything you need to fix to make it work for a customer. As an investor, you don’t get that depth. But the entire job is meeting really smart people and hearing about how they view the world and how they want to shape certain problems. The energy I got from that was enough to compensate for the lack of depth.

Kabir also spent time as a product manager at Verkada and in engineering roles at Amazon. I asked how those stints in more traditional product and engineering organisations changed his view of the FDE model.

Did those experiences show you that FDEs have gaps compared to traditional product managers, or that they have advantages?

It’s definitely an advantage. I started doing product work while I was still at Palantir, towards the end of my time there. A big reason I was able to do that was because I’d spent so much time actually building parts of the product and hearing across many different customers and verticals how they used it. That helps you inform your intuitions about both how to build and what to build.

Verkada was a slightly different experience. Product is not as tightly coupled with engineering there. You only think about what you want to build, not necessarily how to build it. For my personality and background, I had a lot more fun in the Palantir style of doing product, which was much more tightly coupled with FDE and core software engineering.

But there’s also a disadvantage. The biggest thing I felt as a PM was a natural inclination to overfit to a very specific customer’s feature requests. That inclination is probably fine at a business like Palantir, which has a couple of hundred customers that tend to be very large. You benefit from overfitting to what those customers want.

At a business like Verkada, which has many more, smaller customers, you have to be more disciplined about which features and workflows you actually support. I remember speaking to a customer that was not very large and I started scoping out exactly how we’d build this one thing they really wanted, something highly specific to them. My manager told me, why are you doing this? It doesn’t make any sense. We need to make a business case. We need to decide where this fits from a priority perspective. That was a good lesson.

Kabir’s FDE background now shapes how he evaluates founders. At Emergence, he’s drawn to companies that look messy early on, the ones doing hands-on, customer-specific work before they’ve figured out the product. I asked how he tells the difference between a smart path and a dead end.

Your bio at Emergence says you love founders who do what might initially look like unscalable things to solve customer problems. That’s basically the FDE job description. How do you distinguish between a founder doing unscalable things as a path to product versus one who’s just building a services company that won’t scale?

You can’t scale what you don’t know. Early on in a company, it’s pretty natural to be doing unscalable things.

If you’re primarily serving enterprise customers, doing unscalable things is actually really good because it buys you a level of trust with users that is very hard to get otherwise. If I’m a young person selling to a large Fortune 500 company, I’d be very lucky to get my foot in the door. If during the pilot I severely constrain the set of things I want to do relative to the set of things my users want me to do, it gives me less opportunity to build trust. And with enterprises, you want trust to expand within them over time.

Of course, it’s important to productise in some shape or form. You don’t have to productise the external thing, at least not early to mid-stage. But it is good to be productising the set of primitives you see come up again and again, at least internally.

As an example at Palantir, even when I was there, Foundry was relatively nascent. FDEs would build custom front-ends to support very specific workflows and applications. In maybe a year and a half to two years, a lot of what FDEs had built across deployments provided learnings into what a more generic application builder could look like. One that actually works well, because there were a ton of other application builders in the market that couldn’t do very specific things, like allowing users to configure complex business logic beyond simple SQL queries. That kind of stuff could not have come without the “unscalable” work.

Today, with AI coding tools, the road you can travel doing unscalable things can go a lot further. If you want to build custom applications, custom React front-ends, you can do them a lot quicker with tools like Claude Code. That can incentivise founders to keep the services journey going very long.

But it’s still important to try and productise, because every moment you spend building or supporting something customer-bespoke distracts you from building the thing that’s eventually going to be your product. At a minimum, internally, founders should be productising the set of primitives they see over time.

This naturally led us to a question about defensibility in a world where building is getting easier by the day.

If it’s easier than ever to build things, what counts as a moat?

Brand and trust. That as a moat has not changed. You tend to look for whether there’s a lot of customer love. Even if it’s easy to build things, not every product will have tons of customer love. Are users going to be super sad if this product was ripped out? If it became 5x more expensive?

You do see a real bifurcation. Today, there are a bunch of coding tools. But people are still spending thousands of dollars every month on Claude Code, on those really expensive tokens, even though there might be cheaper tools out there.

Where you have to be careful is investing in companies that are very thin layers over the model. You have to look for what level of depth they’ve actually gotten within an industry or a workflow.

Towards the end, Kabir brought up a topic I hadn’t planned to ask about. Historically, VCs have avoided services businesses because of thin margins and slow growth. He’s seeing that change.

You mentioned AI-enabled services businesses as a real opportunity. What’s shifted?

The thing most people point to about services businesses is that the gross margin profile is not there. Most services businesses tend to be 25 to 35% gross margin, whereas software has historically been 70 to 80%.

I would push most founders to think about that, because you can probably get to the 60s or even 70s. There are startups in the Valley that have been able to get to 70-plus percent gross margins offering purely a service.

The trade-off between product and services doesn’t actually have to be as explicit as we historically believed. For a lot of industries, like accounting or healthcare, the cost of mistakes is so high that customers want a human in the loop. There is still an opportunity to build a true venture-scale services business that is more enabled by AI. There are already examples, including some companies in our portfolio like Strala, that are taking this approach where they’re not selling product, they’re selling a service.

Founders should not shy away from that.

I had one last question. Many FDEs eventually start their own companies or move into product. Kabir has done both. I asked what he’d tell FDEs thinking about what comes next.

You’ve been an FDE, a PM, and now an investor. What advice would you give to people entering the FDE role, or FDEs thinking about their next step?

It’s probably the most exciting time to be an FDE because there’s so much more you can actually do for more customers with the tools being built today.

From a core advice perspective, the job of an FDE is evolving. A lot of companies outside of Palantir would structure this role historically as someone who does configurations and integrations. Every FDE should be thinking hard about how they can shape the product. They are the people providing the most direct signal and feedback. A key thing that sometimes gets missed about the FDE model is that the reason you have deployed teams is not just because the product doesn’t work. It’s about finding more use cases to tackle, more users to enable.

For people thinking about what’s next, FDE is becoming more of an independent function. You can be a true head of deployments at your company. If that’s not the direction, starting a company is a great option. Product is a natural progression too, but honestly those roles are converging. A lot of what you’re already doing is spending time with customers. You are already shaping product and doing product-style work.

I’d even say that going into core product engineering is a strong path. That used to be the most common move at Palantir. People who’d been there a long time would build stuff in the field, then build a more generic version of it that would be used across the fleet of customers. Pretty much all the best engineers at Palantir across the years were former FDEs.

Kabir Sial is an Investor at Emergence Capital.

The client was still in touch with the original builder, so they shared the contact and I got on a call with the guy. Nothing dramatic, but every piece of logic, every business rule, every edge case in that system lived in one person’s head. If he’d moved on or been unreachable, there was no project. The AI was perfectly capable. There was just no door to walk through.

The agent works. The system it needs to talk to does not. These systems were never designed to be talked to by an agent. They were designed for a person who already knows how everything works.

The distance between what an agent can reason about and what it can actually access and act on is the context gap. Right now, it’s the single biggest bottleneck in enterprise AI.

Demos are easy. Integrations are not.

Building an agent that can read a sales order and extract line items is a weekend project. Building one that can take that sales order, match it against the right customer in an ERP, check inventory across three warehouses, apply the correct pricing tier, and book it into the accounting system with proper GL codes? That’s months of work. And most of that time isn’t spent on the agent itself. It’s spent getting access to the systems around it.

Another client, a wholesaler, ran an old on-premise version of Business Central. Getting a connection required weeks of back-and-forth with their implementation partner over firewall restrictions, whitelisted IPs, and specific port configurations. Once we finally had access, we discovered the system had been customised with internal actions and triggers that nobody fully understood. We’d call a seemingly straightforward endpoint and something unexpected would fire in the background. Weeks were spent mapping undocumented behaviour that only revealed itself through trial and error.

This is the reality across almost every deployment. APIs are undocumented or don’t exist. Every customer’s setup is customised in ways that generic documentation doesn’t cover. And the people who originally configured the system have often moved on.

System archaeology

When documentation doesn’t exist, you discover the system yourself. I’ve started thinking of this as system archaeology. Software archaeology is an established concept, but what FDEs do in the field is a specific version of it.

In practice, it looks something like this. You hit an endpoint that returns all available objects. You fetch a thousand of them and immediately you’re looking at field names that only make sense if you’ve worked in that specific industry for a decade. This is where an LLM becomes genuinely useful. You feed it the response and it helps you interpret the data, connect the dots between cryptic field names and domain concepts, and start mapping the structure of what you’re looking at. You filter by type until you find the ones you actually need, often going back and forth with the model to make sense of what each type represents in the context of the client’s business.

Then you need to learn how to create that type. So you start with the absolute minimum number of fields and try to post an object. It fails. The LLM helps you build the next request and interpret the error in context. You add fields, try again. Eventually it succeeds, and you check what you’re missing compared to what a properly created object should look like. You iterate until the object looks right.

That gets you basic reads and writes, and through most of that process the LLM is a genuine partner. But the real complexity shows up when you need to figure out how to perform actions. Creating an object is one thing. Triggering the right downstream behaviour, posting it to a ledger, moving it through a status chain, firing the correct workflow, is another entirely. At that point the LLM can only really help you verify what happened, and verification itself is hard. You’re checking whether the system ended up in the right state, often across multiple tables and processes, with no specification to compare against. That’s where the undocumented behaviour lives. That’s where the system does things nobody told you about, because nobody remembered it did them.

Fetch. Interpret. Request. Validate. Repeat.

It’s painstaking work, but it’s the work that actually gets an agent into production, and no amount of model improvement will eliminate it. The problem isn’t the agent’s reasoning. The problem is that the context the agent needs is locked behind firewalls, buried in legacy databases, or sitting in the head of an operator who’s been doing the job for fifteen years.

Where this leaves us

Companies have access to the most capable AI models ever built, and most of them are still running on spreadsheets, disconnected tools, and manual processes. The gap between what the models can do and what the systems around them allow remains enormous, and nobody has done the work to close it.

I think the instinct for a lot of companies right now is to look at AI as a way to leapfrog the infrastructure problems they’ve been ignoring, to automate the messy process and let the agent figure it out. But AI is not a magic cure for undermaintained systems. If anything, it makes the mess more visible. The moment you try to connect an agent to a process, you discover exactly how undocumented, fragile, and human-dependent that process really is.

The organisations that get real value from AI will be the ones willing to do the unglamorous work first: mapping the processes, connecting the systems, documenting what was never documented, and building the doors before expecting agents to walk through them.

The question I keep coming back to is simple. How many companies are prepared to do that work? And what happens to the ones that aren’t?

You might have noticed I went quiet for almost ten days. I spent a few days in San Francisco, attending meetings and delivering a talk at the FDE Conference, organised by Nixo, Rippling and ElevenLabs. Between the travel and the talk prep, I decided to skip a week rather than rush something out.

This week, I want to share what I talked about. The talk was called “The Champion Trap,” and it’s based on a pattern I’ve seen across roughly 20 client engagements so far. The pattern is simple: the person most excited to work with you is often the one most likely to send you in the wrong direction.

That sounds ungrateful. It’s not meant to be. The champion is usually someone incredible. But there’s a gap between knowing what a team does and knowing why they do it the way they do it. And that gap will cost you months if you don’t catch it early.

Let me walk you through how I learned this.

The setup

Global customer. A major music label with offices across the UK, US, and the Netherlands. The project: accounts payable automation.

On paper, accounts payable doesn’t sound too complicated. But their suppliers are music artists, and artists are not always comfortable with invoicing. Formats ranged from proper PDFs to handwritten notes, Word documents, Excel files, things that barely qualified as invoices at all. Tens of thousands of suppliers. 150 possible approval paths across seven levels of hierarchy.

One invoice sticks with me. We flagged it for a missing purchase order number. The operator reached out to the creditor and asked them to add it. They sent back a revised invoice. We processed it, flagged it again. The purchase order was still missing. I double-checked. They had literally typed the words “purchase order” on the invoice instead of providing the actual number.

That’s the kind of territory we were operating in.

We had a champion on the client side, and she was excellent. This project was her top priority. She was available, responsive, senior enough to make decisions, and deeply motivated to get it done. Every instinct said: this is the person to build with. This is the person who’s going to get us to a solution fastest.

We spent two months building the solution with her.

Death by a thousand details

Then we gave it to the operators.

It wasn’t one big dramatic failure. It was dozens of small things. Operators were changing data directly in the ERP that we didn’t know about, which meant we needed two-way sync instead of the one-way push we’d built. The approval process ran on a spreadsheet that had been growing for over a decade, with paths and exceptions nobody had fully documented. We’d built around how accounts payable should work, not how it actually did.

There were hidden workarounds everywhere. Dozens of micro-decisions per hour that the champion had never seen, because she didn’t do this work every day. The operators did.

And because this was finance, there was no room for partial wins. Either the invoice books correctly, or it doesn’t. There’s no “almost right” in AP.

The champion wasn’t wrong about anything. She genuinely believed she knew how the process worked. But there’s a difference between overseeing a process and living inside it, eight hours a day, handling the exceptions and edge cases that never make it into a summary.

The cost

Two to three months of redesign. The AI worked fine. We’d just built with the wrong person’s understanding.

Two mistakes in one project. First, we built with the champion’s version of reality instead of the operator’s. Second, we tried to automate a broken process instead of simplifying it first.

We spent months building infrastructure around that ten-year-old approval spreadsheet, faithfully replicating every path and exception. When we finally pushed back and said this is going to take longer and be harder to maintain if we cover every path, they realised the process could be significantly simplified. The framing that unlocked it: faster delivery, easier maintenance. Everyone wants both.

The project is in a much better place now. But those extra months were the tuition fee for a lesson I won’t forget.

Right customer, right stage

Four people matter in every FDE project: the sponsor, the champion, the operator, and the FDE. Each one is essential, but at different stages.

The sponsor unlocks the deal in pre-sales and approves expansion at the end. During the build, they just need updates.

The champion gives you context and vision. They’re invaluable during pre-sales and for alignment checks throughout. But their role during the build itself should be periodic check-ins, not daily collaboration.

The operator is where the real knowledge lives. They should be your primary partner during scoping and the build phase. They hold the “why” behind every workaround, every exception, every process that looks irrational from the outside but makes perfect sense when you understand the constraints.

Champions know what the team does. Operators know why they do it the way they do it. If you only have the “what,” you’ll build something that looks right but doesn’t work in practice.

What it looks like done right

Different project, different client, different approach. Sales order processing.

This time, we pushed hard from the very first call to get connected with the operators. Before the deal closed, before scoping was even finished. We did a thorough discovery call where we actually mapped the process before signing anything. At kickoff, we confirmed everything with operators from day one. No assumptions from the sales phase carried over unchecked.

Then we built fast, iterated with operators synchronously and intensely, and delivered in six weeks from first contact.

The difference wasn’t that we built faster. It’s that we knew who to sit with from the start.

This part is worth being honest about: operators are not always eager to work with you. There’s real fear around AI. People wonder if you’re there to replace them, restructure their role, or hand their job to a machine. I’ve been fortunate that in almost every engagement I’ve worked on, the company’s intention has been to free operators from repetitive work and give them more meaningful things to do. But the operators don’t always know that when you first walk in. Earning their trust, warming them up enough to share how the work really gets done, that’s part of the job. Maybe the most important part.

The closing thought

This matters more now than ever. AI is getting better at the intelligence layer. It can process invoices, route approvals, handle data entry. But the “why,” the judgment, the decision-making, that still lives with the people doing the work every day. And the only way to get it is to be in the room with the people doing the work. With them.

Every project has someone eager to help you build. The hard part is finding who knows how the work gets done.

The value of an FDE isn’t building faster. Tools are making building easier every month. The value is knowing who to sit with. And it’s almost never the person raising their hand.