Greg Isenberg sits down with Varick Agents CEO Vas to reverse-engineer the forward deployed engineer role — and hand over a 30-day plan to become one.
Posted
yesterday
Duration
Format
Interview
educational
Views
15.7K
654 likes
Big Idea
The argument in one line.
Because every company can now buy the same frontier AI models, the only competitive edge left is deployment, and forward deployed engineers — who combine consulting-grade business judgment with production engineering — are the ones positioned to capture it.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You're a software engineer or consultant weighing forward deployed engineering as a career path that can pay $150K base up to seven figures.
You run or advise a business deciding whether to hire an FDE, an agency, or a freelancer to deploy AI internally.
You want a concrete week-by-week plan for building, hardening, measuring, and pitching a production-grade AI agent from scratch.
You're already freelancing or consulting on AI implementation and want a sharper audit-evals-deployment framework to sell and structure engagements.
SKIP IF…
You want a hands-on coding tutorial — this is a role definition and business-process framework, not a build-along with code.
You have no interest in enterprise/B2B AI deployment work; this doesn't touch consumer products or indie-hacker SaaS.
TL;DR
The full version, fast.
Frontier AI models are now commoditized — every company can buy the same Claude, GPT, or Gemini stack — so the advantage has moved from having intelligence to deploying it well. That's the job of a forward deployed engineer (FDE), a role Palantir popularized: embed on-site, learn the real (messy) workflow, decide which steps deserve an LLM versus deterministic code, then build, evaluate, and defend a production agent. The loop is audit (map the real workflow) → evals (turn nondeterminism into evidence) → deployment (integrate with existing systems like NetSuite or Salesforce, not replace them). FDEs are valuable because they're rare: strong communicators who are also strong engineers. The 30-day plan: week 1 build a working agent, week 2 harden it against failure modes, week 3 make it measurable across revenue/risk/cost, week 4 defend it like both an engineer and a VP.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Greg cold-opens on the $1M FDE headline number and frames the episode as the clearest explainer on what an FDE is and how to become one.
02:03 – 04:09
02 · What is an FDE
Vas sets up the premise: frontier models release constantly and every company can now buy the same intelligence, so intelligence stops being the moat.
04:09 – 06:16
03 · How Palantir Popularized FDEs
Vas traces the term to Palantir, whose FDEs embedded on-site with an ontology software stack to customize dashboards and agents per client — consulting for the software age.
06:16 – 11:26
04 · Deciding Where Intelligence Belongs
The three-stage FDE framework: business reality, FDE judgment (where AI belongs vs. deterministic code), and the deployed system — with the 95%-of-pilots-fail stat as the cautionary case for being selective.
11:26 – 14:59
05 · What FDEs Earn
Compensation ranges from $150K base plus equity up to seven figures a year; Vas also covers the technical range of the build stage, from no-code ontology workflows to full production code.
14:59 – 17:38
06 · Two Kinds of Judgment: Communication and Engineering
The FDE has to be excellent at both the 'business' side (workflows, cost, incentives, politics) and the 'technical' side (models, APIs, evals, guardrails) — not an average of the two but genuinely strong at both.
17:38 – 20:40
07 · How the Work Really Gets Done
Vas breaks down how a 'simple' trigger like an incoming email hides enormous complexity — 40 senders, inconsistent formats, undocumented exceptions — and why FDEs must sit with workers to extract it.
20:40 – 22:56
08 · Audit, Evaluation, Deployment
The three-part job structure of an FDE build: auditing the workflow, creating eval suites to prove correctness, and deploying with client hand-holding plus monitoring.
22:56 – 27:36
09 · Which LLM to Choose
Vas's company stays model-agnostic, but recommends individual FDEs master one model and one agent-building platform first rather than chasing model-agnosticism prematurely.
27:36 – 31:47
10 · Audit: Finding the Workflow Worth Rebuilding
The audit is often worth more to a client than what they paid for it; Greg notes his agency rebranded 'audit' as 'sprint' because the word itself was a hard sell.
31:47 – 32:57
11 · Evals: Turn Non-Determinism Into Evidence
Evals convert fuzzy outcomes into a pass/fail matrix — run 50 cases, investigate the failures, and route anything unsafe to a human.
32:57 – 38:59
12 · Deployment: Build on Existing Systems
Winning FDEs integrate with a client's existing stack (NetSuite, Salesforce, SAP) instead of forcing a migration, and de-risk adoption through free initial audits and only charging once value is proven.
38:59 – 49:13
13 · The 30-Day Plan Begins
A condensed version of Vas's first year: week 1 build a working agent, week 2 harden it against failure modes, week 3 make it measurable (revenue, risk, cost), week 4 defend the system like an engineer and a VP.
49:13 – 51:34
14 · Final Thoughts
Greg floats a possible cohort/program to walk people through the 30 days, and both hosts close urging people to get hands-on now while the role is still undersupplied.
Atomic Insights
Lines worth screenshotting.
Intelligence itself is no longer the moat — every company can now buy the same frontier model, so the edge moved entirely to deployment.
Palantir popularized the forward deployed engineer role by sending engineers on-site to customize its ontology per client, effectively inventing consulting for the software age.
An FDE's job breaks into three stages: understanding business reality, judging where intelligence belongs, and building the deployed system.
The MIT finding that 95% of generative AI pilots fail traces back to teams applying AI everywhere instead of being selective about which steps actually need judgment.
FDE compensation ranges from a $150,000 base with considerable equity up to seven figures a year for the best combination of consulting and engineering skill.
The million-dollar FDE is not an average of a good communicator and a decent engineer — it's someone who is genuinely excellent at both.
Most workflows described to you in a one-hour meeting are fiction; the real process — with its exceptions, tribal knowledge, and undocumented workarounds — only surfaces when you sit on-site for a full day.
The job of FDE judgment is deciding which of a workflow's steps are risky or low-ROI enough to leave alone, and which few actually need an LLM's nondeterministic reasoning.
You can build an eval for nondeterministic tasks like a presentation by collecting a large sample of past examples and encoding what 'good' looks like as a golden dataset, then layering human-in-the-loop feedback on top.
Get excellent at one model and one agent-building platform before trying to be model-agnostic — model-agnosticism is the company's edge, not the individual FDE's starting point.
There's only one way for a workflow to go right and a thousand ways it can go wrong, so an agent's value comes almost entirely from how well it handles the unhappy paths.
The only three buckets that matter when measuring an agent's business value are revenue uplift, risk mitigation, and cost savings.
Winning FDE deployments build on top of a client's existing stack (NetSuite, Salesforce, SAP) rather than pitching a migration — clients who spent years and millions moving to a system won't tolerate being told to move again.
Employees at a client company are quietly evaluating an FDE's project by one question: does this help me get promoted, or does it put my job at risk if it fails.
Running the first few engagements as a free audit — and only charging once measurable value is proven — de-risks the sale and teaches the FDE more than the client pays for.
A company's own audit is frequently worth more to them than what they paid for it, because most organizations have never mapped their real workflows step by step.
Takeaway
The AI edge moved from having intelligence to deploying it well.
WHAT TO LEARN
Forward deployed engineering is valuable precisely because it's rare to be excellent at both reading a business's real (undocumented) workflow and shipping a production system for it — and that combination, not access to any particular model, is what gets paid up to seven figures.
02What is an FDE
Every company can now buy the same frontier model, so competitive advantage no longer comes from access to intelligence — it comes from how, where, and why it's applied inside a specific business.
03How Palantir Popularized FDEs
The forward deployed engineer role traces back to Palantir, whose engineers embedded on-site with a customizable ontology to build workflows and dashboards tuned to each client — effectively consulting for the software era.
04Deciding Where Intelligence Belongs
FDE work runs through three stages: understanding the actual (often undocumented) business reality, judging which steps genuinely need an LLM versus deterministic code, and building the deployed system.
The MIT statistic that 95% of generative AI pilots fail traces to teams applying AI everywhere instead of being selective about where judgment actually adds value.
05What FDEs Earn
Compensation ranges from a $150,000 base with considerable equity up to seven figures a year for the rare combination of consulting-grade communication and strong engineering.
06Two Kinds of Judgment: Communication and Engineering
The best-paid FDEs aren't an average of a decent communicator and a decent engineer — they are genuinely strong at both, which is why the role can pay from $150K base to seven figures.
07How the Work Really Gets Done
The documented version of any workflow is rarely the real one; a one-hour interview yields a clean-sounding process, but sitting on-site for a full day surfaces the exceptions and tribal knowledge that actually matter.
08Audit, Evaluation, Deployment
The FDE build itself has three parts: audit the real workflow, build eval suites that prove the system behaves correctly, and deploy with client hand-holding plus ongoing monitoring.
09Which LLM to Choose
Individual FDEs should get excellent at one model and one agent-building platform before trying to be model-agnostic — model-agnosticism is a company-level advantage, not where an individual's early value comes from.
10Audit: Finding the Workflow Worth Rebuilding
A company's own audit is frequently worth more to them than what they paid for it, and reframing the word 'audit' as a 'sprint' can remove a client's instinctive resistance to the term.
11Evals: Turn Non-Determinism Into Evidence
Evals turn fuzzy, nondeterministic outcomes into evidence: build a golden dataset from historical examples, run the system against it, investigate every failure, and route anything unsafe to a human reviewer.
12Deployment: Build on Existing Systems
Winning deployments integrate with a client's existing systems (NetSuite, Salesforce, SAP) rather than pitching a migration, since clients who already invested years and millions in a system will reject being told to move again.
Client-side employees judge an AI project by whether it helps them get promoted or puts them at risk if it fails, so de-risking the pitch (free initial audit, pay only once value is proven) is what gets projects approved.
13The 30-Day Plan Begins
An agent's real value comes almost entirely from how it handles the thousand ways a workflow can go wrong, not from handling the one way it goes right.
A 30-day plan can compress a year of learning: week 1 build a working agent end to end, week 2 harden it with schemas and failure-mode handling, week 3 make it measurable across revenue/risk/cost, week 4 defend the system's architecture and economics like both an engineer and a VP.
Glossary
Terms worth knowing.
Forward Deployed Engineer (FDE)
A hybrid consultant-engineer who embeds with a client to learn their real workflows, then decides where AI belongs and builds the production system that applies it.
Ontology (Palantir)
Palantir's customizable software layer of connectors and data pipelines that lets an enterprise unify its data sources into one interface, which FDEs then customize per client.
Token maxing
The early-AI-wave habit of applying a large language model to every step of a process indiscriminately instead of being selective about where judgment is actually needed.
Golden dataset
A curated, labeled set of past examples (e.g., prior presentations or categorized emails) used as the ground truth for building and scoring an eval.
Happy path / unhappy path
The happy path is the one way a workflow succeeds; unhappy paths are the many ways it can fail or hit an exception — most of an agent's real value comes from handling the latter.
Shadow mode
A deployment stage where an AI system runs alongside the existing process without taking real actions, so its output can be validated before it's given autonomy.
Audit trail
A logged, inspectable record of every action an AI agent takes, used to build client trust and to debug failures.
Resources
Things they pointed at.
04:09toolPalantir's ontology software stack
27:36channelCorey Ganham podcast episode (on selling AI audits)
“People at a company don't want to get fired — they want to get promoted. Your job is to help them get promoted.”
Sharp reframe of internal-champion psychology→ newsletter pull-quote↗ Tweet quote
35:40
“Do the audit for free, prove value there, and only get paid once you really prove measurable value. Your first few customers are worth more to you than you are to them.”
“There's only one way that something can go right, but there's a thousand different ways something can go wrong. If you're only building for the happy path, you're worth nothing.”
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogystory
00:00I know it's crazy, but there are people making a million dollars a year as Ford Deploy engineers. But what exactly is an FDE? I know you've probably seen it, but I feel like a lot of people aren't clear as to what it is and how they could become one.
00:16Well, in this episode, I brought on my friend Voss, and Voss is a leading expert when it comes to FDEs with his company, Veric Agents. And in this episode, he gives you his entire playbook, how you could become an FDE in thirty days.
00:31Now, this episode is for people who wanna become an FTE, but also for people who are just interested in what it means, how they can actually use FTEs in their business to be make more money, to be more productive, and I just think this is the clearest episode, the clearest piece of content on the Internet, the clearest masterclass for how to understand clearly what an FDE is, how you could become one, and why it matters.
01:02Enjoy the episode, and I'll see you at the end.
01:13Voss is here, and Voss, by the end of this episode, what are people going to learn?
01:20They're gonna learn exactly how to break into forward deployed engineering or become a better FTE in thirty days. The full roadmap for AI forward deployed engineering. And I don't feel like this has been shared anywhere.
01:31I feel like the term forward deployed engineer is just like on my x feed everywhere. So what I'm hoping for, Voss, is for you to clearly explain what this means and just, like, all the concepts to it and just break it down for me in a clear, easy to understand way so so I could so I could, you know, learn from it, but so others can learn from it too.
01:55And there's a lot of different definitions. Everyone has their own, and I'm gonna give you what I think is the clearest explanation. Okay.
02:01Let's do it. Sweet. So, yeah, this has never been shared before.
02:05This is something our team put together. It's how to break into FD in thirty days. Let's start off with recent developments and the facts of today.
02:13The reality is every company can now buy intelligence. You know, you have a Frontier model being released every single day. Just yesterday, we had Kimi three being released.
02:22Last week was Fable five, you know, or GPT 5.6 Soul. Every company can now buy intelligence, and the reality is intelligence is becoming commoditized.
02:32So the same foundational capability is becoming available to anybody who can pay for it, and that's most companies today. So you'll see here is a graphic where every company has access to the same foundational model.
02:45So if everyone can access it, intelligence can no longer be the moat. I think there was this huge theory that, you know, people will be priced out of intelligence, and that could be the case in the future. But the reality is today, everyone has access to the same tools.
03:00If you go and talk to 50 different enterprise clients, they're all using the same stack. They're all using Claude code, Codex. They're using Cursor for model agnosticism.
03:08They're using GitHub Copilot. It's all the same thing. So the reality is everyone has the same capability in terms of what intelligence tap they have access to.
03:19So where does the advantage go? It goes into deployment. So the edge is no longer who has the intelligence.
03:25It's where, how, and why they use it, and that is the role of an AI forward deployed engineer. It's allowing companies to harness and take advantage of AI intelligence or software previously to make sure that they apply it the best to their specific company context.
03:43Every single company is different in terms of how their business is structured, what processes they have, how things run, etcetera.
03:51And the job of an FD is to make sure that the intelligence, which is general, is specifically applied to this company in a way that benefits them the most. And the advantage will start to become who has that best bridge, that connection between their own processes and the intelligence stack that they have access to.
04:12correct me if I'm wrong, was popularized by the Palantir team. Right?
04:16That's right. So can, you you know, can you tell me about, like, how Palantir
04:22I think how Palantir works with FTEs? I mean, I feel like for a lot of people, Palantir is this black box. Can you can you go a little more into that?
04:30Yeah. It's funny. So I lived in New York for a few years, and I had a ton of buddies who were Palantir four deployed engineers.
04:35So I have a little bit of insight into this. Without sharing what I what I think is proprietary, Palantir has an ontology. They have a software stack that they work off of, and this is full of connectors to software, but also data lakes, which allow people to which allow enterprises to pipe their data into a unified interface.
04:52And what Palantir FTEs then do is they'll actually be deployed on-site. So this is either, like, enterprise customers or the military, the government, and learn their workflows and then spin up kind of workflows, dashboards, you know, agents that will solve the problem for these companies.
05:09So Palantir really popularized the idea of essentially which was what was consulting, but for the software space, they coined the term for a deployed engineer, and it really started to allow their business to take off.
05:20They had a centralized platform, but its beauty was not in, like, how tech forward it was. It was it was in how customizable it was.
05:28And and then these forward deployed engineers would go on-site, customize it per client, and it would really solve their pain points better than in generalized servers.
05:36Cool. And I guess, like, the the thesis is that if it works for Palantir, it can work for everyone else.
05:45That is sort of the thesis. Yeah. And the Palantir, I think, really solved it when it came to the data age where you wanted to unify your data sources and then visualize it in more unique ways.
05:54I think the AI age is going to demand that a 100 times more where every single company is gonna need customized agents, and that's actually what we're here to solve as well with our with our OS. But everyone is sort of coming to the same realization that forward deployed engineers are a massive reason why AI is going to be powerful for businesses.
06:17So someone has to decide where intelligence belongs, not just where it's applied, and that person is a forward deployed engineer as well. So there's kind of three stages to a forward deployed engineer's involvement at a company. The first is understanding the business reality.
06:31So it's how the work actually happens today. And I think this is the part that gets glossed over by people who are, you know, very deeply in tech. You know, in Silicon Valley, we have a mindset where, like, okay.
06:41Well, the beauty's in the software. Like, it doesn't really matter what the business processes are, but I can tell you firsthand, every business is so different.
06:49Even in terms of, like, the same process across multiple businesses. Let's go, like, accounts payable, for example, or or sales, for example, at two different companies. The way that they do that is so different.
07:00One has a 10 step process. One has a 30 step process. One is using Salesforce, Gong, and Chili Piper.
07:09The other one is using HubSpot and Apollo and Clay.
07:14There's the software differences, but there's also the process differences, and there's the things that matter most of the business being very different. When things go wrong, like exception handling, the way that that's being done in a company needs to be documented as well.
07:30They'll either interview people or just observe them work or get, you know, access to their systems, like their ERPs, their CRMs to figure this stuff out. And this is where the bulk of the time goes, in my opinion.
07:43It cannot be understated how important this is both in terms of understanding the business, but also to bring that business along the journey. And this is where communication and analytical ability is incredibly important for a forward deployed engineer.
07:56The way I like to think of an FDE is the best combination of someone very deeply technical who can understand it, but also someone with fantastic communication ability and the ability to get the information out of people that they need to. And this is all encompassing for business reality.
08:13And, you know, you say the FDE goes on-site. When you say on-site, is that, like, literally, like, walks in the office and starts, like, speaking to people and stuff like that, or do you mean, like you know?
08:26It can it can certainly be done remotely. Yeah. And, you know, there's there's certain times where that's, you know, required because the company itself is remote Right.
08:35Or, like, the people of the function are not all in one office. But I will say a large majority of the time, it is on-site. I know that Palantir does this very heavily.
08:43We do this as well. And it's not just because, you know, you can't get the information remotely, but it's it's it's actually more so because the relationship that you build with the person like, you know, you're on-site.
08:55You're part of the team. You'll uncover far more information that way. Right?
08:59Like, if somebody will if you schedule a one hour meeting, for example, somebody will walk you through what they think is the job. But if you're on-site with them for the full eight, ten hours, whatever it is, you're actually experiencing the job.
09:12Like, when something goes wrong that's not really documented in an SOP or in, a in a Word doc or a Google Doc somewhere, you're going to see that play out. You know, even the consultants at McKinsey, they do this. They'll go on-site to a mine, and they'll sit with the miners, and they'll watch them do their work because it's so much more powerful to establish that relationship and get the information that way.
09:33Yeah. The second step is FDA judgment, which is where does intelligence belong and where does it not? I think when the AI wave first started, we saw a lot of, you know, let's just slap AI everywhere.
09:45Let's let's give everything to the model, and let's let's let it figure it out. And this is what led to token maxing and hallucinations, and you have the the MIT stat that ninety five percent of generative AI pilots fail.
09:57Again, now the industry is sort of shifting gears, and they're realizing that, okay. We actually need to be very selective about where we apply this intelligence. And we also need to be selective about how we design the new stack for this intelligence to play out.
10:10So, again, for example, you have a 10 step workflow. It might be that, you know, that workflow should not be changed by AI. You know, maybe it's too risky or maybe it's not high enough ROI.
10:22Maybe it's already pretty automated. Why do we need to do bring AI into it? It also could be that of those 10 steps, only three of them actually need judgment.
10:33Right? So categorization of this, you know, lead in a CRM tool, that might be a little bit more nondeterministic, so we're gonna bring in LLM there for for judgment.
10:42But the rest can be solved with with, you know, if then else statements. It can be solved with API calls. And this sort of judgment is actually, you know, far more complex than I'm making it out to be even, but it belongs with the FDE.
10:56So the FTE both has, again, the business reality, which is the consulting style, like, communication style approach, but also the technical judgment so that they can determine based on their technical background, okay. I think that this design is going to be, you know, risky.
11:11We're gonna have 80% accuracy. It's not worth it versus this other, you know, workflow will will have a much higher ROI. We'll be able to build it much faster.
11:19It's lower risk, etcetera. And that sort of back and forth judgment is where an FDE really shines. It's bridging the gap between the business and the technology.
11:27If you you know, just curious. Like, if if someone listening to this, like, wanted to become a Ford deployed engineer in New York City that's doing this sort of stuff, like, how much money could they make?
11:39A lot of money. You have no idea how expensive it's gotten both from a we're hiring perspective, but also in terms of what the market's demanding.
11:47This is the hottest role in technology right now. I mean, you could make anywhere from a 150,000 base with considerable equity to I've seen the roles go up as high as a million dollars a year, and I'm not joking.
12:00These are extremely well compensated roles if you are the best combination of consulting and technology.
12:08Deployed AI system. Finally, the last step is actually going out and building the software itself.
12:15This is where it varies wildly company by company. For example, at Palantir even, they have some FTEs that, you know, you're not actually writing code. You're mostly, like, spinning up workflows, like text.
12:26You're chatting with the software of the Palantir ontology to create, like, some dashboards. And to the extent that you're writing code, it's SQL.
12:32But there's other companies where you are fully writing, like, production code either on-site with the client or you'll go back and and do this, but it varies wildly. So there are some FTE roles where you're going to be writing production code.
12:45You need to have a background in software engineering and, like, really be confident in your ability there. There's other FTE roles where it's far more technically light, and you can, you know, chat to build on top of an existing platform.
12:58So this is the part that varies wildly. But either way, you need to have a very good understanding of the software because when the client has an issue with, hey. This doesn't work right, or we have an issue in production, it's basically your ass on the line, and you have to know who to call, what to do, and how to fix it.
13:14Totally. In summary, FTEs are in demand because they control how intelligence enters the business, how it's used, and that is where all the value is today in the AI age.
13:24Everyone is coming to this consensus, and that's why FTEs are extremely valuable.
13:28Well, it's also in demand because it's new as well. Like, this like, there wasn't Intel superintelligence on tap five years ago. So sue not only is the idea of superintelligence on tap just absolutely absurd, many trillion dollars of, you know, money is gonna be changing hands over the next few years, but the idea that now you need a person to actually like, people are realizing, hey, you actually need judgment.
13:56And, hey. You actually need to, like, to be, you know, be a systems thinker. And, hey.
14:01Like, actually, token maxing isn't the best strategy.
14:05Like, there was, like, a moment in time where token maxing, like, people were people basically were agreeing that token maxing was the strategy. It was just like, hey.
14:15These models are so good. Let's just let them do their thing. That was, like, the thinking.
14:20Yeah. That was a a funny period in time. I would argue we're still not fully out of that.
14:27I mean, this is a brave new world for everyone involved. And, I mean, I I have horror stories of of of like, c suite executives I've talked to who have blown through their entire $10,000,000 clogged budget in, like, three months.
14:40It was supposed to last them a year because they gave it to everybody. It's token maxing, and everyone's spinning up whatever they need. And and and the the sad reality is it didn't really move the needle for the business either, and it's because that business didn't really invest heavily into forward deployed engineering.
14:54And so I think you're totally right. Cool. Let's keep going.
14:59Sweet. So we've we've already alluded to this, you know, pretty heavily prior, but I wanna really make sure I hammer down this point, which is that there's two sort of streams of of kinds of judgment that are required, and it's very rare in a in a single person.
15:14So I think the unfortunate reality is, and this is what's gonna happen. It's already starting to happen, is as, you know, we go from the token maxing, let's go all, you know, token maxing, go, go, go, to now the same thing on FTE. Let's go, go, go.
15:27Let's hire a bunch of FTEs. I wanna be very clear about what the role really demands. I think there's a lot of FTEs who are, you know, unfortunately, neither the best communicators and neither the best software engineers.
15:38I would strongly urge them to strengthen both of those skills. It's both the understanding of workflows, cost, incentives, risk, adoption, business value, you know, the politics of the internals of of a company.
15:50These are all things that you have to manage, and consultants here are incredibly strong. Right?
15:56You'll talk to McKinsey engagement managers, BCG, Bain engagement managers. They'll be very good at this side. The other side is what they might need some more support in.
16:04And same thing. Software engineers will be very good at the right side with models, systems, APIs, data, code reliability, evals, guardrails, you know, more AI centered turns, harnesses, post training, fine tuning.
16:17These are things that are more on the technical side of the aisle, and software engineers are really very good at this, but they need to also then kind of drift towards the business side by understanding the left side of the aisle. And FTE is the best combination of both of these.
16:31It's not an average combination. It's not the worst combination of both where you're not the best communicator, but you also can't code.
16:37It is truly the best of both, and that is the million dollar hire where the FD can turn business understanding into working software end to end. They can do both sides perfectly.
16:47Yeah. I mean, put another way, it's like if you understand art and you understand science and you could speak both, you have what it takes to become a the million dollar FD.
16:59The the hard part is, like, usually, the people that are good as good at science are sort of good at science, and the people that are good at art are kinda good at art.
17:10But there are, you know, there is some overlap in the Venn diagram.
17:15Absolutely. And and that's why it's such a rare role, but I also firmly believe, and that's kinda the whole point of this presentation, is that you can become this. It's it's not out of the realm of possibility to become much better at both of these things.
17:26It just you need it cleanly laid out. You need a road map, and that's what I hope that I can provide by the end of this call.
17:36So first, for example, let's understand how the work is really done because the documented process is very rarely the the real process.
17:46Right? So an email might arrive. Now this is extremely simple, but the reality is it sounds like a clean trigger, but it's it's far more complicated than that.
17:54It arrives from 40 plus senders. No two of them are formatted alike. The data is different.
17:59Some of it's in a PDF. Some of it's in a screenshot. Some of it's in an Excel spreadsheet, or it's buried in a forwarded thread.
18:05It's it's far more complex than it makes out to be. So if you didn't look into this, if you weren't an FTE and you just asked the person for, hey.
18:13What's the first step of the workflow? They'll tell you when email arrives. And all of a sudden, you're building for a system that doesn't map to reality versus the reality, which is that it's so complicated.
18:23And half of them are exceptions. It's the same as last time. It ignores the second attachment.
18:27Sarah already signed off on this one. There's no consistent subject line, so you can't route without actually going into it. And, usually, the reality of how to play this is in one person's head.
18:38So one person will know, okay. Yeah. Well, when I see this email from this person, I'll send it to this this vendor or to this part of our procurement team, but that's not written down.
18:46And if you don't sit with that person, kind of coax this all out of them, they're not gonna remember to even tell you. You would think about, like, at your job today, I ask people viewing this, how easy is it for you to really write down every single exception that might happen happen in your job?
19:02I was a software engineer at Medan. If people ask me for my job, I'd say, well, yeah, I code all day. I'll get a task, and I'll I'll work on it.
19:08But that's not the reality. Right? The reality is I have meetings.
19:11You know, this happens. Something breaks in prod. I have to go fix it.
19:14That's what we're getting at here. The second step is, oh, it's copied into a spreadsheet. Same thing here.
19:19You get the idea. One's a real one. Two are stale.
19:21Data validation, it's rekeyed by hand. Columns drift. Same thing with checking into an internal system.
19:26I won't get into all of this. You get the idea. Every step is extremely complicated.
19:31So that's what understanding the work really means. It takes time, and it takes effort to sit with a person responsible and sometimes multiple people responsible. Usually.
19:42Usually, it's multiple people. Very, very often. Yeah.
19:44Mean, if this company has, like, 5,000, 10,000 people working in it, chances are you have a lot of people working on the same thing. Then you decide how the work should operate when intelligence is built in. So, again, where does deterministic software live in?
19:56Where does the agent act? Where does the human approve? Where does the record get updated?
20:00I think the best combination of sorry. The best solution of AI for most companies is a very good combination of deterministic software.
20:09Probably the majority of it is that, but then, obviously, the the judgment that API calls to LMS can provide. And then finally, human loop.
20:18So this is just a a fancy little little digest, but it's really the agent that can then be deployed into existing systems. It's doing the first half, which is intake validation, agent drafting. Then you have a human in the loop for approval.
20:30It's something that I strongly recommend my FTEs to push for in a in a in an agent implementation. Once you get approved, it'll then go through the latter half of the steps.
20:39And that's what you're building. So the job of an FTE when you're building has three parts. It's obviously auditing, then creating evaluation suites to make sure the system behaves correctly.
20:48Is This extremely important in the AI age. And then finally, deployment, which is both handholding the client to make sure they're adopting it, it's working well for them, but then also the software side, making sure that nothing breaks. You're monitoring all the metrics that matter.
21:00You're monitoring KPIs, SLAs, and everything needs to be top notch for somebody to really trust you as an FTE. And every stage is a prerequisite for the next.
21:09So for an eval so prove the system behaves correctly. So in a scenario where the outcome, you know, is nondeterministic, meaning, like, it's tough to say what success looks like, how do you create an eval?
21:26Or can you create an eval for more creative task or tasks that are hard to, like, understand if it's successful or not?
21:36Yeah. For for, obviously, for, you know, more nondeterministic tasks, it's much harder.
21:40Right? It's much easier to say, okay. Was this email categorized correctly?
21:44Because we have 10,000 previous emails to go off of, and it'll be the basis for our eval set. But even for tasks where it is nondeterministic, like, for example, creating a presentation.
21:54Right? There's a million different ways to do it, and sort of the beauty is in the eye of the beholder where, you know, one thing looks good to me might look bad to you.
22:05Here, it's very helpful to have as much previous data as possible. Obviously, if you have 5,000 previous presentations to go off of, it makes it a lot easier to create this golden dataset of what we think matters. You know, you can say, you know, always put the logo in the top left, always have larger font of the styling, etcetera, etcetera.
22:22But this is obviously where you'll never get to a perfect result with just evals. You need human in the loop feedback to make sure that going forward, you at least have a feedback mechanism that improves your harness, if not, like, post train or fine tunes the model that you're working under. So on one hand, like, get as much data as you can and kind of determine, like, what looks good, what looks bad, identify, like, what matters to you, but also then always bake in human loop feedback.
22:48Because even with a good dataset, even with good emails, you'll need to have them constantly improved. And that's where that feedback mechanism comes into play.
22:56And I've noticed, like, in this entire presentation, this entire podcast, we haven't really spoken about which LLM to use.
23:05Are you, like, basically agnostic in terms of, like, working with Anthropic or OpenAI or Google or like, if you're an FDE, basically, how do you think about which LLM to work with?
23:21Yeah. Great question, actually. Something I probably should've touched on.
23:24We, as a company, are extremely model agnostic. So we think our value lies in our ability to be switching from one model to the next and making sure that your accuracy only improves, your cost only goes down, and you're not marrying to one intelligence provider, which we think will be a an asset going forward.
23:41You don't want to monopolize your intelligence, your inference layer. That being said, if I was in FTE today or if I was trying to become the best FTE today, I would stick to one model and one agent building platform.
23:53OpenAI has one. Claude has one. Agent SDK, etcetera.
23:56Every single model provider has one. Get very, very good at one of them because that will be the foundation that you then, you know I mean, let's let's try out Claude tomorrow if I'm already good at OpenAI's, you know, agent building platform. Okay.
24:08I feel more confident about that. Let's go to Kimi three or GLM 5.2. Let's see what the open source models can do.
24:13Let's build a proprietary harness. That's how I would go about it. But I wouldn't really worry about being model agnostic when you're starting out as an FD because that's, again, not where your value lies.
24:23Your value lies in how good are you at understanding both sides of the aisle because that can then apply to any model.
24:29Totally. And it's we're getting to a point where the models are very similar in a lot of ways.
24:40Yeah. And a lot of the big players are you know, they have like, Google will have their frontier model, but they'll also have an open source model, for example.
24:49And so now you're getting to this place where it's like, okay. You can play with their open source model. You can play with their, you know, frontier model.
24:57And and so I I expect that the arrow of progress around LLMs is they're gonna have a bunch of different products for you to play with. So, yeah, I agree.
25:07Like, if you wanna, you know, pick pick an ecosystem, bet on an ecosystem that you believe in for whatever reason, be the best at that ecosystem.
25:18And then as you become the best, then it's like, okay. If you want and you're working with a client, for example, and for whatever reason, another model makes more sense, then great.
25:30You know? You Yeah. You can go and recommend that.
25:34Absolutely. Yeah. I would say that that's exactly right.
25:37And then just to really hammer the last point in, your ability to determine what model is best for a task relies on your understanding of various different models. You're benchmarking them along the way, but to your point, don't put the cart ahead of the horse. Like, really get good at one before you then try to venture out and make that understanding.
25:54I would totally agree. Yeah. I mean, that's like
25:58yeah. You don't wanna, like, hammer a specific, you know, model when you don't understand what the system and the set of tasks are.
26:09It's like Mhmm. The equivalent of, you know, you're a waiter and you just hand someone a glass of Pinot Noir, and they're like, I didn't ask for that.
26:19You know, you you know, a good restaurant has a sommelier, and and then and sommelier's job is to understand what is your palate.
26:27Do you like dry wines? Do you like wines from, you know, France you know, Southern France or Northern France or you know?
26:39That's the wine guy, so I I guess, you know, the analogy might break down. But that idea, I think, of just, like, understanding what people want first and then deploy makes a lot of sense.
26:52Yeah. I mean, honestly, I thought that was pretty good. Like, similar year of of agents is an FTE.
26:57Like, you really go in and figure out what they want, and then you give it to them. Right? You might give everybody pinot noir.
27:01It might work for some of them, but it's not gonna work for most. And that's why, again, most AI pilots fail. 100%.
27:10Sweet. This is, more of the same. Find the workflow worth rebuilding.
27:14I'm gonna link this. I'll have Greg link this this document, you know, in the in the in the channel. So if you guys wanna dive in deeper in here, but the idea is, again, the same.
27:22Collect the context, trace the FD findings, figure out the bottlenecks, the repetitive work, the judgment points, all that stuff, and then produce the operating map. And this back and forth is why having the understanding of the business and the tech is super important.
27:37Cool. By the way, if you go back to the audit, like, if you wanna be an FTE, you know, we just had an episode with Corey Ganham, who he came on the podcast, and he basically was he talked about selling audits as a way to to learn about someone's business and then deploy AI afterwards.
27:58Like, you can sell the audit. Right? Like Yeah.
28:01In charge of the audit. And then the implementation, you can charge, like, a monthly fee or you can charge a onetime fee.
28:12Yeah. So, actually, we're in this exact business of, you know, implementing AI across the largest companies on the planet, and we require every single engagement to start with an audit, which, you know, obviously costs money to the business.
28:26This is extremely valuable. I think, again, like, there's a lot of misunderstanding. Like, you know, you can just throw AI on the on the the on the company.
28:35The audit is worth so much money to a business. I mean, we've had companies that tell us, like, the audit was worth 10 times what they paid for it, so it's better than McKinsey because it's so telling.
28:46AI is so new, like you said. No one really understands how to go about an audit. But if you're able to say, like, look.
28:53Here is in your department. Here are all the different workflows, and we've mapped them out very cleanly.
28:58Right? We have the full steps, the back and forth, the exception handling. We're gonna map that out for you, and we're also going to tell you what we think is worth automating versus what isn't.
29:08Give them that priority map. Give them that matrix, that ROI matrix, and then go ahead and show them how you would build it and show them the ROI, show them the use case.
29:18That is worth so much money to a company. I think this is something that even most consulting firms are not able to figure out, and this is where you have an edge if you are really up to date on AI and you actually know, live, and breathe it yourself.
29:31The audit is worth a ton of money to a business.
29:35Totally. It's also a chance for you to, like, build trust with them. Yeah.
29:40You know what mean? And and show them how you work and underpromise and overdeliver.
29:47And and it gets their creative juices flowing around like, okay, I didn't realize that, you know, because you're producing like an operating map. Right?
29:55So you didn't realize like, oh, hey, like, you know, I never thought about that use case or I didn't think that, you know, this would produce this expected business value, maybe it's worth investing in.
30:08Absolutely. It's funny. Like, you know, when we first started, you know, the company, it was last year.
30:13This is before FTU is a really big thing. We used to call the audit the medicine that neither one of us wants to take. Right?
30:21Like, a lot of companies are like, oh, like, I have to do an audit? Can't you just, like, token max and start building? But it really is so valuable, and they realize that as the audit goes on.
30:32Yeah. We because we we we also have an agency called LCA, and LCA is well known for building like, working with the biggest companies on the planet and then taking their products from a product perspective and bringing them into the AI age.
30:50So, like, from a you work with, like, a Dropbox and what is an AI first version of Dropbox or Slack and AI first version of Slack look like. And we started doing audits as, hey, let's audit your product first.
31:03What we noticed was the word audit was a tough pill for people to swallow. And we just rebranded audit as a sprint.
31:13So it'd be like it was a design sprint. We just kinda like and we, like, you know, brought in the the the concept of an audit with it.
31:24So we noticed that that that worked better. So
31:28just just a little tip for folks. Super helpful. Yeah.
31:31For some reason, people have an allergic reaction to the word audit.
31:35I mean, they think of they think of, like, a tax audit.
31:47Let's keep going. Again, deterministic software versus an agent versus a human in control. I'm not gonna beat a dead horse.
31:53You gotta prioritize the high volume workflows where the improvement is large enough to matter. That's your job as an FDE is to figure that out firsthand.
32:02Evals, you turn nondeterminism into evidence. You gotta make sure that you have the right data, the required steps. It matches the expert, and it's safe to act on, and you gotta make this kind of matrix.
32:12And wherever you feel like it's not safe to act on, you know, you route it to a human, and you create an evaluation report. Right?
32:19So you have 50 runs and 41 of them passed. Of the nine that didn't, let's investigate why.
32:25You know, five of them had missing data. Four of them had the wrong record pulled, and then you use that to improve the system. Greg, you touched on this earlier, like, how do you set up evals?
32:33This is sort of the the framework that I would use.
32:39Yeah. Just so yeah. It helps to just have, like, a a decision tree, a matrix when you're thinking about things.
32:44Again, like, because everything is so new, you could go a million different ways, but, you know, I'm sure there's other ways to do this, but this is ours. And this is just how we kind of think about things at a high level.
32:54It depends on a case like its basis for sure. So how do you make it deploy and work inside the business? This is, phase three.
33:01The first one is the audit. The second one is Eval's. Third is deployment.
33:04One, we really preach about, like, integrating with what already exists. I think a lot of AI folks are forcing migrations to, like, new software. And the reality is, and this is a tip that I give to all my FTEs, you have an edge if you're able to build on top of their systems.
33:19So, you know, one of our clients, for example, said that they spent, you know, a couple of years, a couple million dollars moving to NetSuite, which is an ERP software. And if your AI solution is like, hey. We have to make you move off of NetSuite, they're gonna tell you to get lost.
33:34But instead, if you're saying, which is what we do, build on top of NetSuite, make it much better, and integrate that NetSuite with your Salesforce, with your SAP, with your Concur, Expensify, Gong, you know, every other piece of software Workday, that is a much more powerful system, and that is where all the value lies.
33:54Then if you can test it in a controlled environment and really scale up from, you know, deployment to shadow mode to increasing autonomy to then being deployed in production, that is gonna be your edge as well, where you're not forcing a massive shift.
34:10You're kind of walking through that journey. And to our point earlier of why you meet them in person, it's because it's a lot easier to kind of guide them along that journey if you've met them face to face versus if you're just a guy behind a computer screen saying, hey. Now we're gonna flip a switch and AI is gonna run your business.
34:24That's a a much different much more polarizing approach.
34:28I mean, it makes sense. Right? Like, you're you you did the audit, and then if you're gonna pitch to them, hey.
34:34You've been working with this software stack for the last twenty years. All of a sudden, go switch to this thing, and it's gonna cost you a bunch of money.
34:43And there's just like so many unknowns, like, that is a tough pitch to sell.
34:50You know what I mean? And, like, you want to if you're pitching anything, you want to pitch something that feels like you're fishing with dynamite. So it's like, how can you, you know, how can you fish with dynamite?
35:02You just say like, hey, you're you have this system and the stack.
35:06You're it's it's worked for you. I'm gonna make it better, and it's going to help you all be more efficient.
35:18It's it's gonna help you reach customers faster. It's gonna drive value for customers.
35:24It could increase revenue. Like, when you start saying things like that, it's like, okay. No brainer.
35:28No brainer. No brainer. Also, you have to keep in mind that you're pitching to people at a company.
35:34And people at a company I'll say the thing that people don't say, which is they don't want to get fired. Right? Like, they want to get promoted, actually.
35:44So your job is to help them get promoted. How do you help them get promoted is probably not by moving from one ERP to another ERP.
35:53That may be marginally better. You help them get promoted by driving value cost effectively.
36:01If you can drive value cost effectively, everyone's high five high fiving. Right?
36:07Because when performance reviews comes around, you know, you the the employee, the executive can point to, I worked on this project.
36:15Yes. I worked with an outside agency like LCA or Veric Agents or individual FDE freelancer.
36:27But as long as you help them do that, that's what's gonna help them get promoted.
36:33Yeah. Totally. And and and just to, again, like, double down on that, they view you as a risk.
36:39Right? They can just sit by and let things stay the same and status quo. They'll be fine.
36:44But if they instead bring in an FDE who's gonna change stuff up and maybe it fails, like, they're worried. If this fails, it's a terrible look on me.
36:53Forget, like, migrating to a new another ERP. Even just you being involved at all is a risk to them. So you have to derisk this as much as possible for them if you really want to sell yourself into a company.
37:05And what I strongly recommend is, like, do the audit for free. Like, get your foot in the door, prove value there, come up with a plan, and then only get paid when you really prove measurable value.
37:18That is what I strongly because that derisks the whole thing. Your first few customers, if you're really starting this out, will teach you so much. They are genuinely worth more to you than you are to them.
37:29But after you have one, two, three of those, then you can start charging for this because you're going to be leagues and miles ahead of everyone else in the space. I promise you it's still so early.
37:40I know this from our company as well. There is so much demand for people who really know how to do this. And quite frankly, there aren't that many people who know how to do this.
37:50Get started. Get your feet wet and and really prove that you know what you're doing, and that's derisking the whole thing for them.
37:58Totally. And it it's just gonna give you the confidence too. You know?
38:04Yeah. And you'll know what matters to them when you're selling. Like, you can touch on different aspects that speak better to this person in the function.
38:10It's all really valuable. If I had to put one page cemented burned in everyone's brain, it's this one, which is you go from audit to evals to deployment.
38:21There's some steps in the way you build, you observe, and you improve, and the loop runs again. Because once you improve one system, the next one becomes extremely clear. There's always interconnected bottlenecks where one workflow is impacted by something upstream and it frees up something downstream.
38:39And this is why AI is so pervasive in an organization. It's because once you have it in one place, you're going to need it everywhere else so that you're not just, you know, 10 x ing one workflow, 10 x ing another.
38:50You're 100 x ing the entire business as a whole. And that's your job as an FTE is to go from audit to eval to deployment over and over again.
39:00And the next stage that I'm gonna show is the thirty day plan of how you can get there from zero to one. If if I was starting from scratch, how would I go about it?
39:09And you did this, by the way. You you started from scratch. Right?
39:12I didn't know this, but you were you're an engineer at Meta. Right? And then you sort of learned how to do this.
39:20Yeah. Absolutely. I was an engineer at Meta for a few years working on a different a couple different products, but I was never a consultant.
39:29I would never really understood what matters in businesses as deeply as I do now, and we got started again just by by doing it. And we we we had this thesis that, like, AI needs to be applied, and it allows us to get ahead of the curve. But you never learn by, you know, reading, and and only learn by doing it.
39:49So the goal from this is is to do like, if I could condense what I did over a year and really had the biggest learnings, biggest wins in just thirty days, this is what I would do.
40:01So the first step is build an agent that can complete a real loop. Right? Build an agent that's actually useful as a workflow.
40:08So, like, ask CHADGPT what is one real enterprise workflow in a function of the back office.
40:18It could be procurement, logistics. It could even be front office. Could be sales, anything.
40:23Get the workflow in as granular of a detail as possible and build an agent for it. Even today, it's very hard to build agents.
40:32Right? We think that it's a solved science. It's not.
40:35There's a thousand different ways to do this. Everyone has different definitions of an agent. My definition is this.
40:41If I give you a task, can you solve it in as much detail and as high enough accuracy as possible? It's different than me prompting Claude to go do it.
40:52It's far more in the background, and it has much more of a repetitive motion where I'm not reliant on somebody prompting perfectly to make it happen. I can prompt like an idiot, and it will still happen.
41:03That's my kind of requirement for you when you're solving for this. There's a bunch of different, you know, aspects to this, but if you have seven days to work on this, you'll be able to pick it up.
41:13Agent looping, then tool usage, then guardrails, then context and memory, then the audit trail, which is incredibly important.
41:20I wanna hammer down here a little bit. If you can't show the client what the agent is doing, they will never trust you. There's a big fear in AI agents today that, okay, it's gonna go off and do something.
41:31It's horrible. There's lot of fear mongering as well. I won't say from who, but everyone knows who I'm talking about.
41:36You need to show that the agent traces are logged. Everything and this is a software engineering problem. So if you can do that, you're a step ahead.
41:43And, again, there's a full day for each of these things. To clarify, if you're, you know, working twelve hours a day, I don't expect you to be able to pick all this stuff up perfectly on each every single day, but this is what I mean by, like, a thirty day plan.
41:57You can space it out as you need. It's not like you have to get it done in thirty days. Then a real workflow, then a checkpoint.
42:02The checkpoint, the last day, is you have a working agent with tools, guardrails, deliberate memory, and a full audit trail for one task. You might not even understand the task the best, but this is just to get you well versed in building agents.
42:18The second week is turning that demo into a system that can recover. Again, very heavily on the engineering side. So a defined JSON schema, not free form text.
42:27You're validating schema. You have failure modes. And, again, I wanna call it failure modes.
42:33Exception handling, and we also see in thirteenth day is failure handling, is also extremely, extremely important.
42:41This is where going in deep into a client matters because if you understand, hey. When something goes wrong, how does it go wrong?
42:48And let me build the agent around that, that is extremely important. It's far more effective than you're building an agent that solves for just the happy path.
42:57It's called the happy path. If you're building for the unhappy paths, the 1,500 different ways it can go wrong, your agent is worth a million times more.
43:06The way I say it is this. There's only one way that something can go right, but there's a thousand different ways something can go wrong.
43:13So if you're only building for the way it goes right, you're worth nothing. If you're solving for all the exceptions, that's where you are worth something as an agent.
43:22That's week two. Then week three is where you start to make it measurable and economically viable. Right?
43:30So you'll have the retry logic. Yes. This is more engineering.
43:32You'll have the golden dataset for evals. You'll make sure that it improves over time. But you'll also start understanding, okay.
43:38This is what we talked about earlier, Greg. Looking at cheaper models for subtasks, looking at, you know, less SOTA, less Frontier models.
43:47Can we get this job done with a Gemini Flash, or can we get the job done with a Muse Spark or probably not a llama four, but, you know, there's other models that can that can be a good fit there. This is where you can start to do more or more of this test, which is we have an agent now.
44:03Now let's try to optimize it. Let's try to measure, okay, how much is it really moving the needle? If I deploy this in production, how much time am I saving?
44:09How much risk am I mitigating? How much revenue uplift do I have? There's only three buckets of measurement that matter for a business.
44:16It's those three. Revenue uplift, risk mitigation, and cost savings.
44:20So you need to measure your agent across all three of those buckets. And at this checkpoint, you have, you know, an evaluated agent with known failure modes, measured costs, and a golden dataset. And the final week is defend the system like an FDE, which is all of the business around it.
44:36It's the pain points. It's why AI belongs. It's the architecture behind it.
44:41It's the iterations. You know, When you first built the agent, it got this wrong, but then it improved over time. Accuracy went from, you know, 70% to 95%.
44:51And the economics around it. So how much time did you save? The error reduced again.
44:54Risk revenue cost. We talked about this. And you rehearsed this as an engineer.
44:59So what was the architecture? What were the decisions that you made? And then you also rehearsed this as a VP.
45:03Like, what was the problem that you solved? What was the outcome? What was the evidence?
45:06What was the risk? And this week is where you're going to know, you know, was the system that you built worth the salt?
45:14Was it worth the investment? How much could you charge for this when you build it for a customer? That's what this week is for.
45:21And I strongly recommend that during this week, you pitch your agent to businesses because they will tell you, like, you know, did I get you'll you'll pitch them.
45:32Did I get this right? Did I get the economics right? Am I thinking about this the right way?
45:35And they'll tell you point blank. No. Or I want it built this way.
45:39And you'll start to see, like, okay. Now for my next FTE engagement, starting out with an audit when you're actually embedded with a customer, you'll learn much more about that.
45:49Obviously, this thirty days is you're not embedded with a customer because you can't because you have to become an FTE first. That's when you can finally start to pitch yourself and be involved in a company. So if I had to zoom out, this would be the thirty days.
46:03It's doing the job before you have the title. So on day 30, you understand forward deployment engineering, but you also have evidence that you can do it. And if you pitch this to a company, they'll be much more likely to give you a shot, and that's my goal.
46:15Foss, this is this is perfect. Like, this is exactly what I would recommend to you.
46:21What would be so cool is if is if you actually taught people how to do this. Right?
46:29And, like, spent thirty days with people to actually do this. Maybe maybe we do it together, just an idea.
46:39If people are interested, I'll just include a link in the pinned comment on YouTube.
46:46I'm just curious if people people are interested in, like because it it might it might feel overwhelming for people to do this on their own.
46:56I mean, I still think you could do it on your own, by the way. But I wonder and and by the way, I'm not promising anything. I'm just curious.
47:02Are people into into some sort of program for this?
47:18Like, it just takes so long. I I remember I was in computer science school in 2008.
47:24No. 2009 and at university, and I remember the App Store had just come out.
47:34It was so clear in 2009 that mobile apps was the next wave. Just like it's so clear right now that AI agents and AI is the is the isn't even the next wave. It's the wave.
47:47And I just remember the textbooks at the time, and I went to a top university. Textbooks at the time and the course material was like, you know, building old school software.
48:00And I remember going to a teacher, a professor, a well known guy, and saying, why can't we why can't you teach us how to build an Objective C and to build for the App Store?
48:12And he was just like, yeah. It's just not in the textbook. Just not in the textbook.
48:17And that's when I, like I was like, I'm gonna drop out of this. I'm I'm dropping out because, like, I don't wanna learn yesterday's stuff.
48:26I wanna learn tomorrow's stuff. Now there's always the argument to be made that you need foundational work.
48:34And so, like, I learned a lot in university around, like, foundational stuff, around maths and physics and stuff like that. I actually think that that stuff was really helpful just in, like, learning how to think.
48:46But, like, the actual tactical stuff did not really learn.
48:52Yeah. I I I do you know, I I wanna say, like, this time is different, like, just because it's so powerful.
49:00Like, AI is so like you said, it's the wave that I'm I'm hopeful that universities are gonna pick up sooner than later, but for some reason, I feel like you're right. I don't think it's gonna happen anytime soon.
49:29I think, you know, like you said, you might not find this in university, but you're absolutely gonna find it on YouTube.
49:36Like, Greg is teaching everything that you need to know and Twitter as well. Those two sources are gonna be where everything is released. I mean, even Mark Zuckerberg had to come back to to Twitter who announced, you know, the latest model from Meta.
49:49That's where everything's happening. Study the game there, and you've got a great coach right in front of you with with Greg.
49:56So, hopefully, that, you people know, are really taking advantage of this time where there's a a significant alpha from going out, learning, doing it yourself, being scrappy with it versus
50:05waiting for a university to come by and and and teach you this because that's not gonna happen anytime soon. And it's free. Right?
50:12You can listen to this It's free. And apply it's free. So it's just like, why not?
50:16Right? Yeah. Voss, thank you for being generous with your with your, as we say on the channel, the sauce and the tactics and just, like, breaking this down so clearly.
50:27I've been following you for a couple years now almost, and you're a must follow.
50:33I'll include links on where you can follow Voss from Varic Agents in the show notes, in the description.
50:41You know, please comment what you what you thought of this episode because I enjoyed myself with Voss. I'd like to have him back on the podcast again.
50:49Hopefully, he he's down to come back on, but please let us know. I read every single comment. You wanna like and subscribe for more of this in your feed.
51:02Greg, you're a legend. Thank you for having me on. To the people, I believe in you.
51:05I really believe this is a fundamental shift in in how work is done, and you are you're if you're listening to Greg and you're and you're you're on this pod you're you're watching this, you're already a step ahead. I'll be reading every single comment too. If any questions you have for me, let me know.
51:18But I would say, like, go out and get it. Go out and get the job done.
51:22Make make the most of of your ability to understand AI, and it's still so early. So get ahead of it while you can. Greg, thank you for having me on, man.
Greg Isenberg opens with the number that makes the whole episode worth clicking: some forward deployed engineers are paid seven figures a year. What follows isn't hype — it's Vas, CEO of Varick Agents, walking through exactly why that number is real, where the role came from, and the audit-evals-deployment loop that turns a commoditized AI model into a business-specific system worth paying for.