Same Map, Two Altitudes

We're writing about the same thing in different corners of the world and are coming to the same conclusions.

We’ve been writing about the same role from opposite ends of it.

One of us spends his weeks inside the deployment — embedded with customers, doing the unglamorous archaeology of getting an agent to read a system that was never built to be read. The other spends his weeks underwriting the category — deciding which of these companies compounds into something durable, and why. A forward-deployed engineer and a venture investor. Bottom-up and top-down.

We got introduced, traded a few posts, and expected the call to be a friendly argument. It wasn’t. We’d independently written the same diagnosis in two different vocabularies. One of us calls it the context gap and system archaeology; the other calls it the deployment bottleneck and the two conditions. Same finding, different altitude: the model stopped being the hard part. What’s hard is everything wrapped around it — the context, the correctness, the integrations, and the judgment about what’s actually worth building.

So we did something more useful than argue. We put both bodies of work on one table — one of us literally fed the other’s entire back catalogue into the model that runs his thinking — and looked for the seams. This is what we found: where the map overlaps (more than we expected), the one place it forked (and how the fork turned into the most interesting idea of the call), and where we think the role is going next.

Where the map overlaps

The bottleneck isn’t the model — and the wiring is getting harder, not easier. Everyone wants to talk about model capability. The real wall is integration. Not the marquee enterprise accounts — those companies run modern, API-friendly systems. It’s the long tail: the SMBs running twenty-year-old software with no API, often not even in the cloud, where the cost of changing the system of record runs from half a million to tens of millions of dollars. Nobody is ripping that out. So the work is to reach into it. ⚑ One of us recently backed a company doing exactly this — agents operating legacy systems (think medical practices, hotel booking) by clicking like a human on a screen the model can’t natively see. The point both of us keep landing on: the low-hanging API fruit is gone. What’s left is thirty years of technical debt, and that’s now the job.

The work is mostly process engineering — and better models pushed it further that way. This surprised exactly no one who does it, but it’s worth saying against the “AI writes the code now” noise. As the models got better, the share of the job that is writing code went down, and the share that is understanding how a business actually works went up. The building blocks exist; agents wire them together; the scarce skill is figuring out which blocks, in what order, for a process nobody has ever written down.

The honest test of an FDE: does the work feed the product? This is the line between a company and a consultancy. If what you learn in the field flows back into the product, you compound. If it doesn’t, you’re billing for labor with extra steps. In practice it’s messy — at an early startup it might be ~40% feeding product and the rest keeping revenue alive, and the ratio shifts with maturity (a mature voice-API company or a frontier lab feeds the harness and adjacent tooling, not the core model, and that’s fine for them). But the principle holds: feeding the product and driving the outcome are the two things that earn the title.

Do FDE well and your whole post-sales org gets smaller. Here’s a move stolen from the old SaaS playbook. Investing in onboarding used to buy you downstream efficiency — fewer support tickets, less change management, customers reaching value sooner, CSMs not constantly restarting dead accounts. That effect is amplified in applied AI, because you’re no longer selling seats on a platform — you’re selling units of work. So the forward-deployed function isn’t protecting an annuity; it’s driving revenue, and it compresses what used to be five roles (pre-sales, solution architect, project manager, change management, account relationship) into one. The counterintuitive consequence: done right, FDE shrinks the post-sales organization. Support doesn’t disappear — it inverts. Tier-one goes to AI (low cost of error, much like code). What’s left for humans is the harder tier-two and tier-three work: longer to resolve, touching more of the organization, and frankly more exhausting. The people who do support now are more tired, not less.

Eval pass rate is the new NRR — and the cost of error sets the bar. If there’s one metric the forward-deployed function should organize around, it’s the rate at which the system’s work clears the customer’s bar for “correct.” That’s the new driver of stickiness and net revenue retention. But the bar isn’t universal — it’s a function of the cost of error. In aerospace, a part with a defect is catastrophic, so the bar is 100%. For a wholesaler, shipping to the wrong address costs fifty cents, so 95% is fine and the value is in everything built around the core task. You can see this in the job market: the most eval-obsessed forward-deployed roles cluster in the domains where mistakes are expensive — legal, medical, finance. Define the cost of error first; it tells you what “good enough” has to mean.

The argument that collapsed into a better idea

We went into the call hunting for a real disagreement, and we thought we’d found it on defensibility.

One of us had written that, as models commoditize, lock-in is the next move — the labs are building deployment arms whose solutions are coupled to their own models, so switching becomes a re-implementation by design. The other had written that the moat is the opposite of lock-in: a private eval — your own proprietary library of what “right” looks like, the thing that lets you swap models underneath and keep climbing your own hill. One view says trap the customer; the other says own the judgment and stay portable.

Then we realized we were describing the same animal from two sides. The lock-in view is about the labs’ incentive; the private-eval view is about what actually stays valuable when the model underneath is a commodity. Push both one step further and they meet in the same place: when models are roughly interchangeable, the differentiator moves to the harness — and then one step beyond the harness, to the opinionated product experience wrapped around it.

That’s the real moat, and it’s an old venture truth in new clothes: a strongly opinionated product that produces work which clears a very opinionated eval bar. Think about why you stay in your coding tool of choice — not because it’s the only model, but because it has your context and a point of view about how you should work. Think about Apple shipping products that aren’t always the most innovative but are relentlessly opinionated, and winning anyway. The defensible thing isn’t the model and it isn’t even the harness; it’s the taste encoded into the product and the private bar it’s measured against. The hardest moat for AI to copy is the one that can’t fully articulate itself — the “I don’t know what it is, I just know it’s right.”

The forward payload: the FDE is splitting in two

The most interesting thing we found wasn’t in either of our archives — it fell out of the conversation.

Two forces are pulling on the role at once. Sovereignty — a government or regulated buyer mandating which models may touch their data — and cost — the minimum tokens required to clear the eval bar — both push toward model-portability. The same harness may have to run on a Canadian model for one customer, an open-weight model for another, a frontier model only where the work genuinely needs it. That makes one half of the forward-deployed role more technical, not less: you have to know what each model is good at, what it costs, and how to orchestrate several of them (a powerful model conducting, cheaper models doing the sub-tasks) to produce a unit of work that passes the bar. The skill isn’t syntax anymore; it’s judgment about the implications of technical and model choices.

But the other half of the job — gathering context, mapping the org, holding the customer relationship, reading the political weather of a deployment — isn’t getting more technical. It’s getting more like the role we used to call customer success. And as the CSM role collapses into the deployment motion, that’s where the context-gathering half of the FDE lands.

So the role bifurcates: a deeply technical forward-deployed engineer and a context-gathering, account-holding partner. Two roles inside one account. If that sounds familiar, it’s because Palantir has been running it for years as Delta and Echo — the engineer who builds and the domain person who holds the context and the value — each correcting the other. The AI-native company is about to re-derive the same pair from scratch.

This also quietly settles a question one of us had been holding: whether teams drift toward more engineers than domain experts as judgment gets abstracted into the product. The better answer may be that it was never a ratio. It’s a pair — and the durable unit is the technical FDE matched with a context partner who is, increasingly, the evolved CSM.

What’s still transitory

A caveat we both hold: all of this is written in pencil. The whole edifice assumes the current model paradigm, where out-of-the-box AI delivers a minority of the value and the wiring is genuinely hard. Every month the models eat a little more of both conditions — more context, more verifiable correctness — and when a generation closes that gap on its own, parts of this thesis compress. One of us leans that the shape is partly transitory; the other that it’s durable and expanding. We’re comfortable not resolving that in print.

Two questions we’re still chewing on, and we’d rather show them than pretend they’re closed: whether the technical/ context pair eventually collapses back into a single hybrid person, and how to hire for the role — for raw slope and drive, or for accumulated domain judgment. We disagree at the margins on that last one, which is probably the next thing we’ll write about.

Close

We came at this role from opposite ends and drew nearly the same map. That’s either a sign we’re both right or a sign we’re reading from the same hymn sheet — and the only way to find out is to keep publishing the disagreements as we find them. If you came here from one of our newsletters, the other one is the other altitude on everything above. We’ll keep comparing notes in the open.