The Forward Deployed Engineer Agent Factory Model

A platform and a business model in one. Panaversity runs the platform. Our graduates build and earn on top of it: Systems of Record for clients at Layer 1, manufacturing at Layer 2, and domain startups they own at Layers 3 and 4.

In plain words

This model has five layers. Read them bottom-up:

• Layer 0 is the machinery: the technical parts everything above is built from. Panaversity builds and runs it.
• Layer 1 turns any content (a book, a rulebook, a manual) into a source of truth that both people and AI agents can read and trust.
• Layer 2 teaches you the whole method and gives you the building tools: Zia Tutor AI to learn with, Zia Developer AI to build with.
• Layer 3 packages all of it for one profession, such as accounting: that profession's knowledge, its own AI teacher, and its own AI builder.
• Layer 4 puts it to work for one company: AI Workers are manufactured for it, and the improvement is measured and proven.

One sentence for the whole page: build the base once, then use AI to fit it to each profession and each customer. If a word on this page is new to you, the glossary defines it, and the crash courses teach every skill mentioned here. You should also read more about Forward Deployed Engineers.

Software that works exactly the same way for every customer is becoming less useful for complex, AI-enabled work. The next generation of software will often start as a flexible base instead of a fixed product. An AI can help customize that base for each customer. Someone builds the framework once. Then an engineer, working with an AI agent, fits it to one company: its data, rules, and workflows.

We call our version of this pattern the Forward Deployed Engineer Agent Factory Model, or the FDE AF Model for short. You can read it in two ways. As an architecture, it has five layers that move from the foundation to the customer. As a business model, Panaversity runs the platform at the lower layers, while graduates build services and businesses above it. This page explains the layers and the rule that connects them. It also shows how the Agent Factory ecosystem can grow from a book into profession-specific AI businesses, and how graduates can earn from what they learn.

Before continuing, note one important point. This model organizes three parts introduced in the ecosystem overview. The System of Record provides trusted knowledge. Zia Tutor AI teaches from that knowledge, and Zia Developer AI uses it to help build solutions. If these three parts are new to you, read the overview first. You may also continue here, because each part is introduced again when it appears below.

📚 Teaching Aid

Open Full Slideshow

View Full Presentation — The FDE AF Model

---

Where this model comes from

The model was not invented in this book. Three sources point at the same future: what one company proved, what the market now predicts, and what this book adds by combining the two.

What Palantir proved. Palantir is a large US software company that builds data systems for governments and big companies. Twenty years ago it faced a problem every software company faces. If a company sells one finished product, the same for everyone, the product never quite fits any customer's real work. If it builds custom software for each customer, it ends up maintaining hundreds of separate systems, and the work never gets easier.

Palantir found a third way. It builds one core platform. Then it sends engineers, called Forward Deployed Engineers (FDEs), to work inside each customer's organization and fit the platform to that customer's real needs. The most important step comes next. When many customers need the same improvement, Palantir adds that improvement to the shared platform. Future customers can then use it without rebuilding it. People in this field compare this process to turning a gravel road into a paved highway: each project improves the path for the projects that follow.

The approach worked, but it remained rare for about twenty years because customization was expensive. It often required teams of engineers working inside a customer for years. Only governments and very large companies could afford it.

AI changed both the demand and the cost. First, a language model is a general capability, not a finished business solution. A company still needs someone to connect it to the company's data, rules, and workflows. Second, AI helps engineers complete that customization much faster. One engineer working with AI agents can now do in weeks what previously required a team working for years. AI therefore increased demand for the model while reducing the cost of using it.

That is why the role is spreading quickly in 2026. OpenAI runs a large FDE team. Anthropic and Google Cloud are also hiring for the role. a16z (Andreessen Horowitz, a well-known US investment firm) has called FDE the hottest job in startups. The lower cost also means a graduate can now use this model for a mid-size firm, even though the original model once depended on billion-dollar contracts. Product thinker Marty Cagan explains the value clearly: the model sits between a standard product that does not fit enough and custom work that cannot scale.

What the market predicts. Alex Becker, founder of the ad-tracking company HYROS, made a widely shared prediction about where software is going. Today, most business software is sold as a finished app: you subscribe, and you use it the way it comes. Becker argues those days are ending. Instead, companies will pay for an open base (software they are allowed to change), and an AI agent will connect the pieces and add the missing features from a simple prompt.

In his view, a software company will survive in one of three positions:

1. It provides a base that others can build on.
2. It provides essential services, such as payments, messaging, or hosting. Engineers often expose these services through APIs.
3. It owns a product whose value grows as more people use it. This is called a network effect.

He adds one more prediction, and it matters most for this book: the winning bases will come ready for an AI to read and understand from day one, or in his words, "LLM optimized with the correct context built into them already." We return to that idea below. One person's post is a prediction, not proof. The proof is the hiring data and the delivery practice above.

Other forecasters describe a similar change, but they also give a warning. The AI Futures Project writes detailed forecasts about AI. It describes a future in which each economy has two workforces: people and AI agents. In this forecast, AI companies automate one profession at a time (for example, accounting first, then law, medicine, and other fields).

In that forecast, an AI lab trains its own language model on a profession's knowledge. The lab interviews experts, buys data, builds practice environments, and continues training until much of the profession's knowledge is inside the lab's model. However, the people building the system may have little direct experience in that profession. The profession receives the finished system, while the AI lab keeps most of the control and economic value. Knowledge trained into the lab's private model may also be difficult for the profession to recover or move elsewhere.

The FDE AF Model is a plan for the opposite. In our model, accountants and the graduates who work beside them build the accounting vertical, and doctors build the healthcare vertical. Each profession builds its own AI, keeps its own knowledge, and owns the result.

What happens if the forecasters are right? Suppose a large AI lab releases a general accounting AI next year. Would that remove the need for an accounting vertical? No. The FDE AF Model is designed to use stronger general models as they become available. Here are three reasons.

First, our verticals use the labs' models instead of competing with them. The important difference is where the profession's knowledge lives. In the lab-centered approach, much of the knowledge is trained into the lab's model. In our approach, the knowledge remains outside the model in a governed System of Record owned by the profession. The model reads that source when it needs the knowledge.

The user also brings the model: readers and customers connect an AI subscription they already have. When the underlying models improve, the vertical and its AI Workers get those improvements at no extra cost to the vertical. If a better model becomes available, the vertical can switch to it while keeping its own knowledge and other assets.

Second, a general AI cannot deploy itself inside a company. A general accounting AI may not know a country's exact filing rules. It may not have the profession's trust, and it cannot work directly with a local firm's reviewers unless someone designs that process. Even a highly capable accounting AI must be fitted to each company's data, workflows, and people. That work happens at Layer 4 and is led by the FDE. More capable models can make this work more valuable, not less.

Third, there is a limited opportunity to establish a trusted AI vertical in each profession and country. The first strong domain ecosystem can become difficult to replace. That ecosystem contains three parts: a trusted knowledge source, an AI teacher, and an AI builder. Its long-term advantages include the profession's trust, experienced experts, rights-cleared knowledge, and detailed local rules.

Large AI labs may win the competition to build the strongest general models. That is not the competition this model is trying to win. The goal is to become the most trusted profession-specific system in a particular country or region. Services can create early income, but long-term ownership comes from building a vertical business of your own.

What this book adds. Each source is missing something. Becker describes the demand, but in his picture every service team rebuilds the profession's knowledge (accounting rules, medical protocols, banking regulations) from scratch for every client. Palantir proved the delivery model, and even grew a whole industry product from it (its Skywise aviation platform began as custom work for Airbus). But the entire pattern stays locked inside one company, so you cannot learn it and run it yourself.

The FDE AF Model combines both ideas and changes two things. First, it gives each profession's knowledge a permanent home in the vertical layer. The knowledge can then be written once and reused instead of being rebuilt for every client. Second, it makes the whole pattern teachable, so graduates can learn and run it instead of leaving it inside one company. The model also makes continuous improvement a formal rule: reusable lessons from customer work must be considered for addition to the shared platform.

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 will make the layer definitions easier to follow.

First, the term System of Record appears at three scopes. Keep these three words separate:

Term	Meaning	Example
Machinery	The technical foundation used to build Systems of Record	Postgres, pgvector, MCP, and authentication
Kernel	The one reusable System of Record component	The standard SoR software assembled from Layer 0
Instance	One deployed System of Record containing a specific body of content	This book's SoR, a client's manual, or an Accounting SoR

Layer 0 builds the machinery. Layer 1 provides the reusable kernel. The kernel can then produce many instances. Generic instances, such as this book's SoR or a client's manual, appear at Layer 1. Profession-specific instances, such as an Accounting SoR, appear at Layer 3.

Second, the same five-layer stack can be viewed in three ways:

• The technical view shows what is built.
• The talent view shows who builds and operates it. For example, Layer 2 trains Outcome Architects and FDEs.
• The revenue view shows how each participant earns.

The layer definitions below use the technical view. The talent and revenue views appear later because people and income are not technical outputs of the architecture.

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

In plain words: this layer is the technical machinery everything above is built from. It is already running, so no one above this layer ever builds it.

Produces: the reusable machinery for building Systems of Record for humans and agents. It has four parts, and each part has a plain job:

• Writing and publishing: content is written in Markdown and published with Docusaurus, so the same source is also a website humans read directly.
• Finding by meaning: pgvector on Postgres indexes the content, so it can be searched by meaning, not just by keywords.
• Serving content to agents: MCP (Model Context Protocol) lets AI agents call tools and read the same content. It is an open standard, and the Skills & Connectors crash course teaches it.
• Checking who is asking: Better Auth acts as the single authorization server. JWT/JWKS verification at each network boundary confirms the identity and permissions behind every request.

Consumed by: MCP component builders. Layer 0 knows nothing about any subject. It is pure infrastructure: patterns and machinery, no content.

This is also the answer to a question every FDE practice must settle before it starts. Kevin Bai puts it as a test: do I have a platform, or am I willing to invest in building one? He asks it because an FDE function without shared primitives collapses into the dev shop described in the one law. Asked alone, most graduates would have to answer no. In this model they answer yes without building anything, because Layers 0 and 1 are already running and Panaversity operates them. The graduate's own shared assets sit higher up: the method System of Record she is given, and the domain builder she and her expert own and version at Layer 3.

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)

In plain words: this layer turns any content (a book, a rulebook, a manual) into a source of truth that both people and AI agents can read and trust.

Produces: the SoR kernel in two forms.

First, the kernel already runs as a service: the Agent Factory System of Record. It serves this book to both people and AI agents.

Second, you can run the kernel with your own content. You load a Markdown corpus (a body of content such as a book, rulebook, or product manual) and receive your own governed System of Record. For example, you could create an Accounting System of Record or a Core Banking System of Record. The kernel itself is assembled from Layer 0 components and libraries.

In both forms, the kernel provides semantic retrieval over MCP. Semantic retrieval finds content by meaning, not only by exact keywords. Agents and software clients use it directly. People reach it through websites, tutors, and other applications built on top of it.

info

Retrieval alone is not a System of Record. The content also needs a named owner, version control, review and approval, access control, and support for citations. The kernel provides technical features for this governance, but the owner of each instance must define and operate the governance process. This distinction separates the FDE AF Model from most retrieval tutorials. For more detail, read A System of Record for the Agent Era. Without trusted source material, agents may invent information. With it, they can act on verified knowledge.

Consumed by: ecosystem builders at Layer 2, vertical builders at Layer 3, and anyone who needs their own source of truth. Building and governing these instances for clients is also the first rung of the graduate earning ladder (see the business model below). One boundary keeps the rungs distinct. A client SoR build is a content service, with no Workers and no outcome contract. The moment an engagement adds manufactured Workers and a contract of success, it is Layer 4 work.

This is the key horizontal move: one component, many corpora. The Agent Factory book's System of Record is the first deployed instance of this kernel. An accountancy corpus, or a bank's policy manual, is another instance of the same kernel. Nothing about the kernel itself is about teaching AI.

Two more properties of an instance matter for everything above. First, a domain instance is not only reference material. An Accounting System of Record or a Core Banking System of Record also carries that domain's crash courses: the teaching content for building AI agents, AI workers, and AI-native companies in that domain.

Second, instances pair. Every instance speaks MCP, so the generic Agent Factory System of Record (which teaches how to build agents and AI-native companies in any domain) can be composed with a domain instance. One source teaches the method, the other teaches the domain, and an agent or a student reads both at once. Layer 3 is this pairing, packaged into a product.

That pairing is also the answer to a question about the engineer, not the architecture: what does a vendor-neutral FDE actually carry into a client? What You Carry In answers it at length. A vendor's FDE carries the vendor's platform. Ours carries two Systems of Record. The first is the method, and she did not build it: the deployed Agent Factory System of Record, deep and already governed, identical at a Lahore firm and a Chicago one, because the method does not change with the domain. The second is the profession, and she built it herself: her own domain instance, bound to one vertical and one jurisdiction, and hers alone. Both speak MCP, so her agent reads both at once with no integration work.

This is also why the domain instance is allowed to start small. It carries no method at all. Every page on specification, evaluation, deployment, and oversight already lives in the first System of Record, versioned and maintained by someone else. So the domain instance holds only what the profession adds: the law, the standards, the expert's procedures, the invariants, the decision map. A small vertical corpus is not a corner cut in order to ship early. It is what the pairing buys.

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

In plain words: this layer teaches you the whole method and gives you the building tools. You learn with Zia Tutor AI and build with Zia Developer AI.

Produces: reusable components and a standard way to combine them.

The components include:

• the learning component, which stores progress and memory;
• the pedagogy component, which controls how the system teaches; and
• the builder component, which helps users build agents and solutions.

Each component provides MCP tools and agent skills. An agent skill is a SKILL.md file that contains instructions and judgment an agent can load and follow. Small connectors, called MCP gateways, combine several components into one product.

For example, a teaching gateway can connect the content source, the pedagogy component, and the learner's progress. Together, they form one tutoring product.

Like Layer 1, Layer 2 is already deployed. The Agent Factory runs two reference products inside AI applications people already use: Zia Tutor AI for teaching and Zia Developer AI for development.

One boundary rule is important: these two products remain generic. A profession-specific vertical does not modify Zia Tutor AI or Zia Developer AI. Instead, it reuses the same components to build its own gateways at Layer 3.

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

In plain words: this layer packages everything for one profession. The package holds that profession's knowledge, its own AI teacher, and its own AI builder.

Produces: the domain trio, one per vertical (a vertical is one industry or profession, such as accounting or healthcare). The trio has three parts:

1. The domain System of Record: the authoritative corpus of regulations, procedures, catalogs, or protocols, served through the Layer 1 kernel.
2. The domain expert twin: a gateway in the Zia Tutor AI pattern, composed from the same Layer 2 components, with that domain's expert teaching in their voice. An expert twin uses the expert's real name and likeness, with their documented consent, never a synthetic substitute.
3. The domain builder: a gateway in the Zia Developer AI pattern, preloaded with that domain's architectures and compliance constraints. It is the vertical's Mode 2 manufacturing tool: the graduate uses it at Layer 4 to manufacture that domain's AI Workers (Digital FTEs).

Under the hood, the trio is the Layer 1 pairing made into a product. The domain SoR is paired with the generic Agent Factory SoR, so the vertical teaches both the method and the domain.

info

How is domain knowledge organized? Three forms, one governed home.

When you build a vertical, an AI system for one profession or industry, you must decide how the agent will receive each kind of domain knowledge.

The knowledge has three forms. Each form has a different job.

1. The corpus provides the evidence

A corpus is a large, organized collection of trusted source material. In a domain System of Record, it may include:

• regulations;
• standards;
• manuals;
• policies;
• procedures;
• other official documents.

The corpus may contain millions of words. It holds the information that the agent must be able to cite as evidence.

Think of it this way: the corpus is the collection of knowledge, while the System of Record is the governed system around that knowledge. The System of Record adds ownership, review, approval, versioning, access control, stable IDs, search, and citation support. The corpus is therefore one part of the System of Record, not a separate system.

The System of Record also includes the technology used to store, search, and serve the corpus. In this model, Postgres stores the content and its governance records, pgvector helps agents search the content by meaning, and MCP tools give agents a controlled way to retrieve it. These technologies are parts of the System of Record, but none of them is the System of Record by itself. The complete System of Record is the governed knowledge together with its storage, search, access controls, versioning, and citation support.

The agent can reach this knowledge in two main ways:

• It can search the corpus by meaning.
• It can fetch a complete section by its stable ID.

A stable ID is a permanent name for a section. It continues to point to the same section even after the content is updated. It works like a page reference that remains valid across new editions.

2. The map tells the agent what exists

The map is a small agent skill. A skill is a set of instructions that helps an agent perform a task correctly.

The map gives the agent an overview of the corpus. It explains:

• the corpus's main sections;
• what type of knowledge each section contains;
• how to search the corpus;
• when the agent must read a particular source.

For example, a Worker involved in customer onboarding may be required to read the relevant Know Your Customer (KYC) sections before taking any action.

The map is necessary because search has a weakness. An agent can search only for something it knows to look for. The map is always available to the agent, so the agent knows what information exists and when it must retrieve it.

The map also states the domain's non-negotiable rules. For example, an agent may never be allowed to move money without human approval.

For high-risk actions, written instructions are not enough. The rules must also be enforced through:

• tool permissions;
• human approval gates;
• automated policy checks.

The domain builder provides these safety settings together with the skills. This means the rule is not only written down. It is also enforced by the system.

3. The reflexes tell the agent what to do

Reflexes are procedural skills that the agent must load at the right moment.

Examples include:

• a checklist that must be completed in full;
• a required form or template;
• a checker script that the agent must run;
• a step-by-step procedure that must be followed in order.

These procedures should not come back from search as incomplete pieces. The agent must receive the full procedure before it begins the task.

A simple test helps decide where knowledge belongs:

• If the agent must find and cite the information, it belongs in the corpus.
• If the agent must load and follow the information to perform a task correctly, it belongs in a skill.

Some knowledge belongs in both forms. The full and authoritative details remain in the corpus. The skill tells the agent when to use those details and how to apply them.

The skills are also written, reviewed, approved, and versioned inside the domain System of Record. The domain builder then gives the correct skills to the agent.

The map stays available at all times. Procedural reflexes load only when the agent needs them.

One governed home. Three forms of delivery.

One discipline keeps this layer from becoming a maintenance nightmare: each domain has one builder, not one per customer. The same domain builder manufactures the AI Workers for every company in that domain. When the builder improves, it is updated in one place and versioned, so every company's Workers stay consistent. Customer specifics live in the customer's Layer 4 instance, never inside the builder.

If you fork the builder per customer, you inherit exactly what the promotion law exists to prevent: many builder versions, many diverging Workers, maintained forever. This is Palantir's key move, now in the graduate's hands. The domain builder is your one core platform. Every fix that repeats across your customers is folded back into it, so every future customer gets it for free.

Consumed by: professionals in that domain and the FDEs who deploy solutions for them.

Our first vertical is sales, and its founding corpus (the FISTA Sales Book) is complete. Our second, now in validation, is being built for accountants and grows from our chartered accountancy (CA)/CPA curriculum work. Its trio would contain:

1. an Accounting System of Record with accounting standards, tax rules, and material from professional bodies;
2. an expert twin that teaches in the voice and style of a senior accountant; and
3. a builder with accounting and regulatory constraints already included, so the agents it produces follow filing rules and create audit trails by default.

Healthcare, Core Banking, Islamic finance, and government services are possible future verticals. Each vertical must also be adapted for a jurisdiction (a country or region with its own rules). For example, a trio built for US GAAP and IRS rules is a separate opportunity for a graduate serving US clients. The same approach can be used for the UK, the Gulf, and other regions. Which vertical you should build is a decision with its own method: the screen, the eight tests, and the launch gates in Choosing Your Vertical. And filling the three forms above is its own discipline again, because a profession's current workflows were designed for human limits and old technology: Designing the Vertical System of Record is the method for deriving them instead of copying them.

Ayesha partners with her aunt, an 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

In plain words: this layer puts it all to work for one company. AI Workers are manufactured for it, and the improvement is measured and proven.

Produces: a deployment that achieves a defined and measured business outcome for one company. A working system alone is not enough.

Where the customer comes from. Everything below begins with a customer who has already agreed to a number. A reader cannot skip how that happened, because a graduate with nothing built has no way to reach it. Before there is a contract, there is a sponsor: a named person inside one real company with the authority to discuss a starting number, before anything is signed. A company is not a sponsor. A job title with no authority over the work is not a sponsor. And a sponsor who will not discuss a starting number is not a sponsor.

What earns that conversation is the System of Record, not the pitch. Choosing Your Vertical selects the profession and its beachhead. Designing the Vertical System of Record derives the first slice: one professional outcome, covered completely, with its outcome contract, its invariants, its decision map, its exceptions, its derived reflex, its checker, and its evaluation set. A System of Record with one slice is called thin, and one with many is called thick. The words count outcomes, never corners. A slice that handles only clean cases is not thin. It is unfinished.

So the vertical business has an order, and the order does not begin with a customer:

expert → thin slice → sponsor → baseline → contract of success → engagement → thicker System of Record

One arrow strictly precedes everything commercial in that line, and it is the slice. Walk into a mid-size firm carrying one governed page of its own profession, the plain words at the top, the expert's cited rules below, the checker underneath, and the buyer is not sitting through a pitch. He is reading his own work, written better than his own firm has written it, and the next question comes from his side of the table: what does this do for my four-hour file? Nobody had to create urgency. The asset created it.

Two numbers, two sources, two moments. The slice is derived from the expert's own files: real cases, including one that failed review and one that escalated. The baseline is measured in the customer's workflow, because that is the only number a buyer can verify. So the slice is built before contact and the baseline arrives after it, and there is no contradiction between them.

Two ladders, one rule each. Build first, sell second governs the vertical ladder: the trio, the domain products, and the engagements that run on them. It does not govern the service ladder. A graduate with no committed expert yet earns at Layer 1 and Layer 4 on the method System of Record alone, building governed Systems of Record from clients' own manuals and manufacturing Workers with the deployed generic tools. That work needs no vertical slice, because it sells no vertical. For most graduates it comes first, it pays, and it is often how the expert is found. The service ladder starts with a client. The vertical ladder starts with a slice.

One honest label before the mechanics. The demand data for this role is measured, and 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 sponsor, because the category is new and the shelf is still empty. Read the order above as this book's reasoning, in the same class as Becker's forecast: sound, and not yet a measurement. A graduate who builds a good slice and waits three months for a meeting has not disproved the model.

Every engagement (one paid client project) needs two fixed points:

1. An agreed starting point: both sides define the current performance and the target before work begins.
2. A proven finishing point: the team shows, with production evidence, that the target was reached.

The implementation happens between these two points. Without an agreed starting point, success is undefined. Without a proven finishing point, there is no evidence that the project delivered its promised outcome.

The start is the contract of success. Before any building begins, the graduate and the customer agree, in writing, on three things. The baseline: a real measurement of how the work performs today (for example, one working-paper file takes four hours). The target: the number that will count as success (the same file in forty minutes). The acceptance criteria: the exact conditions under which the work is done (for example, 95 percent of files correct on first pass, and the firm's own reviewers approve the output). It is a contract because both sides agree on what success means before money or code moves. The contract protects the customer from a system that works but changes nothing, and it protects the graduate from a goal that moves every week.

The finish is proof in production. Success must be demonstrated in the company's real daily work, using real data and real users, not only in a demo.

Three kinds of evidence are required:

1. Business KPI measurement: key performance indicators show whether the agreed target was reached.
2. Adoption: the people responsible for the work actually use the system. A system that is not used cannot prove a business result.
3. Agent evaluations: tests show that the system continues to behave correctly.

Evaluations show whether the agent behaves correctly. KPIs show whether the business improved. Both are needed because an agent may pass its technical evaluations without improving the business outcome.

Between start and finish, the team takes a vertical ecosystem and fits it to that company: its ontology (the map of the company's concepts and how they relate), its data, its workflows, its people. The manufacturing tool is the Layer 3 domain builder, running in Mode 2. With it, the graduate manufactures the AI Workers (Digital FTEs) the company needs and assembles them into its AI-Native Company.

The builder is shared. The same domain builder serves every company in that domain. It is updated in one place and versioned for all customers. Customer-specific information remains in the customer's Layer 4 instance and never becomes part of the shared builder.

For example, the same accountancy builder can manufacture Workers for many accounting firms. When a reusable improvement is added to the builder, future customers receive it, and existing customers can receive it through a controlled update. This is the promotion law in practice.

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. Becker calls this work the new agency; Palantir calls it forward deployment. Either way, this is where our graduates earn.

Ayesha's first slice is the working-paper outcome, derived from her aunt's own files before any customer exists: one outcome contract, the invariants her aunt would not bend, one derived reflex, one checker, and an evaluation set that includes the file which failed review. Her aunt's profession, not a cold list, produces the sponsor: a partner at a mid-size accounting firm in Chicago, served remotely from Lahore through the trio's US-jurisdiction build (the per-jurisdiction repeat from Layer 3). The baseline arrives in that conversation: four hours to prepare one working-paper file. The target: forty minutes. With the domain builder she manufactures a working-paper Digital FTE, the firm's reviewers supervise its output, and the measured result proves the target.

The ecosystem is the first proof

Notice one thing about the ecosystem: it is the model applied to itself (a recursion). Layer 2 teaches the FDE AF Model, and Layer 2 is itself built with the FDE AF Model. Its System of Record is the first deployed Layer 1 instance. Its live gateways (Zia Tutor AI and Zia Developer AI) compose the Layer 2 components. Its content was assembled the way we teach you to assemble yours.

The proof is not only the diagram. Products based on the model are already running. Open Zia Tutor AI and ask a question about this page, or connect your own agent to the System of Record. When you do, you are using Layers 0 through 2.

This design also supports future verticals. Each vertical can pair the same deployed Agent Factory SoR, which teaches the general method, with its own domain source. The first complete implementation of the model is therefore the ecosystem that teaches the model.

The one law of the model: repeated work moves down

The FDE literature carries one warning above all others, and the sharpest version comes from Kevin Bai, who led FDE engagements at Palantir and then built Rippling's FDE function as its first hire. He was asked how an FDE function survives in the enterprise when every customer receives something custom. His answer draws a hard line. If each engineer builds entirely from scratch, you do not have an FDE function. You have a dev shop. That can be a profitable business, but it is a different business, and the maintenance cost will eventually eat the profit and loss statement, assuming the engineers have not resigned first. What makes it an FDE function instead is that the engineers never write software from scratch. A set of shared primitives already exists, and the engineer assembles them into something valuable for that one customer. 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.

Promotion means moving a reusable capability into a lower, shared layer so that more people can use it.

• A Layer 4 customization used by three or more customers becomes a candidate for the Layer 3 vertical.
• A Layer 3 component that is useful in any profession becomes a candidate for the Layer 2 library.
• An infrastructure pattern needed by many components becomes a candidate for Layer 1 or Layer 0.

Repetition starts a review; it does not cause automatic promotion. A capability is promoted only when it meets all of these conditions:

1. It contains no confidential customer data.
2. It can be separated from one customer's unique process.
3. It fits the platform strategy.
4. It passes security and compliance review.
5. It includes tests and agent evaluations.
6. It has a named long-term owner.

Promotion must also answer a fair customer question: why should work I paid for become part of your shared platform? Three commitments protect the customer:

1. Clean-room promotion: only the general pattern moves into the shared layer. The customer's data and confidential ontology remain at Layer 4.
2. Opt-in promotion: the engagement contract must give permission. Promotion rights are never assumed.
3. Rewarded promotion: when a customer's work produces a reusable improvement, the customer receives an incentive, such as lower ongoing fees. The shared improvement can also reduce that customer's future maintenance cost.

Two companion rules apply the same principle at different boundaries:

• At Layer 2: a vertical does not customize the deployed generic products. It builds its own gateway from the shared components.
• At Layer 3: a customer does not receive a separate fork of the domain builder. One versioned builder serves every company in the domain.

Both rules express the same idea: a shared capability should exist once, at the correct layer. Customer-specific or profession-specific information should remain in the instance above it. Breaking either rule creates many separate versions that must be maintained forever.

The law also creates a return path. Lessons from customer work move down into the shared foundation when they are safe and reusable. Versioned improvements then move back up to the products and customer deployments that can use them. This improvement loop separates a platform that becomes stronger over time from a services business that repeatedly solves the same problem. Field work is therefore both paid delivery and a source of platform research and development.

This law is also how a graduate's own vertical System of Record grows from thin to thick. She derives new outcomes with her expert, and repeated customer work moves down into the shared vertical when it is safe and reusable. One thing that looks like growth is not: adding a jurisdiction is a new build, not a thicker one, because each jurisdiction has its own rules and its own ladders, sharing only the expert's methodology.

The base must be agent-readable

One more requirement is central to the model: the base must be easy for AI agents to understand and use. Becker predicts that successful software bases will include the context an LLM needs from the beginning. Jensen Huang, CEO of NVIDIA, makes a related enterprise argument: agents need authoritative sources they can read, update, and check. A System of Record for the Agent Era explains this requirement in more detail. Layers 0 and 1 provide that foundation.

An open-source repository by itself is not enough. Code without clear context forces an AI agent to make assumptions. A governed System of Record provides more than code. It gives the agent versioned and citable source material. MCP provides a standard way for agents to access that material, while pgvector helps them find passages by meaning.

In this design, the AI agent is treated as an important reader of the system, not as an afterthought. Prompt-based customization can work reliably and quickly at Layer 4 only when the base clearly explains its content, rules, and available tools to the agent.

Here is why this stack beats a generic boilerplate (ready-made starter code), piece by piece:

• Versioned Markdown with stable identifiers keeps passages predictable. The system splits the text in the same way each time, so a citation can still point to the correct passage after an update. The same Markdown also publishes as a website, allowing one source to serve both people and agents.
• MCP gives the agent defined tools to call instead of forcing it to scrape a website. Because the tools have clear inputs and outputs, their behavior can be tested.
• Better Auth, with JWKS verification at every boundary, confirms who is making each tool call and whether that caller has permission. This makes the activity auditable and more suitable for regulated customers.
• The vector index and governed corpus use the same Postgres system. Retrieval therefore follows the same version and approval status as the source content. An agent cannot retrieve a paragraph that governance 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 give the model a clean commercial map, and it reads best as two maps in one: what the platform earns, and where a graduate earns.

The platform layers belong to Panaversity. Layers 0 and 1 are owned and operated as the ecosystem's foundation, and their revenue is the platform's. Layer 1 earns through Systems of Record as a service. A company that wants its own governed source (its policy manual, its product catalog, its procedures) gets a hosted instance of the kernel, or runs its own with support.

Layer 2 education also earns revenue for the platform. It can reach hundreds of thousands of learners with very low LLM inference cost because connector-native apps let users bring their own AI model subscriptions. The platform still pays for storage, embeddings, authentication, and operations. However, it does not pay the main LLM usage bill for every learner, which removes a common limit on scale.

The graduate's earning starts at Layer 1 and climbs.

At Layer 1, a graduate builds a customized content System of Record for a client. The graduate loads the client's domain content (its manuals, standards, procedures) into the kernel, sets up the governance, and charges for the build and the upkeep. The kernel stays Panaversity's; the service and the fee are the graduate's.

One clarification, because the ladder can be misread as sell-first. A graduate's own first governed build is usually not for a client at all. It is the thin slice of her own vertical, derived with her expert and paid for by nobody, and it is what makes the Layer 4 conversation possible in the first place. Client builds at this rung earn money on the service ladder. The unpaid slice opens the vertical one.

At Layer 2, a graduate uses Zia Developer AI, in Mode 2, to manufacture AI Workers and AI-native solutions for clients. The generic tools are deployed and free to use, and the client pays for the outcome.

At Layer 3, the graduate builds their own domain startup. Partner with a domain expert, launch the vertical, and earn three ways:

1. The partnership. The expert licenses their approved persona and their rights-cleared authored material (rights-cleared: material they own or have written permission to license) to the startup. The startup sells the expert twin built on that license and shares the revenue with the expert. The license is the input; the twin's subscriptions are the income.
2. Domain education. The domain SoR carries that domain's crash courses, so the same asset that powers the expert twin also teaches the profession.
3. Domain products. With the domain builder, the startup manufactures ready-made, domain-specific AI Workers (Digital FTEs), and even complete AI-Native Company blueprints, and sells them to many companies in the domain: built once, sold many times.

A customer who needs a Worker fitted to its own data and workflows moves to Layer 4, so products and engagements feed each other. (A domain corpus often also contains laws, standards, and third-party publications the expert does not own: those enter under their own licenses.)

At Layer 4, the startup runs FDE engagements: discovery and outcome design, deployment, and recurring revenue through managed operation, governance, and continuous improvement. The recurring fee has real substance. The domain builder is shared and versioned, so every customer receives the domain's improvements as updates. The retainer (the ongoing monthly fee) buys Workers that keep getting better, not just Workers that keep running.

What to charge, and on what basis

The layers above say where a graduate earns. They do not say what to charge, and that question has a better answer in 2026 than it had in 2024, because the market has arrived at three artifacts this model already required.

The market named our unit of sale. Pricing frameworks for agents now include an agent-based model, which prices an agent as a replacement for a full-time employee rather than as software. That is the Digital FTE, measured like a hire. This book did not follow that convention. It was early to it.

The market named our contract. Outcome-based pricing charges for a result rather than for activity: a customer-service vendor prices its agent at about one dollar per resolved conversation, another charges around one dollar fifty per automated resolution on committed volume, and one of the larger customer-experience companies built its whole business model on the approach. Notice what that pricing model needs before it can exist. It needs an agreed starting number, a target, and acceptance criteria a reviewer can check. That is the contract of success, which this model has always made mandatory. The contract is not paperwork you complete in order to start work. It is the instrument that lets you charge for a result at all.

The market named our structure. Hybrid pricing, a base fee with a variable component on top, is now the most common arrangement and is still growing, while seat-based pricing keeps falling. Firms using hybrid report materially better revenue growth and net revenue retention than pure-subscription firms. At Layer 4 that is exactly the engagement plus the retainer.

And the premium has a twenty-year proof. Selling an outcome instead of a seat is not only a 2026 pricing trend. Kevin Bai gives the older measure. Among public SaaS companies serving the Fortune 500, ranked by average contract value, meaning what a single customer spends with a single vendor, he 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. Read that beside the headcount he notes in the same breath: a few thousand people. The discipline that makes outcome pricing possible is what let one vendor charge several times the going rate for two decades. Treat the figures as one practitioner's recollection rather than an audited table, and treat the direction as the durable point.

So the graduate's price list has three planks, and each one follows from a rung above.

What you sell	Priced against	Where it sits
The engagement	The contract of success: baseline, target, acceptance criteria	Layer 4
The managed operation	The Workers you run and the improvements they receive	Layer 4 retainer
Ready-made Workers and blueprints	Built once, sold to many companies in the domain	Layer 3 products

Two cautions, because outcome pricing is not free money.

It moves risk onto you. If you charge for a result, you carry the cost of a Worker that fails to produce it. That is affordable only when the checker is real and the evaluation set covers the awkward cases, which is why the definition of done comes before the price rather than after it. A graduate who prices an outcome before proving one has sold a promise.

It rewards the wrong behaviour unless the guardrails hold. Every main number can be produced dishonestly. A close can be accelerated by carrying differences forward. A pipeline can be filled with deals that are not real. The guardrails in the contract of success are what stop your own pricing model from paying you to damage the customer.

One last note on direction. Analyst forecasts now put a large share of enterprise AI deployment as vertical-first rather than horizontal, and the named leaders in support, legal, healthcare, and personal-injury law all combine deep domain knowledge with outcome-aligned pricing. Read that as confirmation of the shape rather than as a promise about your own numbers: the same period's surveys still find most companies unable to show measurable value from AI, which is the gap Layer 4 exists to close. Pricing data in this subsection was last verified in July 2026, and the durable point is the three artifacts rather than any published rate.

This is why the model gives graduates a step-by-step earning path. You do not have to wait until you can build a complete company. Start at Layer 1 or Layer 2 by building Systems of Record for clients or manufacturing solutions with the deployed tools. Move to Layer 3 when you have chosen a domain and found a committed expert. You can then sell ready-made Workers as products. At Layer 4, you earn from customer-specific deployments through the vertical you own. The higher you climb, the more of the business you own.

(Graduates can also contribute components to the platform under contribution agreements, which define ownership, licensing, quality requirements, support obligations, and revenue sharing. That path builds reputation and the ecosystem, but the money is in the layers above.) PIAIC (the Presidential Initiative for Artificial Intelligence and Computing) trains the FDEs, Panaversity runs the platform beneath them, the verticals give them the domain, and Layers 1 through 4 are where they earn.

The model must also answer a fair question from graduates: my startup depends on a kernel owned by Panaversity, so what protects me if the platform's terms change or the platform fails?

There are two answers. The first is structural portability. The graduate's assets are not locked into a private technical format. The corpus uses plain, versioned Markdown. Retrieval uses standard Postgres with pgvector. Content is served through the open MCP protocol. The vertical's main assets (the corpus, the expert's license, and customer relationships) belong to the partnership and are designed to be portable. The same answer covers the method System of Record a graduate carries into every client: it is not hers, and it does not need to be, because nothing in it is stored in a format only one platform can read.

Contractually, a vertical's platform terms are set in its partnership agreement before the vertical launches, the same way promotion rights are set in the engagement contract at Layer 4. The terms are agreed up front, and they are not changed underneath a running business.

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)	Panaversity, which runs the platform; contributed components per their contribution agreements
Vertical corpus and expert twin (Layer 3)	The graduate's domain startup, jointly with the expert: her rights-cleared material under license, third-party sources under their own licenses
A customer's own SoR corpus (a Layer 1 instance)	The customer's content stays the customer's; the kernel stays Panaversity's
The domain builder (one per domain, versioned)	The vertical that maintains it: shared by all its customers, never forked per customer
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 useful model must state where it does not apply. Not everything should be promoted into a shared layer. Work that is specific to one jurisdiction, restricted by contract, or tied to one customer's unusual process should remain at Layer 4. Moving such work into the shared platform would make the platform harder to manage and less reliable. Repetition at two customers is only a signal to watch. The normal trigger for a promotion review is use by three or more customers together with a clear 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. Without the expert there is also no thin slice to build, because the reflexes are authored in the expert's voice and derived from the expert's own files. So until an expert commits, serve that domain through Layer 1 and Layer 4 engagements instead: that is the service ladder, it pays, and it is often how the expert is found. How to find the vertical that passes this rule, and the tests every candidate must survive first, is its own discipline: Choosing Your Vertical. And the model assumes a stable base: while the foundation is still in beta, every vertical multiplies its bugs. That 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 the foundations to building Digital FTEs, one layer at a time. To understand which role you could play in this model, read the roles this book trains. When you are ready to build on the foundation itself, connect your agent to the System of Record. The model shows the destination and structure; the courses show the steps for getting there.

Flashcards Study Aid

Test Your Understanding

Checking access...

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 prediction, not as evidence. facebook.com
• AI Futures Project (Larsen, Dean, Halstead, Lifland, Greenblatt, Kokotajlo), "AI 2040: Plan A," 2026. Cited for its labor-market forecast (two workforces; profession-by-profession automation), not for its governance program. ai-2040.com
• SaaS Mag, "How SaaS Companies Are Monetizing AI Agents," April 2026. Source for the usage, outcome, and hybrid pricing split, hybrid adoption rates, and the Agentforce revenue figure. saasmag.com
• Pickaxe, "AI Agent Pricing Models Explained," April 2026. Source for the per-resolution rates, the hybrid growth and retention comparison, and the decline of seat-based pricing. pickaxe.co
• Nevermined, "How to Monetize AI Agents in 2026," May 2026. Source for the four-model framework, including agent-based pricing as full-time-employee replacement. nevermined.ai
• ACTGSYS, "Vertical AI Agents 2026: Why Industry-Specific Agents Are Eating SaaS," May 2026. Source for the vertical-first deployment forecast and the named vertical leaders. Cited as an industry survey, not as a measurement of our own model. actgsys.com
• Kevin Bai (Anthropic Applied AI; ex-Palantir; founding FDE at Rippling), "Forward Deployed Engineering 101," AI Engineer World's Fair, Forward Deployed Engineering track, June to July 2026. Source for the dev shop warning, the platform test, and the average contract value comparison. Cited as one practitioner's account with figures recalled on stage, not as an audited measurement. youtube.com/watch?v=KwhgfwOSToQ