Everyone rents the same AI. Deployment is the moat.

I spend most of my time on one question: what actually compounds. So a line in a recent podcast stopped me. Vas, who runs an AI deployment firm called Varick Agents, sat down with Greg Isenberg on the Startup Ideas Podcast to explain the "forward deployed engineer," and he opened with a claim that reframes the whole AI gold rush: every company can now buy the same intelligence, so intelligence is no longer the moat.

That is a profit-pool argument in disguise, and profit pools are my beat. When a capability commoditizes, the margin does not vanish. It slides to the adjacent layer that stays scarce. Vas's whole thesis is a bet on which layer that is. What follows is his framework, grounded in that conversation, with an operator's read on why it holds.

Intelligence is the commodity now

A frontier model ships almost every week. Anyone who can pay gets the same foundational capability, and today that is most companies. Go talk to fifty enterprises, Vas says, and they are all standing on the same stack: Claude Code, Codex, Cursor for model-agnosticism, GitHub Copilot. The intelligence tap is identical. If everyone can turn it on at roughly the same price, it cannot be the thing that separates them.

So the edge moves to deployment: where the intelligence goes, how it is wired in, and why. Every business runs differently, and the value accrues to whoever builds the best bridge between a company's real processes and the general model it rents. That bridge is the job.

The evidence that intelligence alone is not enough is already piling up. Vas leans on the MIT finding that 95 percent of enterprise generative-AI pilots fail, a number I have argued elsewhere is inflated, though the honest 40 to 50 percent is bad enough, and he tells a sharper story of his own: a C-suite team that burned through a $10 million model budget in three months, a budget meant to last a year, because they handed it to everyone and let them run. The tokens got spent. The needle did not move. The capability was there; the deployment was not.

Put simply: When everyone can rent the same intelligence at the same price, intelligence is not your advantage. Whoever fits the model to a specific business the best captures the value. Spend there, not on more tokens.

The role that captures it

The title is borrowed from Palantir, which is where Vas points to explain it. Palantir built a customizable ontology, a stack of connectors and data links that let a client pipe its data into one interface, then sent engineers on-site to learn each client's workflows and stand up the dashboards and agents tuned to that business. It was consulting for the software age, and the beauty was never how tech-forward the platform was. It was how customizable it was.

What makes the role rare is that it demands two kinds of judgment that almost never live in one person. One is business judgment: reading how the work is really done, weighing cost and risk and incentives, managing adoption and the internal politics. Consultants from McKinsey, BCG, and Bain are strong here. The other is technical judgment: models, APIs, data, evals, guardrails, shipping production software, and knowing where AI does not belong. Engineers are strong here. The forward deployed engineer is the best of both, not the average of both, and Vas is blunt that the average, a mediocre communicator who also cannot really code, is worthless.

That rarity is priced accordingly. Vas puts the range at $150,000 base with meaningful equity, up to $1 million a year for the best of the breed. He calls it the hottest role in technology, and the money is a straightforward reading of supply and demand: the demand is real, and the people who can genuinely do both halves are scarce.

Put simply: The million-dollar hire is the person who can turn business understanding into working software, end to end. If you are strong on one side, the fastest way to become valuable is to get credible on the other.

The documented process is never the real one

Here is the part technical people skip, and the reason the job cannot be done from a laptop far away. Ask someone what the first step of their workflow is and they will say "an email arrives." Clean trigger, simple system. Then you sit with the work.

The email arrives from more than forty senders, none formatted alike. The data is in PDFs, in screenshots, in Excel, or buried in a forwarded thread. Half of every batch is an exception. The rule for what goes where lives in one person's head and is written down nowhere. If you build for the story you were told, you build for a system that does not exist.

This is why Vas insists the work is mostly on-site, the way Palantir does it and the way McKinsey consultants sit with miners at the mine. A one-hour meeting gets you what someone thinks their job is. Eight hours next to them gets you the job, including the thing that breaks and the undocumented move that fixes it. It is also where trust gets built, and trust is what lets you deploy anything at all.

Put simply: The map in the SOP is not the territory. Budget most of your time for getting the real workflow, exceptions included, out of the people who hold it in their heads.

The loop that compounds

Once you know the real workflow, the build is one repeating loop: audit, evals, deployment.

The audit maps every workflow cleanly, the full steps and the exception handling, and hands back an ROI matrix of what is worth automating and what is not. Vas charges for it, and clients tell him it was worth ten times the price and better than McKinsey, because AI is new enough that nobody else knows how to audit it. A tactical note from the same conversation: the word "audit" triggers a tax-audit flinch, so Isenberg's agency renamed it a "sprint" and it landed better. Same work, easier yes.

Evals turn fuzzy tasks into evidence. Run the agent fifty times, count the passes, then read the failures: five had missing data, four pulled the wrong record. That report is how you improve the system and how you decide what is safe to automate versus what gets routed to a human. The design that works for most companies is mostly deterministic software, an LLM only at the few steps that genuinely need judgment, and a person in the loop to approve before anything irreversible happens. And you build for the exceptions, not the demo. In Vas's words, "there's only one way that something can go right, but there's a thousand different ways something can go wrong." An agent that only handles the happy path is worth nothing.

Deployment has one rule: integrate, do not migrate. A client that spent years and millions moving onto NetSuite will throw you out if your plan is to move them off it. Build on top of what they run, wire it into Salesforce and SAP and the rest, and roll out in stages, from a controlled test to shadow mode to real autonomy. Measure everything against the only three things a business counts: revenue uplift, risk mitigation, and cost savings.

The compounding is the whole point. Bottlenecks are connected, so the first workflow you fix makes the next one obvious, and the one after that. You stop 10x-ing a single task and start 100x-ing the business. That is why this spreads once it gets a foothold, and why the person who owns the loop is hard to dislodge.

Put simply: Audit, evals, deploy, repeat. Build on the systems they already own, keep a human on the irreversible steps, and score every agent on revenue, risk, and cost. The loop is what compounds, not any single automation.

Do the job before you have the title

The most useful thing Vas offered is a way in that needs no permission. He condensed a year of learning into a 30-day plan, and the framing is the takeaway: do the job before you have the title.

Week one, build an agent that runs one real back-office workflow end to end, something that keeps working even when you prompt it badly. Week two, harden it: real schemas instead of free text, and every unhappy path you can find. Week three, make it measurable and cheap, with evals, a golden data set, and cheaper models on the subtasks that do not need a frontier one, scored against revenue, risk, and cost. Week four, defend it two ways, as the engineer who made the architecture calls and as the VP who has to justify the spend.

Then you sell, and the sell is an exercise in de-risking. The buyer is a person who does not want to get fired and does want to get promoted, and who sees any change you bring as a risk to them. So you do the first audits for free, prove measured value, and only then charge. Your first few clients teach you more than you give them, and after three of those you are miles ahead of a field that is still mostly empty. As Vas puts it, the demand is real and the people who can actually do this are few.

Put simply: You do not need the title to start. Build one agent, harden it, measure it, and pitch it as both engineer and VP. Then de-risk the buyer with a free audit and get paid on proven value.

Where the margin went

Strip the job title away and this is the same pattern I keep tracing. When a layer commoditizes, the profit pool moves to the adjacent layer that is still scarce and still hard. Intelligence went first, priced by the token and roughly equal for everyone. What stayed scarce is the fit: the messy, on-site, exception-ridden work of making a general model do one company's actual job, safely, and proving it moved a number that matters.

Call that person a forward deployed engineer or call it a function a company builds in-house. Either way, the money in AI is not going to sit with whoever holds the smartest model, because soon that is everyone. It will sit with whoever deploys it best. That is the moat, and unlike the model, you cannot rent it.

Put simply: Intelligence commoditized, so the value moved to deployment. Whoever fits the model to a real business, and can prove it, owns the part that does not commoditize next.

The framework, the examples, and the figures are Vas's, from his breakdown on Greg Isenberg's Startup Ideas Podcast; the plates, the profit-pool read, and the operator's take are mine.