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: AI Tutor to learn with, AI Developer 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. AI Tutor teaches from that knowledge, and AI Developer 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.

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.

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.

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 AI Tutor and build with AI Developer.

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: AI Tutor for teaching and AI Developer for development.

One boundary rule is important: these two products remain generic. A profession-specific vertical does not modify AI Tutor or AI Developer. 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, AI Tutor answered her questions, and AI Developer 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 AI Tutor pattern, composed from the same Layer 2 components, with that domain's expert teaching in their voice.
3. The domain builder: a gateway in the AI Developer 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.

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

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.

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 engagement is 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: 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 (AI Tutor and AI Developer) 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 AI Tutor 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: without discipline, per-customer work multiplies into a thousand separate custom versions 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.

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.

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.

At Layer 2, a graduate uses AI Developer, 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.

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.

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 domain partnership: the expert's 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. So until an expert commits, serve that domain through Layer 4 engagements instead. 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.

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

Continue to Preface: Why now, what's at stake →