The Roles This Book Trains
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.
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.
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.
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; 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
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.
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 June 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
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.
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.
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. 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.
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. 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.
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: 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: on this market, the portfolio is 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.
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.
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 — 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, 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.
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 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
Gergely Orosz, "What are Forward Deployed Engineers?", The Pragmatic Engineer, August 2025. ↩
OpenAI, "The OpenAI Deployment Company", 2026. ↩
Fast Company, "Postings for this AI job are up 800%", 2025. ↩
Salesforce, "Forward Deployed Engineers Are Proving AI Makes Tech Jobs More Human", 2026. ↩
PYMNTS, "OpenAI Launches $4 Billion Company to Accelerate Enterprise AI Adoption", May 2026. ↩
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." ↩
Motley Fool, "Palantir Reaches Huge Milestone", November 2024. ↩
Andrew Ng, "Forward Deployed Engineers and the Future of AI Engineering", The Batch, May 2026. ↩
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. ↩
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). ↩
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. ↩
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. ↩
Recruiting from Scratch, "Forward Deployed Engineer Salary in 2026", June 2026. Median and percentile bands from analysis of 135 active postings. ↩
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. ↩
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. ↩
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. ↩
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. ↩
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. ↩
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. ↩
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. ↩
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. ↩
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. ↩