The Roles This Book Trains

The market is inventing titles faster than it can define them. Most of those titles are the same discipline at different depths: the discipline this book teaches. Here is the map, and exactly how far the book carries you toward each role.

The Question Behind Every Title

The historian Yuval Noah Harari has posed the hardest question in modern education: for the first time in history, we have no idea what the job market will look like in ten years, which means we do not know what to teach young people today. The old answer was simple: teach them to code. That answer is breaking, because AI learns to code, and within a year it may write most code better than most humans. Teaching syntax is teaching a skill the machine is absorbing in real time.

This page is the book's answer to Harari's question. Do not train syntax-writers; train the people who stand above the machine: the ones who specify what to build, supervise the AI Workers that build it, and verify what comes back. Syntax can be automated. Judgment, specification, and deployment cannot: they move up the ladder as the machine climbs it. Every role below is a seat on that ladder, and the demand data on this page shows the market is already paying for exactly this: because it cannot answer Harari's question either, and it is hiring the people who can.

📚 Teaching Aid

::tip Open Full Slideshow View Full Presentation, The Roles This Book Trains ::

---

Here we define the roles of the new agentic AI era: the jobs that exist because companies now manufacture, run, and govern AI Workers. The entries are sorted by how the work actually clusters, and the verdict beside each one is the honest scope line: how far this book carries you toward it, and where the certification tracks take over. The verdicts matter more than the names. Where the book stops, it says so. And because a role is only as real as the demand behind it, this page tracks that demand across every market now hiring for these roles: the AI labs, the hyperscalers, the consulting giants, the independent services firms, and the open freelance market.

The map: three levels, one line. One sentence holds this whole page together. This book trains you to build AI Workers (Digital FTEs), and to combine those Workers into a company that runs on them (an AI-Native Company). The job market has a hot new name for the person who can do all of this: the Forward Deployed Engineer (FDE). So there are three levels, and each one builds the next: the person (you), the unit (the AI Worker you build), and the enterprise (the company those Workers add up to). Every role on this page is either a stop on that line, a role that supports the line, or a limit the book honestly draws around it. One more thing before the map: "FDE" describes where you work, not what you know. Work inside a client's company, and the market calls you an FDE. Get hired by that company, and the same skills make you their AI-Native Company Architect. The book trains the skills. The market picks the name.

That definition is correct, and it is also incomplete, because an address says nothing about what you carry through the door. A vendor's FDE carries the vendor's platform. What a vendor-neutral one carries is a harder question, and it turns out to have a precise answer: two Systems of Record, one given to her and one she builds herself. That section sits inside the FDE map below, because the answer only makes sense once you have seen what the vendor's version looks like.

Everyone starts on the same Foundations, the browser skills every reader needs before any agent work. On that floor sit the two modes of general agent use. Mode 1 is using a general agent to do your own work faster, a proficiency every reader needs, not a job title. Mode 2 is manufacturing AI Workers that do the work for you, and that is where the job titles live. The map opens with the Foundations floor and the Mode 1 Practitioner, then turns to the Mode 2 roles, which are almost all of it.

New to the vocabulary (Digital FTE, SKILL.md, Agent Factory)? Start with the Thesis and the glossary, because this page assumes them.

One discipline, applied in two settings: four roles carry the pipeline inside your own company; a Forward Deployed Engineer carries the same pipeline into a client.

The whole map at a glance: the core pipeline, what extends and supports it, where the book stops, and the baseline beneath it all.

The baseline everyone starts from

Foundations: the floor, before either mode. Every reader starts the same way, in a browser tab, on the Foundations: how to prompt, the two document languages of agentic work, commissioning code you never write, skills and connectors, and how to think in the AI era. No mode, no role, nothing to install. This is the floor the whole map stands on. Where everyone starts, not a title you hold.

Mode 1 Practitioner: not a title, a proficiency. On that floor, you use a general agent to do your own work faster: to reason, write, code, analyze, plan, ship an outcome, and close the session. This is Mode 1, and the book trains it for everyone, engineers through Claude Code or OpenCode, domain experts through Claude Cowork or OpenWork, under the Seven Principles of General Agent Problem Solving. It is the first mode every reader runs before the Mode 2 roles below, and it makes you sharper at the job you already hold rather than handing you a new one. The first mode everyone runs, not a title you hold.

The generalist core

These core roles run as a single pipeline, from intent to production: Outcome Architect (what) → Digital FTE Builder (build) → AI-Native Company Architect (system) → Cloud AI Engineer (run). Run it inside your own company and it is these four roles; run it inside a client's, carried end to end by one embedded, vendor-neutral engineer, and it is the Forward Deployed Engineer. Everything else on the map supports, extends, or bounds this line.

Four roles run the line inside your own company; one embedded engineer carries the same line inside a client's.

Outcome Architect: owns the intent, not the execution. Work in the agent era splits three ways: intent, execution, verification. The Worker owns execution; this role owns intent. It decides what a Worker should achieve, authors the spec that pins it down, sets what "correct" means, and prioritizes which Workers get built at all: the human who answers what and why before the Builder answers how. Where the Strategist track owns client-facing discovery and ROI, the Outcome Architect owns the internal Worker roadmap and the specs behind it. The book trains this directly: spec-driven development is, at its core, the discipline of writing intent a Worker can be held to.

For most of software's history, the slow part was building the thing. Coding agents broke that. A single engineer now ships several times more than before, because the agent does the building. But that speed exposed a new slow part. If one engineer can build five things at once, someone still has to decide which five things are worth building: and write down clearly enough what each one should do that an agent can execute it. That deciding is the work this role calls intent, and it did not get any faster.

Here is the shift in one number. Companies used to run roughly one product manager, one person setting direction, for every eight engineers. As each engineer's output multiplied, that same one person now effectively has to feed the work of twenty.9 The building scaled. The deciding did not. So the deciding became the bottleneck: the point everything else waits on.

The market sees this and concludes it is short on product managers. This book reads it differently: it is the moment the Outcome Architect, the role that owns intent, becomes the most important seat in the company. The bigger the AI workforce grows, the more it depends on a human who can say, precisely, what it should build.

Execution scaled with agentic coding; the work of deciding what to build did not. The widening gap, not a shortage of engineers, is what the new ratio measures.

Trains this in full: the discipline the whole method rests on.

Digital FTE Builder: the unit product, built end to end. The market calls this the AI Engineer: its catch-all for someone who builds applications out of AI components and drives AI coding agents. This book's name is sharper, because the thing you build is sharper: the Digital FTE, the unit the whole company is assembled from. This is the book's primary graduate. It trains the full spine: spec-driven development, SKILL.md authoring, agent architecture, tool and MCP interfaces (MCP is the standard way an agent plugs into outside tools and data), evaluation, and human oversight, with enough deployment to ship, and the depth left to the Cloud AI Engineer. Trains it, end to end.

AI-Native Company Architect: designs the company, not the single Worker. The whole enterprise: the Two-Layer Model, the management layer, the workforce, the nervous system that carries events between them, and the system of record it all runs against. The Agent Factory is the process this architect practices; the AI-Native Company is the product they ship. The book is its canonical source. The five-quarter Certified Agentic AI Architect program is its credential. Trained in full; certified by the Architect track.

Cloud AI Engineer: the one who runs the AI Worker and the AI-Native company in production. Building a Digital FTE is one half of the work; running it reliably is the other: and so is running the whole AI-Native company it belongs to. Where the AI-Native Company Architect designs the enterprise, this role operates it: deploying and scaling the Workers, the management layer, and the nervous system on real cloud infrastructure, Azure Container Apps to ship, Inngest for durable execution, Dapr and Kubernetes to scale. It is where the system stops being a prototype and becomes a company an organization can depend on. Trains the production path; deeper scale and platform operations belong to the cloud track.

The Forward Deployed Engineer (FDE): the vendor-neutral version the market can't find

The four core roles above run the line inside your own company. Carry that same line into a client's, one embedded engineer, end to end, and it has a name the market is now scrambling to hire for.

What an FDE actually does. Most software engineers build a product at headquarters and never meet the customer who uses it. An FDE does the opposite. They go to the customer's actual workplace, sit alongside the people doing the work, understand the real problems those people face, and build solutions right there, on-site, using their company's platform. Not a demo. Not a slide deck. Working software that runs in the customer's real environment.

Think of it like the difference between a doctor who reads your chart from another city and a doctor who sits in the room, examines you, and starts treatment on the spot. The FDE is the second doctor.

Palantir, a major data analytics company that builds software for governments and large enterprises, created this role in the early 2010s, originally calling them "Deltas".1 Until around 2016, Palantir actually had more FDEs than regular software engineers, because their customers (government agencies and large traditional enterprises) needed someone on-site who could cut through internal bureaucracy with a startup mentality. Palantir's way of explaining the difference is the clearest: a regular developer focuses on one capability, many customers (build one feature, ship it to everyone), while an FDE focuses on one customer, many capabilities (embed with one client, solve whatever they need). Their description of the job captures the scope: it looks like a startup CTO's. You own everything from start to finish on high-stakes projects. The lineage is now confirmed from the outside: launching its own 6,000-person FDE unit in 2026, Microsoft publicly credited Palantir with popularizing the title.11

FDE 101: why Palantir needed the role

Who is describing this, and why it counts. The clearest account of why this role exists comes from Kevin Bai, in a talk he titled Forward Deployed Engineering 101, delivered in mid-2026 at the AI Engineer World's Fair on the same nine-session FDE track that carried Brunet's talk later on this page.24 His career is the short history of the role told through one person. He led FDE engagements at Palantir, the company that invented the job, for what he describes as the most important institutions in the world. He then went and built the function somewhere it did not exist, joining Rippling as the first person on its FDE team and growing that team to about twenty-five engineers in a year. So he has done from the inside what this page keeps describing from the outside: started an FDE practice at zero, in a company with no such practice, and staffed it. He is now a member of technical staff on Anthropic's Applied AI team, which is the team behind the title this page notes Anthropic uses for the role, Applied AI Engineer. And his own account of his background reads like the Venn diagram below before the diagram is even drawn: diplomacy, sales, business development, product management, customer success, and software engineering, with forward deployed engineering as the one job that brings them together.

Two honest notes before the argument. He spoke about the discipline in general and explicitly declined to discuss his current work, so nothing here describes any frontier lab's internal practice. And what follows is a practitioner's framework with figures recalled on stage, not audited research. This page gives it the same standing it gives Aggarwal's arithmetic and Brunet's playbook: the testimony of someone who has actually run the thing, labeled as such.

The problem was never the software. Start with what Palantir actually sells. Foundry lets an organization of any size centralize its data and build an ontology: turning table one, table two, and table three into proper nouns, so that a company with warehouses has one table that is the truth about warehouses. On top of that, customers build applications.

Now show that to a leader of industry. Bai's version of the response: you have made my data organized, and what does that do for my business? That is where selling technology alone falls short. Worse, the vendor's success now depends on the customer's ability to use the software, so the customer pays twice: once for the platform, and again to train its own people to the point where they can build anything with it. Bai calls that a terrible way to do business, and his fix is the sentence the first role on this page is named after. Stop selling software, stop selling hours, and sell the outcome. Send people who will understand the nature of the customer's business, let them build the solution on the platform, and hand over the result. A consumer goods executive cares about shelf placement and sales throughput. How the data is organized is an implementation detail, and Bai says it should be.

Which buyers needed this, and why. Foundry is an app-building platform, which made it uninteresting to the companies that already have great engineers: Google, Meta, the labs, all of whom can build whatever the organization needs. The buyer who needed it was the Fortune 500 in oil and gas, where, as Bai puts it, the pipelines are not data pipelines. The offer to that buyer was engineers on loan: people the client does not have to hire, recruit, manage, or retain, trained on the platform, and sitting close enough to the work to find the real problem and then build for it.

The proof is in the contract size. Measure public SaaS companies serving the Fortune 500 by average contract value, meaning how much a single customer spends with that vendor, and Bai puts Palantir first at about $4 million, ServiceNow next at about $1.2 million, Workday at about $600,000, and no other public SaaS company above half a million.24 Read those figures beside the headcount he notes in the same breath, a few thousand people, and beside the market capitalization figure further down this page. Selling outcomes prices differently from selling seats, and average contract value is the number that says so. It is also this book's claim about Digital FTEs, arriving from the vendor's side of the table.

The test that comes before all of it: do you even need an FDE?

Bai's screen is a two by two: how technical is the thing you sell, and how technical is the person buying it. Three of the four cells need no forward deployment at all.

• Technical product, technical buyer. GitHub, Datadog. The software is complicated, but the buyer is a CTO or CIO and the user is a software engineer, and absorbing that complexity is part of their job. Serve them with documentation and developer relations.
• Configurable product, technical buyer. Nothing special is required here either. A technical buyer configures a simple product without anyone flying out to help. Self-serve, or a sales-led motion.
• Configurable product, non-technical buyer. Rippling, Jira, Slack. These can be complex, but they are configured rather than developed on. A traditional sales-led motion works.
• Technical product, non-technical buyer. The only cell where FDE is necessary, and Palantir's corner of the market.

His discipline about the diagram matters more than the diagram. The question is not do I want an FDE function, because it is easy to want what is in vogue. The question is whether you must take something technically complicated to a buyer who cannot implement it. If the answer is no, he says so plainly: forward deployment is probably not the right fit, and developer engagement or a sales-led motion will serve you better.

Bai's screen before anything else: three of four cells need no FDE, and the agentic turn is pushing vendors into the fourth. His framework, not a measurement.

Two matrices, two different questions. Bai's square is a vendor's build-or-not decision: should this company have an FDE function at all. Brunet's matrix later on this page is per-engagement: is this client an FDE client. A reader of this book uses both from a third position, because he sells no platform of his own. Bai's square tells him which clients to walk toward, the ones holding something technical they cannot implement, which after the shift described below is nearly all of them. Brunet's matrix tells him how to scope the engagement once he is in the room.

This is not the same as a Solutions Architect or a Sales Engineer. A Solutions Architect advises: they run demos, design solutions on whiteboards, and build proof-of-concept prototypes with sample data to convince a prospect to sign. Once the deal closes, their involvement typically winds down. An FDE picks up where the Solutions Architect leaves off. They write production code directly on the customer's infrastructure, with real data, and they stay until the customer gets real value. The simple test: if the role is accountable for making customer-specific work actually function in production, it is closer to an FDE. If it is accountable for proving or explaining the product, it is closer to a solutions architect.

A real example is OpenAI's work with John Deere, the nearly 190-year-old farming company, which shows the same deployment logic: AI applied inside a real operational context, around See & Spray, customer success, dealer workflows, and preseason recommendations. John Deere credits See & Spray with up to 70% less chemical use, and OpenAI's case study shows how AI is being used around setup, in-season recommendations, dealer support, and ROI reporting.2 The work lives on the customer's planting calendar, not a product roadmap, which is the FDE job in one line: real production software, built in the customer's world and shipped when the customer actually needs it.

The FDE is where code, product, and customer meet: the software engineer's build, the platform engineer's product instincts, and the solutions architect's read of the customer, in one person who builds in the customer's world, not at headquarters.

Bai compresses the same picture into a hiring test with two conditions: an FDE is nothing more than a customer-facing software engineer, meaning a person you would hire onto the engineering team on the engineering bar alone, and would also trust in front of a customer.24 Both halves have to be true. Drop the first and you have an account manager who cannot build. Drop the second and you have an engineer who must be kept away from the people whose problem they are solving.

Why every AI company now wants FDEs. FDE job postings grew by more than 800% in the first three quarters of 2025.3 Salesforce built a dedicated FDE team to support its Agentforce platform.4 OpenAI created the "Deployment Company," a majority-owned subsidiary backed by about $4 billion from an investor consortium, built largely around staffing enterprises with FDEs.5

In mid-2026 the model reached the hyperscalers: AWS committed $1 billion to a new Forward Deployed Engineering unit, sending pods of five-to-six engineers to clients for roughly 45-day deployments, with plans to staff it in the thousands, the first major cloud provider to make the bet, and funded entirely from its own balance sheet rather than a private-equity joint venture like OpenAI's or Anthropic's.10 Two days later Microsoft answered with the largest commitment yet: Microsoft Frontier Co., a new operating unit backed by $2.5 billion and staffed with 6,000 people, existing Microsoft FDEs, technical consultants, support staff, and salespeople with industry experience, embedded directly with clients, with early customers including Unilever and Novo Nordisk.11 In one week, the two largest cloud providers put a combined $3.5 billion behind the same job title. And the model has now jumped sectors entirely: McKinsey's QuantumBlack is hiring Lead Forward-Deployed Engineers outright, demanding eight-plus years of hands-on engineering, a consulting giant conceding that advice without deployment no longer sells.12

One detail in Microsoft's own announcement is worth keeping. It does not promise a platform installed or models integrated. It promises a team that co-designs, deploys, and keeps improving AI systems, judged by measurable business outcomes.11 That is the client's own success test, written into the vendor's charter, and it is the same test a vendor's FDE lead states from the delivery side later on this page.

The reason behind all of this is simple: a 2025 MIT Media Lab study (Project NANDA) found that about 95% of custom enterprise AI pilots show no measurable return.6 Not because the AI does not work, but because fitting it into a company's messy, real-world systems is incredibly hard. FDEs exist to close that gap. They are the reason Palantir passed a $136 billion market cap by late 2024, overtaking Lockheed Martin,7 and now every AI company wants to replicate the model.

The same study also says what the survivors did. The 95% figure explains the failure. A second finding in the same report explains the exception: initiatives run with outside partners reached deployment about 67% of the time, while tools built entirely in-house reached it about 33%.6 Read the two numbers carefully, because they measure different things. The 95% is about profit-and-loss impact. The 67% is about reaching deployment at all. Together they say the pilots do not die of weak models. They die of integration work that nobody is embedded to do, and the companies that brought outside people in to do that work shipped twice as often.

Two limits on that number. The report says that the link between outside partners and success does not prove cause, calls its own findings preliminary, and watched each deployment for only six months.6 And look at exactly what it compared: buying from a vendor, against building alone. Vendor-neutral is a third column the study never sampled, because in 2025 it barely existed. So the finding carries a reader to the front door of this section and no further. Outside expertise beats going it alone. Whether that expertise has to arrive welded to one vendor's platform is the question this section takes up below.

Why now, and not in 2012. The failure rate explains why the role pays. It does not explain the timing. Palantir's model was public, profitable, and visible for a decade, and almost nobody copied it. Bai's hypothesis is structural, and it is the best answer on offer: what changed is not that the industry finally noticed Palantir had been right. What changed is the software business itself. Nearly every platform is now agentic. Agentic means customizable. And customizable means the customer no longer knows what the product does or how far it can be pushed, which puts nearly every vendor in the one cell of his square that requires forward deployment: something technical, sold to a buyer who cannot implement it.24 Leave the success of your product to the customer's ability to implement it, he warns, and you will not sell upmarket and you will not expand into a new industry either.

Read the two findings together and they fit like a hand in a glove. Bai names the cause: agentic platforms turned every vendor into Palantir. MIT measured the effect: pilots that go nowhere, because nobody was embedded to close the implementation gap. And the money on this page, the $4 billion, the $1 billion, the $2.5 billion, is the industry paying to close it.

What the market pays: read honestly. Viral posts about this role lead with "up to $1M a year." The real numbers are strong enough without the inflation. Indeed counted 643 US FDE postings in April 2025 and 5,330 a year later, a 729% rise, with typical salary bands of $170,000 to $200,000-plus; Anthropic's own FDE postings run $200,000 to $300,000.12 Across the market, the median sits near $190,000, ranging roughly $160,000 to $220,000.13 Senior and staff FDEs at frontier labs clear $450,000 to $600,000, and the seven-figure numbers do exist, at the very top of one lab's engineering ladder, but that is the ceiling of a career, not the door into one.14 Two details in the data matter more than any single figure. First, postings for the role grew more than 800% in nine months while the candidate pool grew roughly 50%: a supply gap, which is where salary pressure comes from and where a trained reader enters.3 Second, in one review of verified FDE roles, not a single one carried a sales quota:14 the market pays FDEs as engineers, not salespeople, which is the whole distinction from the sales engineer drawn above, priced in. Market data in this section was last verified in July 2026; the role is moving quickly, and the durable point is the discipline, not any single salary band or hiring count.

The services industry sees the same math: from the other side

The vendors above send FDEs out; the outsourcing world has a more existential reason to care, because its whole model, thousands of people selling hours of human execution, is precisely the layer AI absorbs. So within a week of the AWS and Microsoft announcements, that world began repositioning itself around the FDE. Sanjeev Aggarwal, who founded Daksh, one of the pioneers of India's BPO industry, before co-founding the venture firm Fundamentum with Infosys's Nandan Nilekani, put the arithmetic plainly on CNBC-TV18's Young Turks Reloaded: the FDE fuses engineer, product manager, and AI architect in one person ("almost like a unicorn... a 10x engineer"), and on that fusion a firm can build a $100 million business with roughly 100 FDEs, work that the traditional IT services model staffed with 2,000 to 2,500 people, at gross margins he puts at 70 to 90 percent.15 Treat the figures as a veteran's projection, not a measurement; but notice whose projection it is. This is the man who built the old model, declaring its successor: twenty-five heads of the pyramid replaced by one, which is the pod-of-one compression run at company scale. His conclusion is geographic: "India can be the FDE factory for the world," its decades of IT delivery converting into the new discipline. The claim generalizes further than he takes it. The IT-services decades taught South Asia how to embed inside a client's messy systems and ship; that muscle lives in Karachi and Lahore as much as Bangalore. What converts it into the new role is not geography but training: and the method in this book is that conversion, available to anyone who does the work.

Aggarwal's arithmetic drawn to scale: the pod-of-one compression, run at company scale. His projection, not a measurement.

And the professional services firms are repricing their own product. Aggarwal projects. The Big Four have shipped. In March 2026, PwC's US CEO Paul Griggs told the Financial Times that the firm would begin offering alternatives to billing clients by the hours its staff work, and would convert parts of its tax and consulting practice into AI-powered tools clients could use directly, without a PwC professional involved in the first steps, potentially sold as an annual subscription.25 That platform shipped as PwC One, opening with six automated services covering ground from M&A due diligence to tax rules. Griggs was blunt about what it means internally: senior people who are not thinking about how to be AI-first will be replaced by people who are, and anyone who believes they can opt out will not be at the firm long.

Read it as three things at once, because it is three things at once.

It is Aggarwal's arithmetic, confirmed from the other end of the industry. He projected the pyramid compressing twenty-five to one. PwC is removing the human from the first steps of certain services entirely, which is the same compression stated as a product decision rather than a staffing ratio. Two very different firms, one from Indian IT services and one from the Big Four, arrived at the same place in the same quarter.

It is the outcome-pricing claim, made by a firm whose economics depended on the opposite. Bai's average contract value figures earlier on this page argue that selling outcomes prices differently from selling seats. A Big Four firm moving off the billable hour is that argument being acted on by the largest possible incumbent, against its own revenue model. The billable hour was not a pricing preference. It was the whole business.

And it is a new cage. PwC One is a platform. A PwC professional deployed into a client builds on it, and what the client keeps afterward runs there. The structure is identical to the vendor lock-in described in the next section, with a consultancy in the vendor's seat. So the vendor-neutrality argument does not stop at the AI labs and the hyperscalers. It now reaches the professional services firms too, and a reader competing for embedded professional work should expect to meet this version of it.

One more line of Griggs's belongs on this page for a different reason. Layer AI on top of an inefficient process, he warns, and you get a more complicated process and a fast report on how bad the process always was. That is the MIT failure rate explained by a buyer, and it is the FDE's job description written from the client's side of the table: the reason the role exists is that somebody has to rebuild the process, not decorate it.

Treat all of this as one firm's strategy rather than an industry measurement, in the same class as Aggarwal's projection and Bai's recalled figures. What is not a projection is the platform: it shipped.

The playbook, from inside a vendor. The demand numbers above come from press releases and posting counts. In June 2026 the view arrived from inside: Pauline Brunet, who runs the global FDE team at Cursor after ten years of enterprise AI deployment, laid out her playbook at the AI Engineer World's Fair, which this year ran a dedicated FDE track for the first time.23 She opened with the same read this page opens with: she is waiting for the article that names the FDE the hottest job of 2026. Four of her rules matter to a reader of this book, because they describe the job from the side that pays for it.

First, the fit test. Brunet scores every engagement on two axes: how digitally mature the customer is, and how customizable the product is. A mature customer with a simple product needs documentation, not an FDE. An immature customer with a simple product needs a traditional rollout, not an FDE. The FDE lives in the band between: embedded transformation where the customer cannot staff the work themselves, and acceleration where the customer is capable but the build is deep. The lesson for a vendor-neutral reader is direct: this matrix is how the buyer already thinks. Walk into a discovery call knowing which cell you are standing in.

How the buyer's side scopes the role: the FDE lives where customization is deep, at its core where the client cannot staff the work. Redrawn from Brunet's talk; her framework, not a measurement.

Second, the staff-augmentation line. Her red flag is the client who says "we're understaffed": that is a request to rent hours, not to transfer capability, and she declines it. Her counter-move is one question: who will be the working team? If the client cannot name the people who will build alongside you, the engagement is body-shopping in disguise. Carry that question. It is the field test for the distinction this page draws between the FDE and the services pyramid.

Third, directional scope. She refuses open-ended engagements ("take two FDEs for six months") and refuses fixed waterfall promises equally. Her format: name the problem, name the KPI baseline ("this process takes three hours; success is twenty minutes"), commit to a phased six-week directional plan, and expect to pivot on what the client's real systems teach you. Her stated reason is one this book's readers will recognize: she has not yet seen the customer's data, processes, or systems, so precision before contact is a lie. That is spec-driven development, spoken from the delivery side: the spec hardens as the ground truth arrives.

Read that rule carefully, because it is easily misheard as an argument against arriving with anything prepared. It is not. What cannot be precise before contact is the plan for this client: their systems, their data, their baseline number. What can and must exist beforehand is the profession's own governed knowledge, which does not vary by client. Brunet's own team walks in with Cursor's platform already built. The vendor-neutral version walks in with the profession already governed. Neither arrives empty, and neither pretends to know the client's numbers.

Fourth, ROI in three questions. Every engagement must end on at least one: did we increase revenue, decrease costs, or mitigate risk? Her example: a client alarmed that an agent cost $2,000 a day, until she asked what the agent was doing, dispatching the right technician to failing equipment, and the client conceded the agent was cheap. The client had measured cost and never measured return. The Strategist track teaches this framing; Brunet confirms it is the only framing the buyer's side runs.

Two more of her disclosures deserve a plain reading. She hires only engineers with five or more years of experience and does not yet hire early-career candidates: so the salaried vendor door is, today, a senior door. This book does not pretend otherwise. What it offers instead are the doors that do not check tenure: the portfolio, the freelance market, and the pod of one, where the credential is a deployed Worker and a governed slice of a profession, not a résumé line. And she named an offering she never planned and is now building, because clients keep demanding it: help reorganizing the company itself, who to hire, what the job descriptions say, how the ways of working change once the agents arrive. Read that carefully. A vendor's FDE team is being asked, from the client's side of the table, to answer Harari's question. That service is this page, and the Strategist track behind it.

One last detail she states without flinching: her team deploys Cursor's cloud agents and builds applications on the Cursor SDK, inside the client's codebase. Keep that in mind as you read the next paragraph.

The vendor lock-in problem. Here is the catch. Every FDE at Palantir builds on Palantir's platform. Every FDE at OpenAI builds on OpenAI's models. Every FDE at Salesforce builds on Salesforce's tools. Every FDE at Cursor deploys Cursor's agents and builds on the Cursor SDK. The engineer goes deep into the client's company, wires that one vendor's product into everything, and leaves. Switching later is painful and expensive, like a plumber who only installs one brand of pipes: the plumbing works, but you can never hire a different plumber without ripping out the walls. As Andrew Ng has noted in The Batch,8 clients struggle to find FDEs who are not tied to a single vendor, because the whole point of the role, for the vendor, is to lock the client in. AWS's own launch makes the trap easy to see. It promised that clients would walk away self-sufficient, able to keep building on their own: and in the same breath specified that the agentic systems they keep run inside their own AWS environment. Self-sufficiency, on one vendor's cloud. That is lock-in restated as a feature: you are free to keep building, as long as you keep building here. Microsoft's launch made the same concession in a different way. Pressed on the comparison to Palantir, the executive running Frontier argued that Microsoft supports more models, more connectors to data, and more integrations with open systems of record than its rival.11 Notice what that defense is: a vendor measuring its own lock-in against another vendor's and calling the looser cage the feature. The objection this book raises was just conceded from the vendor's own stage.

This book trains the FDE the market keeps asking for but cannot find. The method here is bound to no vendor. A graduate of this book carries the full pipeline (spec the intent, build the Worker, design the system, run it in production) inside a client's organization without locking them into any single platform. When a better model appears next quarter, or a cheaper runtime ships next year, you switch. The client keeps the freedom to choose, and you keep the discipline that works on any stack. One honest tradeoff to name: a vendor's FDE is heavily subsidized, sometimes free, because the vendor earns it back in lock-in, while a vendor-neutral FDE is paid for by the client or an independent firm. That is the feature, not the bug: the client is buying optionality now instead of paying switching costs later. The blueprint this engineer operates inside is the FDE AF Model: five layers from framework to customer, including where the FDE earns at each one.

Few programs train the vendor-neutral version of this role end to end, and to be exact about the boast: what the book trains is the technical core of the vendor-neutral FDE, the half the market can't find. The other half (client discovery, prioritization, ROI framing, and the discipline to push back on an unrealistic ask) belongs to the Certified Agentic AI Business Strategist track. Trains the technical core; the consulting layer lives in the Strategist track.

The hardest objection: without a platform, you are a dev shop

The section above argued that the platform is a cage. Now take the strongest version of the reply, and notice who makes it: the same practitioner who explained why the role exists in the first place.

Bai anticipates the audience member who says an FDE function cannot survive in the enterprise, because building something custom for every customer leaves you herding dozens of repositories nobody can maintain, and engineers who quit rather than learn them. He agrees, with one condition. If every FDE builds entirely from scratch, then in his words you do not have an FDE function, you have a dev shop: a profitable business, possibly, and not the same business. What makes it an FDE function is that the engineers never write software from scratch. A set of shared primitives already exists, and the engineer assembles those primitives into something arbitrarily valuable to the customer. Without that, he says, the maintenance cost will eat your profit and loss statement, assuming your engineers have not all resigned first.24 On how granular the primitives should be he refuses a universal answer: in some industries the application is sixty percent built and the customer customizes the rest, in others the domain demands granular tooling, and the useful comparison is AWS, which hands you DynamoDB so nobody has to invent a database, precisely because it serves an extremely broad set of customers.

Take this seriously, because it is the bill for vendor-neutrality. Strip out the vendor and you have removed the shared primitives along with the cage. Do nothing about that and the pod of one is a dev shop of one: bespoke code at every client, nothing reused, and a maintenance load that grows with each engagement until it eats the margin. Bai's own test is the honest one to turn on yourself. Do I have a platform, or am I willing to invest in building one?

The answer is the next section, and it is why the next section exists. The vendor-neutral FDE does carry shared primitives. They are simply not code owned by a vendor.

What fills the pod: two Systems of Record

Everything above says where an FDE works. Nothing yet says what she brings through the door, and that is the question vendor-neutrality forces.

Ask it of the vendor's version first. A Palantir engineer arrives with Palantir's ontology and tooling already built by someone else. That is real leverage, and it is why one engineer can now do in weeks what a team once did in years. It is also the cage the section above describes: the client stays free to keep building, as long as they keep building there.

Now strip the vendor away. What is left? If the honest answer is "the method, in her head," then she is selling hours of human execution, which is the services pyramid she was supposed to replace, and the client who says "we're understaffed" is asking for exactly that. The pod of one cannot survive on hours. It survives on assets that travel from one client to the next.

Two of them do, and both are Systems of Record. What You Carry In makes this argument in full, and this section is its career-facing half.

The first is the method, and she did not build it. This book, deep and already governed, served as a website for human readers and over MCP for agents. It holds how to specify an outcome, manufacture a Worker, run the loop, trust the checker, and prove the result in production. Every graduate carries the same one, and it is identical at a Karachi accounting firm and a Chicago one, because the method does not change with the domain.

The second is the profession, and she built it herself. One vertical, one jurisdiction, governed by her and licensed from a committed domain expert: the law, the standards, the expert's derived procedures, the invariants, the decision map. It starts at one professional outcome, covered completely, and thickens engagement by engagement. Nobody else has this one.

Both speak MCP, so her agent reads both at once: one source tells it how to build a Worker, the other tells it what the profession requires. No integration work, because the ecosystem's kernel was designed for exactly this pairing.

And this answers the dev shop objection. Bai's condition was shared primitives, so that the engineer never starts from scratch. Test both Systems of Record against that condition and both pass. The method is the primitive layer for how work gets built: specify the outcome, manufacture the Worker, run the loop, trust the checker, prove the result in production. It is identical at every client, which is exactly the property he demands and exactly the property a dev shop lacks. The profession is the primitive layer for what the work must obey, in one vertical and one jurisdiction. Neither is code that gets forked per customer, and that is what bends the maintenance curve he warns about: what you maintain is a governed corpus, and the code around it is regenerated rather than nursed. Two things follow, and both should be said plainly. First, his condition is met without a vendor, which is this whole page reduced to one line. Second, the cost did not vanish, it moved. You now maintain a corpus instead of repositories, and somebody has to fund that before the first client pays, which is the order the page states below: build first, sell second. Read the second half as this book's reasoning, in the same class as Aggarwal's arithmetic. Bai's warning comes from a decade of watching maintenance costs land on real teams. That a governed corpus flattens the curve is a claim, not yet a measurement.

How the second one thickens. Bai also states the rule for what a vendor keeps: anything bespoke and unique to one customer should exist only for that customer, and anything generalizable should be generalized over time, which makes forward deployment a scouting function, the way a vendor learns what to build into the product next.24 The vendor-neutral version runs the same rule to a different destination. What generalizes does not go into a vendor's platform. It goes into the vertical System of Record: the standard that turned out to govern three clients rather than one, the procedure the expert wrote once and now signs off everywhere, the invariant that held at every firm in the jurisdiction. That is what thickens engagement by engagement means mechanically, and it is why the second client costs less to serve than the first.

And here is why vendor-neutrality forces the choice. A vendor's FDE specializes by platform. Take the platform away and specialization has to land somewhere, or you are a generalist consultant with nothing to reuse. Ask what actually travels from client two to client three. The shape of the work travels for free, because reading a document against a rule, citing the rule, and escalating what is unclear is method, and it is already in the first System of Record. Nobody pays a premium for it. What a buyer pays for is the part that does not generalize: which standard governs this question, which version was effective in this period, which country's regulator owns this rule, what the partner must sign personally. All of that is professional and jurisdictional. None of it survives a move from audit files to customs declarations.

So the axis is the profession, and vendor-neutrality is what puts it there. Choosing Your Vertical is the method for picking which one, and Designing the Vertical System of Record is the method for building it.

The two answers side by side. A vendor's engineer arrives with a platform that stays behind; a vendor-neutral one arrives with the method she was given and the profession she built.

One order follows, and it decides how a career starts. Build first, sell second. The slice is not a step that waits for a customer. It is the step that produces one. This page has already said why, three times over without naming it: the portfolio is the credential, the résumé is screened on shipped systems, and a buyer who has been shown nothing will not tell you his own baseline number. Walk into a mid-size firm carrying one governed page of that firm's own profession, and the next question comes from his side of the table.

The client's fairest question closes it. A vendor's engineer can answer easily: I bring our platform, and the leverage stays with us. Yours answers differently: I bring the method and a profession already governed, and what you keep when I leave is a working system you can change, on a stack you chose, with the option to hire me outright. Note what that answer does not claim. The client does not walk away owning the vertical System of Record. It is held by the domain startup she and her expert built, it contains her expert's material under licence, and it contains third-party sources under theirs. So a licence to serve a standard inside her system does not become the client's licence because she offered it. What the client keeps is the freedom the vendor's version cannot offer.

One honest label, in the spirit of the salary section above. The demand data is measured. The pod of one follows from the method. But no verified count yet exists of vendor-neutral graduates who converted a governed corpus into a first client, because the category is new and the shelf below is still empty. Read the order as this book's reasoning, in the same class as Aggarwal's arithmetic: sound, and not yet a measurement.

A pod of one

Look at what AWS sends a client: a pod of five or six engineers, on-site for about forty-five days. That is what forward deployment looks like when people still do the building by hand: it takes a small team. This book changes who is in the pod. A graduate carries the same work into the client alone. The people who used to sit beside them are now Digital FTEs: the Workers the engineer builds and runs. So the team of five or six shrinks to one human commanding a workforce of Workers. The job is the same; what fills the pod is not. The power no longer comes from adding people. It comes from the method, and the Workers it produces. Read this beside the section above and the pod has two halves: the Workers replace the people, and the two Systems of Record replace the vendor's platform. This is the same shift the new product-to-engineer ratio shows from the other side: each person's output keeps rising while the number of people falls. The full arc, legacy pod → compressed pod → pod of one, is traced in How the team got this small.

One risk this creates, named by someone who staffed it the old way. Asked whether several FDEs should work one project, Bai's answer is that it is a good pattern, and his reason is the one that matters here: you do not want a single point of failure, one person holding all the information, going on vacation, and the engagement stalling behind them.24 A pod of one is that risk in its purest form, and pretending otherwise would be dishonest. The book's answer is not that the risk disappears but that it moves out of the human's head. What a second engineer provides is redundancy of knowledge, and in this method the knowledge is already written down: the spec, the evals, the governed corpus, the deployed Worker and its runbook. Redundancy through artifacts rather than headcount is the claim, and it comes with a test you can run on yourself. If you were unreachable for two weeks, could another graduate of this book pick up your engagement from your repository alone? If not, you do not have a pod of one. You have a bus factor of one.

The third door: the freelance FDE

So far the FDE has had two addresses: the vendor's payroll and the independent firm's. A third has now opened: the open freelance market. Upwork runs a dedicated category for hiring Forward Deployed Engineers, with published project bands: roughly $2,000–5,000 for a first integration, $5,000–15,000 for a custom implementation, $15,000 and up for enterprise deployments, $4,000–10,000 a month for ongoing support, and $150–250 an hour for strategic consulting.17 In the UK, contract FDEs bill £600–750 a day at mid-level, £750–1,200 senior, and £1,200–2,000 a day at principal level: and a specialist FDE recruiter reports senior FDEs actively choosing contract work over permanent roles.18 Fractional platforms have followed: dedicated matching for FDEs, and "Fractional Forward-Deployed Engineering Lead" postings that fill within days.19

Now the honest reading, because the marketplace page rewards a close look. The category exists; the supply under it does not. Browse the profiles Upwork lists as Forward Deployed Engineers and you find capable generalists, full-stack developers, DevOps engineers, app builders, none of whom describe FDE work, embedded delivery, or an end-to-end pipeline. The marketplace built the shelf before anyone stocked it. That is this page's opening line playing out at the marketplace layer: the title arrived before the training did. For most job titles, an empty shelf is a warning. For a trained reader, it is the opening: the demand side is posting projects and paying published rates into a category the supply side has not yet learned to fill.

Three things make this door different from the other two. First, it is the vendor-neutral FDE's native market. A vendor's FDE cannot freelance at all: their role exists only inside the vendor's payroll, welded to the vendor's platform. Every genuine freelance FDE is, by construction, the vendor-neutral kind this book trains; on the open market, vendor-neutrality stops being a differentiator and becomes the entry requirement. Second, the retainer tier is not maintenance work in disguise. It is the Digital FTE subscription model this book teaches, run from the outside, and the monthly fee pays you to operate the Workers you manufactured, which is the pod of one converted into recurring revenue. Third, and most important for this book's readers: this door has no border. The salaried FDE market largely requires a US or European work address; the freelance and fractional market requires a portfolio and a connection. What Aggarwal claims for India's IT decades runs through this channel for anyone: the same contract clears from Karachi, Lagos, or Bangalore.

Two constraints, named plainly. Embedding is the essence of the job, and remote embedding is harder than remote coding: the freelance FDE wins by over-communicating, holding client-timezone hours, and treating occasional on-site presence as part of the price of the premium. And the premium itself is earned, not listed: unproven marketplace profiles start near generalist rates, and what moves an engineer up the bands is demonstrated outcomes, which is exactly what this book's capstones produce. A deployed Worker, a shipped plugin, a live connector app, one governed slice of a profession: on this market, those are the credential. The book trains the delivery; client discovery and pricing discipline live in the Strategist track; the reputation is yours to build, one contract at a time.

Hire the FDE directly and the title disappears. "FDE" was never a description of the engineer or their skills. It describes where they work: embedded inside a client's company, as an outsider, carrying the whole line end to end. So the deciding question is simple: whose company are they building in? Build inside your own company, and the work is the four core roles. Build inside a client's, and the same work is called the FDE. Now hire that engineer directly. The client's company becomes their own company. They are no longer forward deployed: just deployed. Nothing about the work changed; only the address did. So the FDE title falls away, and they become the internal core again: one person owning the whole pipeline inside the company that hired them. The single name for that is the AI-Native Company Architect who designs the enterprise, usually running it as the Cloud AI Engineer too.

This is the freedom only a vendor-neutral FDE has: they can join the company outright. A client can hire your graduate as a full employee, and the engineer keeps doing the exact same work the next morning: because the discipline lives in the person, not in any vendor's platform. It walks in the door with them. A vendor's FDE cannot do this. The day they leave Palantir or OpenAI, the platform the whole job was built on stays behind: the engineer who walks out is still talented, but the leverage stayed with the vendor. So the vendor's FDE is on permanent loan: useful while embedded, gone the moment the vendor relationship ends. Our graduate is hirable for keeps. The client can rent them as an FDE, then bring them in-house as their AI-Native Company Architect, and never lose a step. That is what vendor-neutrality buys: an engineer the company can actually own, not just borrow.

One asymmetry survives the trip, and it is worth naming. The first of the two, the Agent Factory System of Record, walks in with her and is available wherever she goes, because it belongs to the ecosystem and it is open. The second does not simply travel. Her domain startup holds it, and it stands on her expert's licence and on third-party terms, so a direct hire is a conversation about that business rather than an automatic transfer. The discipline is always portable. The asset has an owner.

The direct-hire path: deploy the engineer at a client and they are an FDE; hire them directly and they fold back into the core as the AI-Native Company Architect. Only a vendor-neutral FDE can make this trip.

Landing the job is its own discipline. The FDE résumé is screened on different signals than a software engineer's, and the FDE interview is famous for a round most strong engineers fail. Both are covered in Appendix A and Appendix B at the bottom of this page, along with Appendix C: the map from this book's courses to each interview round.

The Subject Matter Expert as Skill Author

Subject Matter Expert as Skill Author: the role the market hasn't named yet. The accountant, lawyer, or supply-chain expert who encodes judgment into SKILL.md (a plain-text file that packages a skill an agent can load and follow) and becomes the knowledge engine of a Digital FTE. The work is concrete: take the tacit rule you apply without thinking, how a seasoned auditor decides which transactions to flag, how a claims adjuster reads a borderline case, and write it down precisely enough that an agent can execute it, then test whether the agent's calls match yours and revise the SKILL.md until they do. Most market lists miss this role because they still picture AI work as engineering-only. This book treats domain judgment itself as something to be authored, tested, and deployed, and it trains the expert to do all three. Like the vendor-neutral Forward Deployed Engineer, it is a role almost no one else trains. Trains it in full: judgment in, working agent out.

Notice that these two unnamed roles are not merely similar. They need each other. The vendor-neutral FDE's second System of Record cannot exist without an author, because the procedures inside it are written in a practitioner's voice and derived from a practitioner's real files. And the Skill Author needs someone to build the governed home her judgment lives in. Neither is a junior partner. The expert brings twenty years and the licence. The engineer brings the method and the build. That pairing is the unit the FDE AF Model calls a vertical, and it is why Choosing Your Vertical refuses to launch one without a committed expert.

The market just printed a price on this role. In mid-2026, Business Insider profiled Yousuf Imran, a Google account executive whose sales commissions stacked a $170,000 base into roughly $986,000 a year. In April he quit to found Mangosteen Studio, an AI product lab building sales tools for salespeople.22 Read past the headline number and notice what he is not: a software engineer. His stated asset was twenty years of learning the problems salespeople face, and his bet is that this judgment, encoded into AI products he owns, is worth more than a near-million-dollar salary renting it out. He framed the decision in ownership terms: if equity is where the upside of this era lives, the equity should sit in a company he builds himself. That is the Skill Author's wager, made at the most visible price the market has yet published: and, like Aggarwal's arithmetic above, it is one person's bet, a signal rather than a statistic. The headline says a man walked away from $986,000; the mechanism says domain expertise became a manufacturing input, and the expert kept the factory.

The Connector and Plugin Engineer

Connector and Plugin Engineer: extends the agent hosts other people already run in. Before you build a Worker that owns its own loop, there is a whole discipline in building the things an agent reaches for, and the market is naming it five ways at once: MCP engineer, integrations engineer, connector developer, plugin developer, agent-tooling engineer. It is one job at two addresses. A connector-native app extends the chat app (claude.ai) for end users: you ship a remote MCP server, tools, stored state, a real sign-in, a fail-closed session gate, that a stranger adds with one pasted URL, and from then on the model itself is your customer. A plugin extends the coding agent (Claude Code, OpenCode) for builders: skills, subagents, hooks, and MCP servers behind one install, where a deterministic hook is the line between advice the model may skip and a rule that runs every time. Same move, two hosts: and under both sits the same artifact, an MCP server, which is why the book teaches them back to back. The through-line is one idea from the thesis: you ship a unit a host loads, and you own the extension while the host owns the loop. Trains both end to end, each to a deployed artifact; issuing identity, meaning your own sign-in server and identity for agents, is the AI Identity course, and building the runtime itself stays out of scope (see where the book stops).

The supporting roles

Every pipeline needs people who check the work, set the rules, and take responsibility. These three roles do that.

Evals Engineer: the person who crash-tests AI Workers before they go live. You would not ship a car without crash-testing it. You would not release a medicine without clinical trials. An AI Worker that makes decisions affecting real people and real money needs the same discipline. The Evals Engineer designs those tests: does the Worker give the right answer? Does it fail gracefully when it gets something it has never seen? Does it stay inside the lines it was given? This is not an afterthought bolted on at the end. It is built into every chapter. Core curriculum, not an add-on.

AI Governance Officer: decides what the AI is allowed to do. Every employee in a company has limits. A junior accountant can approve expenses up to $500 but needs a manager's signature above that. A bank teller can process a deposit but cannot approve a loan. AI Workers need the same structure. The Governance Officer writes those rules at the company level: what the AI can decide on its own, what must go to a human for approval, and what the AI must never touch at all. They also handle the mapping to whatever regulations the company must follow, fair lending rules at a bank, patient privacy at a hospital, data residency laws in Europe. The AI-Native Company Architect builds the system that enforces these rules; the Governance Officer decides what the rules should say. The book trains this framework discipline directly; the specific regulations of your industry are the inputs you bring. Trains the governance framework; your jurisdiction's rules are yours to supply.

Digital FTE Supervisor: the human whose name is on the line. When an AI Worker processes a claim, drafts a contract, or flags a transaction, someone has to be accountable. That is the Supervisor. They are the human-in-the-loop: the reviewer who checks the work, the manager who approves the output, the name the audit trail points to when something goes wrong. This is not the person who built the Worker. This is the person who runs it day to day, the way a shift manager runs a team. Trains it.

Where the book deliberately stops

LLMOps Engineer: up to the model, not the model itself. Running agents in production is the Cloud AI Engineer's job, and the book trains it. The book also trains fine-tuning hands-on: but as a last resort, not a default. A fine-tune binds your system to one model snapshot and costs the optionality the whole method protects, so you reach for it only when prompting, context, tools, and retrieval genuinely fall short. The hard stop is building the model itself: pre-training a foundation model from scratch stays out of scope, because that capability is commoditizing. Trains fine-tuning and the ops around the model, not the building of foundation models.

Harness Engineer: the runtime you use, not the one you build. The harness is the agent runtime, OpenAI Agents SDK, Claude's managed agents, and the like, that runs the agent loop, manages state, and executes tool calls. The book trains you to use these fluently and to stay portable across them, since your discipline outlives whichever runtime wins. Building the runtime itself is not the job. Trains the operator who uses any runtime, not the engineer who builds one.

AI Data Engineer: the agent-facing data layer. The system-of-record work touches the agent-facing data layer: Postgres, pgvector, and MCP as the spine an agent reads from. Classic pipeline and warehouse engineering is adjacent, not central. Trains the agent-facing data layer, not general data engineering.

---

The second axis: your type, not just your seat

The map above tells you where the work sits. It does not tell you which seat fits you. In June 2026, Boris Cherny, creator of Claude Code and the tool most responsible for the execution explosion this page keeps measuring, looked at his own team and asked what roles become when engineering, product, design, and data science "melt into a new kind of role."16 His answer was five archetypes, none of them a job function. The Prototyper churns out brand-new ideas, most of which never ship. The Builder turns a prototype into production-grade product or infrastructure, fast. The Sweeper simplifies the system, cleans the UI, unships, optimizes. The Grower iterates a built product toward product-market fit. The Maintainer owns a mature system and keeps it secure, reliable, fast, and efficient as it scales.

Cherny's five archetypes, and where they rhyme with this map's seats: loudly, but not one-to-one.

Two of his observations do the work here. First, the archetypes are not tied to titles: across Anthropic, some designers are Prototypers, some Builders, some Sweepers, and the same spread runs through engineers, PMs, and data scientists, this page's opening claim, that the title no longer describes the work, confirmed from inside the lab. Second, most people span two archetypes, sometimes three, and the mix a team needs shifts with the product's phase: a pre-PMF product leans on the first three, a mature one on the last three. Read against this map, the rhymes are loud without being one-to-one. The Outcome Architect is a Prototyper's seat. The Digital FTE Builder is a Builder's. The Evals Engineer is a Sweeper's. The Cloud AI Engineer and the Supervisor are a Maintainer's. And the spanning is the pod of one seen from the inside: the Workers absorb the tasks, while the human's two or three archetypes decide which seats they can genuinely hold, and which supporting disciplines they must borrow rather than fake, evals for the Sweeper's subtraction, governance for the Maintainer's caution. Cherny ends on a question, not a claim: maybe the product roles of the future look like his five, and less like the domain roles of today. This page is one answer to that question. The roles tell you where the work sits. Your archetypes tell you which of those seats to take.

---

The pattern is the tell. The agent era fans work out into many roles, not one: building Workers, running and governing them, teaching them judgment. The map is the point: find where you already stand, which archetypes you span, and how far this book carries you from there.

---

Appendix A: The FDE résumé, six signals

Interview and screening practices shift quickly; this appendix and the next were verified against sources from mid-2026.

Recruiters do not read an FDE profile the way they read a software engineer's. Analysis of real screening practice converges on six signals, and a profile that buries them gets rejected before the technical bar is ever tested.20 The first three ask whether you have actually delivered: shipped production systems (real deployments, not features on a team's backlog), quantifiable impact (not "built feature X" but what the customer gained, in numbers), and direct customer exposure (you sat with the stakeholder, not behind a product manager). The second three ask how you deliver: messy-data work (real client environments are never clean), ownership under ambiguity (you ran the project when no one defined it), and AI/LLM depth (RAG, agents, evals, the reason the role exists).

Three rewrites follow from the signals. First, reframe every bullet from activity to outcome: "built an ETL pipeline" becomes "shipped a pipeline that cut the client's month-end close from five days to two." Second, write "I," not "we", FDE screeners read "we" as was carried, and they probe for it in the hiring-manager round. Third, cut the algorithm trophies; a data-structures medal signals preparation for the wrong interview. What replaces it is a portfolio. The freelance section above already named the rule, the portfolio is the credential: a deployed Worker, a shipped plugin, a live connector app, each with a one-line outcome attached. Every capstone in this book is designed to be exactly that line.

One item on that list is not like the others, and a vendor-neutral candidate should lead with it: a governed slice of a profession, published for both readers. A deployed Worker proves you can build. A governed slice proves you own something no employer handed you, and it is the one line on the page a screener has almost certainly never seen before.

Appendix B: The FDE interview, the loop and the trap

The loop runs five to eight stages over three to six weeks: recruiter screen, hiring-manager screen, a practical coding round, a system-design round, the decomposition case study, a client simulation, and a behavioral round, with some AI labs adding a take-home built on their APIs.20 Two rounds decide the outcome, and neither is the one engineers prepare for.

The decomposition round is the filter. You are handed a vague, real enterprise problem: "a major city wants to cut emergency response times; they have call data, traffic data, and ambulance GPS; you have sixty minutes". And the single most common rejection is answering it. The candidate who opens with "I'd build a predictive model using XGBoost" has already failed, because they solved before they scoped. What scores is the sequence: clarify the actual goal, name the stakeholders and the success metric, map what data exists and who owns it, decompose into subproblems sequenced by risk, and propose the thinnest end-to-end skeleton first, assumptions stated out loud, failure modes surfaced unprompted, thinking narrated continuously. Readers of this book will recognize the sequence: it is spec-driven development performed verbally. The round is not testing whether you know the answer; it is testing whether you write the spec before you let anyone, human or agent, execute.

The client simulation is the second filter. An interviewer role-plays a customer, sometimes frustrated, sometimes non-technical, and you deliver bad news, push back on a governance-compromising request, or explain why the system cannot promise 100% accuracy, all without jargon and without promising what you cannot keep. The five red flags interviewers name are consistent across sources: solving before clarifying, ignoring cost and constraints, thin deployment stories (no account of what happened when an API failed in production), zero compliance vocabulary in regulated domains, and no customer instinct.20

One more format is spreading and deserves its own line: the live build. One documented loop ran three hours: thirty minutes turning a vague use case into requirements under cross-examination, ninety minutes building the working solution with an AI coding assistant while validating every suggestion and debugging live, and sixty minutes presenting the result to a role-played stakeholder in pure business language.21 No LeetCode appeared at any stage. The middle round is this book's Mode 1 discipline performed under observation: direct the agent, verify everything it produces, narrate the loop.

Company flavor matters at the margin: Palantir leans on data engineering, ontology thinking, and the decomposition round it invented; OpenAI leans on building and evaluating systems against its APIs, with "how do you know it's actually working?" as the differentiator question; Anthropic (which titles the role Applied AI Engineer) leans on production LLM systems, evals, and mission alignment.20 But the fundamentals above are the loop everywhere, and preparation is a four-to-six-week discipline: fundamentals and stories first, system design next, then timed decomposition practice with a partner, recorded, because most candidates are shocked at how quickly they jump to solutions, and company-specific tuning last.

Appendix C: Preparing for the FDE with this book

The interview was not designed around this book, but it might as well have been. Each round maps to material you have already been assigned:

Interview round	What it tests	Where this book trains it
Decomposition case study	Scoping before solving, spec discipline out loud	Spec-Driven Development, How to Think in the AI Era
Practical coding	Real engineering with an agent, verified	Python in the AI Era; Code You Never Write; the Seven Principles of Problem Solving
AI-specific depth	RAG, agents, evals, "how do you know it works?"	Give Your AI Searchable Context, Build AI Agents, Eval-Driven Development
System design	Enterprise deployment under constraints	The Thesis invariants; Choosing Agentic Architectures; Deploy the Agent Harness
Client simulation	Trust, pushback, business language	Human-Agent Teams; the Strategist track
The live build	Directing an agent under observation	Claude Code and OpenCode; Agentic Engineering Fundamentals
The portfolio behind it all	Shipped, demonstrable outcomes	Every capstone: a deployed Worker, a plugin, a connector-native app, a governed slice

Read the table bottom-up and it says something worth noticing: the interview's hardest rounds, decomposition, the live build, the eval question, are not extra material bolted onto the curriculum. They are the curriculum, examined. The candidate who has actually manufactured a Worker under spec discipline walks into the decomposition round having rehearsed it dozens of times, because writing intent a Worker can be held to and scoping a vague enterprise problem out loud are the same skill at two different volumes.

---

Footnotes

1. Gergely Orosz, "What are Forward Deployed Engineers?", The Pragmatic Engineer, August 2025. ↩

2. OpenAI, "The OpenAI Deployment Company", 2026. ↩

3. Fast Company, "Postings for this AI job are up 800%", 2025. ↩

4. Salesforce, "Forward Deployed Engineers Are Proving AI Makes Tech Jobs More Human", 2026. ↩

5. PYMNTS, "OpenAI Launches $4 Billion Company to Accelerate Enterprise AI Adoption", May 2026. ↩

6. Fortune, "MIT report: 95% of generative AI pilots at companies are failing", August 2025. Original study: MIT Media Lab Project NANDA, "The GenAI Divide: State of AI in Business 2025", July 2025. The 67% and 33% deployment rates are from the same report.

Note that several secondary accounts, Fortune's included, restate the internal-build figure as "one-third as often", which implies roughly 22%: the report's figure is 33%, meaning about half as often, not a third. The report itself states that the association between external partnerships and success does not establish causation, labels the work preliminary findings, and uses a six-month observation window. ↩

7. Motley Fool, "Palantir Reaches Huge Milestone", November 2024. ↩

8. Andrew Ng, "Forward Deployed Engineers and the Future of AI Engineering", The Batch, May 2026. ↩

9. VentureBeat, "Claude Code turned every engineer into three. Now companies need more product thinkers", June 2026. The ratio figures are industry estimates reported secondhand: directional signal, not measurement. ↩

10. CNBC, "AWS invests $1 billion to embed AI forward deployed engineers with customers", June 30, 2026. See also AWS Newsroom, same date, and Reuters (Greg Bensinger). ↩

11. CNBC, "Microsoft commits $2.5 billion and 6,000 employees to new AI implementation unit", July 2, 2026. The same report notes that OpenAI and Anthropic each established FDE groups in May 2026. Mandate language from Microsoft's own announcement, "Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence", blogs.microsoft.com, July 2, 2026. ↩

12. BigGo Finance, "Annual Salaries Top $300,000: AI Commercialization Fuels 800% Surge in 'Forward-Deployed Engineer' Jobs", May 2026. Reports Indeed posting counts (643 → 5,330, April 2025–April 2026), Anthropic's posted FDE bands, and McKinsey QuantumBlack's Lead FDE requirements. ↩

13. Recruiting from Scratch, "Forward Deployed Engineer Salary in 2026", June 2026. Median and percentile bands from analysis of 135 active postings. ↩

14. Rezoomed, "Forward Deployed Engineer Jobs, Salary, and How to Land One", May 2026. Top-of-ladder compensation figure and the zero-sales-quota finding; senior/staff bands corroborated by Jobs by Culture, "Forward Deployed Engineer Boom", May 2026. ↩

15. Sanjeev Aggarwal, "India Can Be The 'FDE Factory' For The World", interview with Shereen Bhan, Young Turks Reloaded, CNBC-TV18, July 3, 2026. The 100-FDE / $100M and margin figures are Aggarwal's stated projections for the FDE-led services model, not reported results. ↩

16. Boris Cherny (@bcherny), X post, June 2026. Cherny is the creator of Claude Code at Anthropic; the five archetypes are his observation of the Claude Code team. ↩

17. Upwork, "Hire the Best Forward Deployed Engineers", accessed July 2026. Project bands and hourly ranges as published on the category page; profile observations from the same page. ↩

18. Adam Moore (Morela), "What is a Forward Deployed Engineer, and are FDE jobs for IT contractors ripe?" and "How to land Forward Deployed Engineer roles beyond Palantir, Anthropic and OpenAI", ContractorUK, May–June 2026. Day rates quoted outside IR35. ↩

19. Go Fractional, "What Is a Forward Deployed Engineer?", May 2026; Fractional Jobs, "Fractional Forward-Deployed Engineering Lead at a Fintech Startup" (filled). Contract FDE hourly bands of $60–250 corroborated by Rocketlane, February 2026. ↩

20. Exponent, "Forward Deployed Engineer Interview: The Definitive 2026 Guide", 2026. Loop structure, the decomposition framework, red flags, and company-specific patterns; the six résumé signals corroborated by practitioner screening guides including AIDD India's FDE profile auditor and interview-preparation walkthrough, 2026. ↩

21. Bagheshri Suresh Kumar, "I Interviewed for a Forward Deployed AI Engineer Role: Here's What No One Tells You", Medium, 2026. A first-person account of the three-hour define–build–sell loop, built live with an AI coding assistant. ↩

22. Jacob Zinkula, "Six people who left Google on why they walked away", Business Insider, June 27, 2026; Imran's profile widely republished, e.g. Entrepreneur, July 2026. Compensation figures are Imran's self-reported W-2 income; a single-person account, cited as a signal of the pattern, not a measurement of it. ↩

23. Pauline Brunet, "Forward Deployed Engineering at Cursor", AI Engineer World's Fair, Forward Deployed Engineering track, June 30, 2026 (youtube.com/watch?v=APqXGyCoGW4). Brunet is VP of Forward Deployed Engineering at Cursor; the fit matrix, scoping format, and ROI framing are her stated practice: one vendor's playbook, not an industry measurement. See also her Latent Space interview at the same conference, "How Cursor deploys AI inside the enterprise", July 2026. ↩

24. Kevin Bai, "Forward Deployed Engineering 101", AI Engineer World's Fair, Forward Deployed Engineering track, June 30 to July 2, 2026 (youtube.com/watch?v=KwhgfwOSToQ), circulated on X in July 2026. Bai is a member of technical staff on Anthropic's Applied AI team; he led FDE engagements at Palantir and founded Rippling's FDE function as its first hire, growing it to about twenty-five people in a year. The average contract value figures, the two by two, the dev shop warning, and the agentic hypothesis are his stated framing and his own recollection of the numbers: one practitioner's account, not an audited measurement. Two biographical details are not from the talk: the description of his Palantir engagements and the diplomacy-to-engineering span of his background come from his own site, zkevinbai.com, accessed July 2026. Note also that several secondary write-ups place the first-hire detail at Palantir rather than Rippling; both the talk and his own site place it at Rippling. The dedicated FDE track ran nine sessions at this year's conference, and Brunet's talk in note 23 was another of them. ↩

25. Stephen Foley, "PwC US chief says partners who resist AI have no place at the firm", Financial Times, March 18, 2026 (ft.com/content/cd365ae8-0f9c-4c33-8ee0-7fad89abd125). Paywalled; the billing-model change, the PwC One launch, and the six opening services are corroborated in Accounting Today, "PwC CEO: You cannot opt out of AI", March 20, 2026. The messy-process warning is from Ana Altchek, "The 2 biggest mistakes companies are making with AI, according to PwC's US CEO", Business Insider, July 29, 2026 (businessinsider.com/pwc-us-ceo-companies-getting-wrong-about-ai-2026-7). One firm's stated strategy, not an industry measurement. ↩

---

Flashcards Study Aid

---

Test Your Understanding

Checking access...