The Forward Deployed Engineer Agent Factory Model
A platform and a business model in one: a five-layer stack our graduates can build on and earn from, at every layer above the foundation.
Think of a franchise. Someone builds the kitchen equipment any restaurant could use (Layer 0). Someone assembles it into one ready-made kitchen you can install anywhere (Layer 1). A cooking school teaches people to run kitchens, and runs one itself as proof (Layer 2). A brand packages that kitchen for one cuisine, with its own recipes and food-safety rules (Layer 3). And a franchisee opens one restaurant, fitted to one neighborhood (Layer 4). This page explains the same idea for AI software: build the base once, then use AI to fit it to each profession and each customer. If a term on this page is new to you, the glossary defines it, and the crash courses teach every skill mentioned here.
Apps that are built one way for every customer are losing ground in complex, AI-enabled work. The next generation of software will not be sold as a set-in-stone product that every customer uses the same way. It will be sold as a base that an AI customizes for each customer. Someone builds the framework once. Then an engineer, working with an AI agent, shapes it to fit one company: its data, its rules, its workflows.
We call our version of this pattern the Forward Deployed Engineer Agent Factory Model, or the FDE AF Model for short. Read one way, it is an architecture: five layers from framework to customer. Read the other way, it is a business model: five layers of places to earn. This page explains the model, its layers, and the rule that holds it together. It is the blueprint for how the Agent Factory ecosystem grows from a book into vertical AI-native businesses, and for how our graduates monetize what they learn.
One prerequisite before the model. Everything here arranges parts you meet in the ecosystem overview: the System of Record is the source, Zia Tutor AI teaches from it, and Zia Developer AI builds with it. If those three are new to you, read the overview first: without the architecture, the layers below are just names.
The mechanism, the provocation, the synthesis
Three sources point at the same future from three directions: proven delivery practice, a market provocation, and this book's synthesis of the two.
The proven mechanism. Palantir, the US software company known for building data platforms for governments and large enterprises, pioneered and popularized this delivery model over the past two decades. It builds one core platform, then embeds Forward Deployed Engineers (FDEs) inside each customer to fit the platform to that customer's reality. Each custom fix that repeats across customers is folded back into the platform: the FDE literature calls this turning a gravel road into a paved highway. In 2026 the FDE role is spreading across model companies, cloud providers, and AI startups: OpenAI runs a large FDE organization, Anthropic and Google Cloud are hiring for the role, and a16z (Andreessen Horowitz, one of the best-known US venture capital firms) has called it the hottest job in startups. Product thinker Marty Cagan gives the strategic reason: a company with only custom projects drowns in one-off custom code, and a company with only one unchanging product cannot fit real customers. The FDE model is the bridge between the two.
The market provocation. Practitioners in the SaaS world now argue that unchanging, ready-made apps will be replaced by open, buildable bases. Alex Becker, founder of the ad-tracking company HYROS, puts it plainly: small teams will ship white-label versions of the apps you know, customers will pay a recurring fee for the base, and an AI agent will connect the pieces and add the missing features in a prompt. A company survives, he argues, only in one of three positions: as the provider of a framework others build upon, as an API company, or as a network effect that cannot be replicated. He also predicts the winning bases will be "LLM optimized with the correct context built into them already." Hold that phrase: we return to it below. One practitioner's post is a provocation, not proof: the proof is the hiring data and delivery practice above.
The synthesis. Becker sees the demand but jumps straight from open components to per-customer agencies, so domain knowledge gets rebuilt in every engagement. Palantir proved the mechanism, and even grew verticals from it (its Skywise aviation platform began as customer work at Airbus), but the whole pattern stays proprietary, locked inside one company. The FDE AF Model takes both and changes two things: it makes the vertical layer explicit, so domain knowledge is encoded once and reused, and it makes the whole pattern teachable, so any graduate can run it instead of one company owning it. It also states the promotion rule as law, so field work compounds into the platform instead of dying at the customer.
The five layers
Every layer is defined by two questions: what does it produce, and who consumes it? If you cannot answer both, the thing you are describing belongs in a different layer.
Two clarifications before the definitions. First, the term System of Record appears at three scopes in this model, and the scopes must not blur: Layer 0 builds the machinery for Systems of Record, Layer 1 is the one reusable SoR component (call it the SoR kernel), and Layer 3 produces domain SoR instances. Machinery, kernel, instance: hold those three words and the term stays sharp.
Second, the model has three views laid over the same stack: a technical view (what gets built), a talent view (who builds and runs it: for example, Layer 2 is where the Outcome Architects and FDEs are trained), and a revenue view (how each participant earns). The layer definitions below are the technical view. The talent and revenue views come after them, as overlays: people and income are not architectural outputs, so they are described separately.
To keep the layers concrete, we will follow one imagined graduate, Ayesha from Lahore, through the whole stack. One italic line per layer shows what that layer means for her.
Layer 0: The foundation framework
Produces: the reusable machinery for building Systems of Record for humans and agents: serving over MCP (the Model Context Protocol, the open standard that lets AI agents call tools and read content: the Skills & Connectors crash course teaches it), the Markdown and Docusaurus authoring pipeline, pgvector retrieval on Postgres, Better Auth as the single authorization server, and JWT/JWKS verification at every network boundary.
Consumed by: component builders. Layer 0 knows nothing about any subject. It is pure infrastructure: patterns and machinery, no content.
For Ayesha, a new PIAIC graduate, this layer is the machinery she never has to build: it is already running when she starts.
Layer 1: The content System of Record component (the SoR kernel)
Produces: one generic, corpus-agnostic MCP component: the technical substrate for a governed System of Record. Load a Markdown corpus (a body of content: a book, a rulebook, a product manual) into it and you get semantic retrieval served over MCP: agents and software clients consume it directly, and humans reach it through the websites, tutors, and apps built on top of it.
Retrieval alone is not a System of Record. The corpus also needs an owner, versioning, review and approval, access control, and citation support. The kernel provides the hooks for that governance; the governance itself is work each instance must do. This one distinction separates the FDE AF Model's foundation from most retrieval tutorials on the internet. For why agents need Systems of Record at all, read A System of Record for the Agent Era: without ground truth, agents hallucinate; with it, they execute.
Consumed by: ecosystem builders at Layer 2 and vertical builders at Layer 3. This is the key horizontal move: one component, many corpora. The Agent Factory book's System of Record is an instance of this component. An accountancy corpus is another instance of the same component. Nothing about the component itself is about teaching AI.
Ayesha loads a training manual into the kernel and has a searchable, citable source by evening. The slow part is the governance: naming an owner, setting up review, deciding who may read what.
Layer 2: The teaching and development ecosystem
Produces: the generic components and the composition pattern: learning_mcp, pedagogy_mcp, builder_mcp, and the thin MCP gateways that compose them, with Zia Tutor AI and Zia Developer AI as the reference gateways.
Consumed by: learners today, and Layer 3 tomorrow, which treats Layer 2 as its component library. This layer teaches how to build generic AI-native companies, AI workers, and AI solutions.
This is where Ayesha trained: the crash courses taught her the model, Zia Tutor AI answered her questions, and Zia Developer AI helped her build her first agent.
Layer 3: Vertical ecosystems
Produces: the domain trio, one per vertical (a vertical is one industry or profession, such as accounting or healthcare). A domain System of Record: the authoritative corpus of regulations, procedures, catalogs, or protocols, served through the Layer 1 component. A domain expert twin: the Zia Tutor AI slot, filled by that domain's expert, teaching in their voice. A domain builder: the Zia Developer AI slot, preloaded with that domain's architectures and compliance constraints.
Consumed by: domain professionals, and the FDEs who deploy into that domain. Our first vertical is under construction for accountants, building on our chartered accountancy curriculum work. Concretely, the trio there looks like this: accounting standards, tax rules, and professional-body material as the domain SoR instance; an expert twin that teaches in a senior chartered accountant's voice; and a builder preloaded with Pakistani regulatory constraints, so every agent it produces respects filing rules and audit trails by default. Healthcare, Islamic finance, and government services are natural candidates after it. And each vertical repeats per jurisdiction: the same trio rebuilt for US GAAP and IRS rules is a separate opportunity for a graduate serving American clients, and the same is true for the UK, the Gulf, and beyond.
Ayesha partners with her aunt, a chartered accountant with twenty years of practice: the aunt brings the expertise and her authored material, and Ayesha builds the trio around it.
Layer 4: Customer instances
Produces: a deployment that achieves a defined, measured business outcome for one company. A working system is not the finish line. Every engagement starts with a baseline, a target, and acceptance criteria, and ends with three kinds of production evidence: business KPI measurement (key performance indicators: the numbers the business cares about), adoption by the people who do the work, and agent evaluations. The evaluations show the system behaves correctly; the KPIs show the business actually improved. Both are required, because an agent can pass every evaluation and still fail to move the number that matters. The team takes a vertical ecosystem and uses AI to fit it to that company: its ontology (the map of the company's concepts and how they relate), its data, its workflows, its people.
Consumed by: that company's human-agent teams. Two roles do this work, and they are not the same role. The Outcome Architect owns intent: the business problem, the redesigned human-agent workflow, the target outcome, and adoption. The FDE owns implementation: integrations, ontology, tools, evaluations, and production operation. In a small engagement one capable person plays both; in a large or regulated one they work as a pair. This is where the market's "new agency model" lives, and it is where our graduates earn: what Becker calls the new agency, Palantir calls forward deployment.
Ayesha's first engagement is a mid-size accounting firm in Chicago, served remotely from Lahore. The baseline: four hours to prepare one working-paper file. The target: forty minutes. She deploys, measures, and proves it.
The ecosystem is the first proof
Notice the recursion. Layer 2 teaches the FDE AF Model, and Layer 2 is itself built with the FDE AF Model: its System of Record is a Layer 1 instance, its gateways compose Layer 2 components, and its content was assembled the way we teach you to assemble yours. The first complete implementation of the model is the ecosystem that teaches the model. That is not an accident. It is the thesis, shipped.
The law of the model: promote downward
The FDE literature carries one warning above all others: without discipline, per-customer work multiplies into a thousand custom forks that must be maintained forever. So the FDE AF Model has one law, and it is not optional:
Anything that repeats at a layer must be evaluated for promotion into the layer below it.
A Layer 4 customization that appears across three or more customers is a candidate for the Layer 3 vertical. A Layer 3 component that turns out to be domain-agnostic is a candidate for the Layer 2 library. An infrastructure pattern that every component needs sinks toward Layer 1 or Layer 0. Repetition opens the gate: it does not walk through it. A capability is promoted only when it can be abstracted without any customer's confidential data, fits the platform strategy, passes security and compliance review, ships with tests and agent evaluations, and has a named long-term owner.
Promotion also has to answer the customer's fair objection: why should my paid work become your platform? Three commitments answer it. Promotion is clean-room: the pattern is promoted, never the data, and a customer's confidential ontology never leaves Layer 4. Promotion is opt-in: promotion rights are agreed in the engagement contract, not assumed. And promotion is rewarded: a customer whose work generalizes gets an incentive, such as reduced ongoing fees, because the promoted component now lowers their own maintenance cost too.
Finally, the law has a return direction: learning flows down into the foundation, and versioned improvements flow back up, so every deployed customer benefits from what the platform learned. This loop is the gravel-road-to-paved-highway pattern made explicit, and it is what separates a compounding platform from a services shop with a nice diagram. Field work is not just paid delivery: it is the platform's research and development.
The base must be agent-readable
One more requirement, and it is the quiet technical heart of the model. Becker predicts the winning bases will ship "LLM optimized with the correct context built into them already." Jensen Huang, CEO of NVIDIA, makes the same point from the enterprise side: agents need authoritative sources to read from, write to, and verify against, an argument this book takes up in A System of Record for the Agent Era. That is exactly what Layers 0 and 1 are for. An open-source repository is not enough: a pile of code without context forces every AI agent to guess. A governed System of Record, served to agent clients over MCP and indexed for semantic retrieval with pgvector, is different in kind: it lets agents ground their answers in versioned, cited source material, because the base is addressed to the AI as a first-class reader. Customization by prompt only works, reliably and at Layer 4 speed, when the base can explain itself to the agent doing the customizing.
Here is why this stack beats a generic boilerplate (ready-made starter code), piece by piece. Versioned Markdown with stable identifiers gives deterministic chunking, so a citation still points at the same passage after the corpus is updated. MCP gives the agent a typed tool surface to call instead of a website to scrape, so behavior is testable. Better Auth with JWKS verification at every boundary means every agent tool call is authenticated and auditable, which is what lets a regulated customer say yes. And keeping the vector index in the same Postgres as the governed corpus keeps retrieval consistent with versioning: the agent can never retrieve a paragraph the governance layer has retired. None of these properties comes free with a repository of code; each one had to be designed in. That is the difference between the FDE AF Model's foundation and a generic boilerplate on GitHub.
The FDE AF Business Model: where each layer earns
The layers also give the model a clean commercial map. Layer 2 earns through education and reaches hundreds of thousands at near-zero LLM-inference cost to the platform, because connector-native apps let the user bring the model. (The platform still pays for storage, embeddings, auth, and operations: what it does not pay for is the LLM bill that usually caps reach.) Layer 3 earns through domain partnerships: the domain expert licenses their approved persona and their rights-cleared authored material. (A domain corpus often also contains laws, standards, and third-party publications the expert does not own: those enter under their own licenses.) Layer 4 earns through FDE engagements: discovery and outcome design, deployment, and recurring revenue through managed operation, governance, and continuous improvement, with maintenance included according to the engagement model.
This is why the model is also a platform for our graduates. You do not have to wait until you can build a whole company: you can enter at any layer. Build components at Layers 1 and 2: independently, or as contributions to the ecosystem, where a contribution agreement defines ownership, licensing, quality requirements, support obligations, and revenue sharing before the work ships. Partner with a domain expert to launch a vertical at Layer 3. Run FDE engagements for companies at Layer 4. PIAIC (the Presidential Initiative for Artificial Intelligence and Computing) trains the FDEs, the base gives them the factory, the verticals give them the domain, and every layer above the foundation is a place to earn.
One more thing the commercial map needs: clear ownership, agreed before work starts, so reuse never becomes a dispute.
| What | Who owns it |
|---|---|
| Foundation and generic components (Layers 0 to 2) | The Agent Factory ecosystem; contributed components per their contribution agreements |
| Vertical corpus and expert twin (Layer 3) | The domain partnership: the expert's rights-cleared material under license, third-party sources under their own licenses |
| Customer data and confidential ontology (Layer 4) | The customer retains ownership or control, subject to law and third-party rights |
| Customer configuration and custom extensions | Defined in the engagement contract |
| A generalized capability promoted down the stack | The platform or vertical it lands in, with promotion rights agreed in the contract |
Where the model does not apply
A model you cannot break is a slogan, so here are the breaking points. Not everything should be promoted: work that is jurisdiction-specific, contractually restricted, or tied to one customer's unusual process should stay at Layer 4 forever, and forcing it down the stack pollutes the platform. Repetition at two customers is a signal to watch, not to act: the default trigger for a promotion review is three or more customers plus strategic fit. A vertical should not launch without a committed domain expert: the expert twin is the vertical's product, and a vertical without one is just a corpus, so until an expert commits, serve that domain through Layer 4 engagements instead. And the model assumes a stable base: while the foundation is in private beta, every vertical multiplies its bugs, which is why we are proving the pattern on one vertical before opening it wide.
Where to start
Here is Ayesha's whole path again, in one moving picture: five layers, climbed one at a time.
If you are new, start with the crash courses: they take you from foundations to building Digital FTEs, layer by layer. If you want to see the seat you would occupy in this model, read the roles this book trains. And if you are ready to build on the base itself, apply for System of Record beta access. The model is the map: the courses are the road.
Sources
- Palantir Technologies, "A Day in the Life of a Palantir Forward Deployed Software Engineer," Palantir Blog, 2022. Primary source for the role definition in Palantir's own words. blog.palantir.com
- Marty Cagan, "Forward Deployed Engineers," Silicon Valley Product Group, 2025. svpg.com/forward-deployed-engineers
- Gergely Orosz, "What are Forward Deployed Engineers, and why are they so in demand?", The Pragmatic Engineer, 2025. newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- Gergely Orosz, "The Pulse: Forward deployed engineering heats up again," The Pragmatic Engineer, May 2026. Reports major FDE demand at Google, OpenAI, and Anthropic. newsletter.pragmaticengineer.com/p/the-pulse-forward-deployed-engineering
- Palantir Technologies, "Palantir and Airbus Extend Strategic Collaboration," press release, February 2026. Official source for the Skywise partnership, active since 2015. investors.palantir.com
- Tao An, "Forward Deployed Engineers: AI's Answer to the SaaS Customization Paradox," Medium, 2025. Supplementary commentary. tao-hpu.medium.com
- Natalie Meurer (Sierra), "Forward Deployed Engineers and the future of software engineering," Latent Space, 2026. latent.space/p/forward-deployed-engineers-aiewf
- Andreessen Horowitz, "Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups," a16z, 2025. a16z.com/services-led-growth
- OpenAI, "Technical Deployment Lead, Forward Deployed Engineering," careers listing describing outcome-based FDE delivery, 2026. openai.com/careers
- Alex Becker (founder, HYROS), public post on the future of SaaS and framework-based apps, Facebook, 2026. Cited as a practitioner provocation, not as evidence. facebook.com