Skip to main content

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.

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.

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.

Role map: a core pipeline, the roles that extend and support it, the deliberate stops, and the baseline everyone starts from

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.

The core pipeline: four internal roles, or one embedded Forward Deployed Engineer at a client

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. Trains it — 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, 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.

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 Forward Deployed Engineer sits at the intersection of three roles: Software Engineer (builds features, writes production code, ships end-to-end), Platform Engineer (improves core product, builds data models and APIs, handles deployment), and Solutions Architect (customer discovery, technical consulting, integration design). The FDE bridges all three: engineering, product, and customer impact.

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 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 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.

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.

This is a role almost no one else trains, 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 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 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 Forward Deployed Engineer, it is a role almost no one else trains. Trains it in full: judgment in, working agent out.

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 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, and how far this book carries you from there.

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." ↩

  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. ↩