What separates a high-margin platform company from an expensive, low-margin consulting shop is not sales — it's architecture. Structure the platform as primitives — generic infrastructure abstracted once, centrally — and the engineers embedded with customers spend their time on domain logic, not plumbing. Then run a harvest pipeline that promotes repeated bespoke work back into the platform, and every client engagement compounds into product. This is the operating model behind the forward-deployed engineer, in the lineage Palantir documented — with the honest read on when it's premature.
Every customer deployment needs storage, auth, state management, UI rendering, data connectors, and model routing — and none of those is what the customer is paying for. The platform-primitives pattern centralises all of that generic infrastructure into a shared engine, so that field engineers — the FDEs embedded with customers — spend as close to all of their time as possible stitching together business logic and domain workflows. The goal is a division of labour: the platform team owns everything that repeats; the field owns everything that's specific.
Lineage, named honestly. This is the operating model Palantir made famous and documents publicly — the vocabulary below ("ontology," entity registries, forward deployment) is Foundry's. It's also visible in every mature platform ecosystem: Salesforce and ServiceNow partner delivery, and — already on this tree — Frappe's doctypes, where declaring one metadata object yields a table, form, REST surface, and permissions for free. That is a Layer-2 composable primitive in production, and it's the cheapest way to feel the pattern before building your own.
Unlike most of the tree, this leaf is opinionated operating method, not a sourced survey: the pattern's lineage is documented (Palantir, Frappe), but the harvest thresholds and DX rules below are house practice — positions we hold from delivery, stated so you can disagree with them precisely.
The architecture is an ownership diagram as much as a technical one. Stability comes from the boundary rules: the field never touches the foundation, and the platform team never blocks the sandbox.
+-------------------------------------------------------------------+ | 3. EXTENSION LAYER (FDE sandbox — field-owned) | | custom UI layouts · domain schemas · custom agent tools | +-------------------------------------------------------------------+ | 2. COMPOSABLE PRIMITIVES (shared engine — co-owned) | | ontology / entity registry · workflow & DAG orchestrator | | agent & tooling SDKs · headless UI components | +-------------------------------------------------------------------+ | 1. FOUNDATION (core infrastructure — platform-owned, non-negotiable) | | multi-tenant auth & RBAC · data ingestion & connectors | | audit & telemetry · model gateway & guardrails | +-------------------------------------------------------------------+
Connectors (SAP, Postgres, Salesforce, S3) with retry and schema conversion built in; multi-tenant RBAC, row-level security, immutable audit; a model gateway that owns LLM routing, token budgets, prompt caching, and safety guardrails. One implementation, every client.
The ontology that turns raw tables into business objects (Customer, Claim, SupplyChainNode); state machines and DAG runners for long-running and human-in-the-loop work; standard interfaces for tool calling and retrieval; JSON-driven forms, tables, and chat UIs.
FDEs build only inside predefined extension interfaces — plugins, hooks, custom actions: transformation scripts, system prompts, specialised views, bespoke integrations. Freedom inside a fence the platform can support.
The margin argument lives in the boundaries. If field engineers can modify the foundation, every deployment forks the platform and you are a consulting shop with extra steps. If the sandbox is too small, the field routes around it and the same thing happens informally. The three-layer split works only when Layer 1 is genuinely closed, Layer 3 is genuinely open, and Layer 2 is where the two negotiate.
Without a strict process for pulling field code back into the platform, the codebase fragments into per-client forks and the margin never materialises. The pipeline is the mechanism — and it's the whole business model in four steps.
[Client A request] ──> FDE builds a Layer-3 plugin
│
same pattern needed by a 2nd client?
│ yes
▼
[Harvest ticket] ──> core team refactors it into a
Layer-2 primitive (clean API + tests)
│
▼
[Platform release] ──> original FDE swaps custom code
for the native primitive
The trigger discipline matters more than the ceremony: one client is bespoke; two clients is a product signal. When a second team starts building a similar pattern, a harvest ticket is raised, core engineering generalises it, and — the step most shops skip — the original team deprecates its custom version in favour of the primitive. Every completed harvest moves revenue from billed hours to owned platform, which is the margin story told as an engineering process: the platform is the asset your client work keeps building, instead of the cost your client work keeps forking.
dev start --client=acme). If an FDE needs a platform engineer to start working, the platform has failed its first test.The pattern compounds beautifully — and it is also the most common way small delivery shops burn a year building product nobody asked for. The discipline cuts both ways: harvest late is fragmentation, harvest early is speculation.
The margin problem is sharper here. An SA delivery shop bills hours in rand while its tooling costs run in dollars — the squeeze the ownership series describes. The harvest pipeline is the practical ladder out: you don't bet the company on a product; you let paid client work surface the product one primitive at a time, funded by engagements that were profitable anyway. The platform becomes the IP you own in a cost base you otherwise rent.
The foundation layer is also the compliance layer. For POPIA-scoped delivery, centralising auth, RBAC, immutable audit, and data residency in Layer 1 means the compliance surface is built once and inherited by every client deployment — instead of re-argued per project. The model gateway does the same for AI governance: one place where routing, budgets, and guardrails are enforced, whichever model a client engagement uses. For a small team serving regulated SA clients, that centralisation is the difference between compliance as an asset and compliance as a recurring cost.
A method leaf cites its lineage rather than a literature: the pattern as Palantir documents it, and the primitive system you can try this week. Last reviewed 2026-08-06.