What Tools Do Forward-Deployed Engineers Use? An Ontology-First Open Stack

The short version: forward-deployed engineering is the fastest-growing role in enterprise AI — job postings up 1,165% year over year by Live Data Technologies’ count, relayed by the recruiting marketplace Paraform — and in 2026 OpenAI, Anthropic, AWS and Microsoft each stood up a forward-deployed organisation of their own. The playbook all of them are copying is Palantir’s ontology-first method. This article is about the two things the recruiting content never covers: what an FDE actually builds across a 60–180 day deployment, and why the copycat wave copied the role but not the substrate underneath it. In between are the five recurring pains of doing this work on a hand-built stack — plumbing eats the engagement, demos die in security review, requirements change faster than code, patterns never compound across clients, the handover poisons the relationship — and how an open, ontology-first stack removes each one. It ends on the question we think defines the next wave of this role: the ontology handover. Does the client’s ontology leave the engagement as typed, open files in their repo, or as renewal leverage in someone else’s platform?

The job nobody describes honestly

The job postings talk about “0→1 ambiguity” and $300K–$550K comp bands (Perspective AI, TechTarget). Several of those postings are pre-sales roles that were renamed in 2026 because the new title recruits better, so it is worth knowing what separates an FDE from a solutions engineer, a solutions architect and a consultant before reading five pains into a job you would not actually be doing. The actual job is making AI work inside someone else’s walls: their data, their permissions, their compliance office, their definition of “good enough.” Palantir codified the method years ago — their AI FDEs front-load a customer-specific ontology before shipping any LLM application and spend 30–40% of the week on discovery (Palantir’s AI FDE guidance). The method is right. The tooling underneath it is where the week actually goes.

What a forward deployed engineer actually builds

A deployment runs roughly 60–180 days and produces four artifacts before the handover, in a fixed order, because each one is the input to the next. This is the part the job postings never describe:

Deployment day	What actually gets written	Done when
0–15 · Ingestion adapters	One adapter per source system — their ERP, their ticketing tool, the spreadsheet that is secretly the source of truth. Read paths first: connect, don’t migrate.	A business object on screen shows a real row that came out of their system this morning.
15–45 · Entity resolution	The unglamorous half nobody demos. “Customer” is four different keys in four systems: you write the match rules, the survivorship rules, and the identifier the ontology treats as canonical.	Two records that are the same company merge — and their ops lead agrees they should have.
30–60 · Permission mapping	Their org chart translated into roles, permission sets, row-level sharing and field-level rules, including the fields only three people may ever see.	Security review is a file read instead of a meeting: a reviewer can point at who can see what.
45–90 · The first workflows	Two or three processes end to end — an approval chain, a triage queue, a renewal — with the actions, views and notifications around them.	Someone who does not work for you finishes a real day’s work in the app.
90–180 · Handover	Seed data, acceptance fixtures, translated labels, the packaged app, and a review checklist their team can actually run.	Their own engineers ship a change without calling you.

Note what the first four rows have in common: none of them is application code in the usual sense. They are definitions — of what exists, of what counts as the same thing, of who may do what, of how work moves. On a hand-built stack each one is nevertheless expressed as code, which is exactly why the pains below bite.

Deployment number two is where the model pays or fails. Nothing in that table is as client-specific as it feels while you are doing it. Entity resolution for “customer” is structurally the same problem at the next client with different keys; an approval chain is the same shape with different thresholds and a different approver role. So the second engagement has one number worth measuring — call it the rename ratio: the share of deployment two that is a rename of typed definitions you already own, versus a rewrite. In a hand-built codebase the rename ratio is close to zero and nobody notices, because deployment two still ships; it just costs what deployment one cost. In typed metadata it is countable, because the surface is finite: a HotCRM-shaped engagement is 15 objects, 17 flows, 10 actions, 6 permission profiles and 5 sharing rules. You can literally list what the next client inherits.

That is the job. The rest of this article is the five recurring pains that make each row of that table harder than it should be — and what removes them.

Pain 1 — Week one is always plumbing

Every engagement starts the same way: before you can show a single business object on a screen, you need auth, SSO, roles, CRUD APIs, an admin UI, file storage, and an audit table. None of it is why the client hired you. Your differentiator — the 30–40% of time spent understanding their business — gets squeezed by the 60% spent rebuilding the same undifferentiated substrate you built for the last client.

What the stack changes: the substrate is already there. One command scaffolds a project where the Console, sign-in and SSO, role/row/field-level permissions, audit logging, REST APIs, and an MCP server are running before lunch:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # Console at :3000 — auth, RBAC, audit already enforced

Everything derivable is derived by the runtime. The only thing left to author is the thing only you can author: the client’s objects, flows, and permission rules. Week one becomes discovery and modeling — the work you’re actually differentiated at.

Pain 2 — The demo that dies in security review

You know this arc. Friday of week one: a glued-together demo — a vibe-coded UI over a copied CSV — and the room applauds. Month two: infosec walks in with three questions. What exactly can the AI see? Whose permissions apply when it acts? Where is the audit record? For a demo stack, the honest answer is a rebuild, and the rebuild is where engagements go to die.

What the stack changes: governance is the substrate, not a retrofit. The validation gate won’t even accept an object without a declared sharing model:

export const Ticket = ObjectSchema.create({
  name: 'support_ticket',
  label: 'Ticket',
  sharingModel: 'private',        // required — the gate rejects an object without one
  fields: {
    subject:  Field.text({ label: 'Subject', required: true }),
    status:   Field.select({ label: 'Status', options: [/* the client's real states */] }),
    approver: Field.lookup('sys_user'),
  },
});

At runtime, every call — human UI, REST, or an AI agent over MCP — passes the same RBAC, row-level and field-level security, and lands in the same audit log. When infosec asks “what can the AI see?”, the answer is a file they can read: the permission metadata, enforced by the runtime, not promised by a slide. Your Friday demo and your production deployment are the same artifact. There is no rebuild, because there was never a governance-free version.

Pain 3 — Requirements change faster than code

Mid-meeting, the ops lead says: “actually, discounts above 20% go through regional managers first.” In a hand-built codebase that’s a schema migration, three API changes, a UI change, and a week — and in the client’s eyes, you got slower the moment they got specific. Forward-deployed work lives or dies on iteration speed in the room.

What the stack changes: the whole application is compact typed metadata. The bundled CRM reference is 1,792 lines, roughly 16k tokens (count it: find examples/app-crm/src -name '*.ts' | xargs cat | wc -l); the complete HotCRM stays under 150k tokens overall — business logic under 100k, with roughly 50k more for UI. At either scale, your coding agent holds the entire system in context: the approval-chain change is one coherent diff across flow, permissions, and UI, written while the meeting is still going, validated by os validate, previewed live in the Console. “What breaks if we change this?” is a question the agent can actually answer, because it can see everything. Requirement changes stop being a threat to the timeline and become the demo.

Pain 4 — Your patterns never compound

Client A’s approval-chain code can’t be lifted into client B’s codebase — different framework versions, different auth, different everything. So every engagement starts at zero, and a three-person boutique can never build the leverage that makes Palantir’s model economics work. This is the quiet reason forward-deployed consultancies stay small.

What the stack changes: patterns are typed metadata, and typed metadata is portable. The approval chain you modeled for client A is a flow definition you drop into client B’s repo and rename. Over engagements you accumulate a house library — objects, flows, permission sets, seed data — that your agent applies to the next client in minutes. And you don’t start the library from zero either: HotCRM is a complete, forkable reference — 15 objects, 17 flows, 4 dashboards, 2 AI copilots, 4 languages — built as the canonical example of the conventions. Fork, rename the namespace, and your engagement starts from a working system instead of a blank repo.

Pain 5 — The handover poisons the relationship

Every engagement ends, and today it ends badly in one of two ways. Hand over a platform, and the client rents their own ontology back forever — you’ve become a sales channel, and they’ve learned to fear successful pilots, because the better the ontology, the deeper the lock-in. Hand over a bespoke codebase, and their team can’t maintain it; it rots, and eighteen months later your name is on the rot.

What the stack changes: this is the ontology handover — the ending the FDE playbook never solved. What you hand over is the client’s repo: typed objects, flows, and permissions under Apache-2.0, plus the compiled artifact and a review checklist. Their security team can inspect the whole definition — the bundled reference is 16k tokens, and even the complete HotCRM is under 150k, not 300k lines. Their own coding agents maintain it with the same loop you used, because the format was built to be agent-writable. If they want the platform operated — browser AI Builder, cloud or self-managed — that’s ObjectOS, and it runs the same open definition; they can leave it without losing the ontology. Your next contract is earned by new work, not extracted by lock-in. That difference is your reputation, compounding.

The FDE’s complete metadata toolkit

The ontology is not just the data model. A forward-deployed engagement uses a metadata type for every phase, from discovery to handover — and all of them are the same kind of typed, validated, portable definition:

Engagement phase	The client question you answer	Metadata types you use
1 · Model the nouns	”What exists in our business?”	Objects & fields (relations, validation rules, formulas) · datasources (connect existing databases, no migration) · seed data (for demos and acceptance)
2 · Model the verbs	”How does work actually flow?”	Flows (approval chains, state machines, record triggers, schedules) · approvals (multi-step, queues, record locking) · actions (permission-checked buttons and server operations)
3 · Screens for people	”Where do our people work?”	Apps & navigation · views (list / kanban / calendar / gantt) · pages & forms · dashboards & reports (the KPIs executives ask for)
4 · Pass security review	”Who can see and do what?”	Permission sets & roles (RBAC) · row- and field-level security · sharing rules · audit (built into the runtime — declared, delivered)
5 · The AI they actually want	”What can AI do for us?”	AI agents (sales / service copilots) · AI tools & skills · MCP exposure (`ai: { exposed: true }`)
6 · Handover & compounding	”What happens after you leave?”	Translations (multi-language labels for global clients) · app manifest & packaging (compile to one `objectstack.json`, install into any environment)

The point is that all six layers are the same substance. An approval chain is typed metadata exactly like the data model, and so is an AI agent — the same validation gate checks them, the same diff reviews them, the same repo hands them over:

// The client's verbs: a discount approval — typed metadata, same as an object
export const DiscountApproval: Flow = {
  name: 'discount_approval',
  label: 'Discount Approval',
  type: 'record_change',
  status: 'active',
  nodes: [
    { id: 'start', type: 'start', label: 'Start',
      config: { objectName: 'crm_quote', triggerType: 'record-after-update',
                condition: 'record.discount > 0.20' } },
    { id: 'review', type: 'approval', label: 'Regional Manager Review',
      config: { approvers: [{ type: 'position', value: 'regional_manager' }], lockRecord: true } },
    { id: 'end', type: 'end', label: 'End' },
  ],
  edges: [/* start -> review -> end */],
};

// The AI the client actually wants: a service copilot — still metadata
export const ServiceCopilot = defineAgent({
  name: 'service_copilot',
  label: 'Service Copilot',
  instructions: 'Help support reps triage and resolve cases. Retrieve only within the user\'s permissions. Always cite case IDs.',
  skills: ['case_triage', 'customer_360'],
  knowledge: { topics: ['support_kb', 'sla_policies'] },
});

HotCRM is the full demonstration of this vocabulary in use: 15 objects, 17 flows, 10 actions, 4 dashboards, 2 AI copilots, 6 skills, 6 permission profiles, 5 sharing rules, and 4 languages — every layer present, under 150k tokens in total: business logic under 100k, with roughly 50k more for UI. The whole thing fits in a single agent context window.

The 2026 copycat wave copied the role, not the substrate

Within a single year the industry decided this is how enterprise AI gets delivered. Each of these is a dated commitment from the company that made it, which is what makes it worth quoting at all:

2026	The commitment	Announced by
May	OpenAI launched a majority-owned deployment company with over $4B committed, acquiring the consultancy Tomoro and roughly 150 forward-deployed engineers with it	OpenAI
11 June	Anthropic and DXC announced a multi-year alliance to train tens of thousands of Claude-certified forward-deployed engineers, working inside the systems DXC already runs for banks, airlines and insurers	Anthropic
30 June	AWS committed $1B to a forward-deployed engineering unit, embedding pods of five or six engineers at a time inside customers	CNBC
2 July	Microsoft stood up Frontier — $2.5B and 6,000 employees — to do the same work	CNBC

Two other numbers circulate with this wave and deserve their provenance stated rather than repeated. The +1,165% year-over-year growth in FDE job postings is Live Data Technologies’ count, relayed by Paraform — a recruiting marketplace whose business is FDE hiring — and it counts postings, not filled roles. Salesforce’s “team of 1,000 FDEs” comes from Salesforce’s own blog: a statement of intent, not a headcount disclosure. Both are directionally real and neither is audited.

Now the part that matters for anyone doing the work. Every commitment in that table is denominated in engineers and dollars. Not one of them is denominated in the thing that decides whether deployment two costs less than deployment one: what the engineer’s output gets written into. Palantir’s method works because the FDE writes into a customer-specific ontology and the application is derived from it — the substrate is the product, and the engineers are how it reaches a customer. Hire the identical person into an organisation with no substrate and the work still looks the same from outside for about a year.

So the useful question to ask any forward-deployed organisation — the one you are joining, buying from, or building — is not how many engineers it has. It is three questions about the substrate:

When the engineer rolls off, which file did the work land in? A ticket, a notebook and a bespoke service are not an answer; a typed definition in the customer’s repository is.
Can the customer read it without you? If the definition is only legible inside a vendor console, the customer is renting their own ontology back, and the better your work the deeper that goes.
What did deployment two inherit from deployment one? Ask for the list. If nobody can produce one, the rename ratio is zero.

This article’s answer to all three is the same, and it is why the ontology-first framing runs through everything above: the artifact is an open business ontology — typed objects, flows and permissions in the client’s own repository under Apache-2.0 — which the client can read, keep, and hand to their own coding agents. Copying the role is a hiring plan and takes a quarter. Copying the substrate means making it open enough that a customer would keep it, and that is a product decision almost nobody in the 2026 wave has made.

The business-side version of this argument — revenue per employee, blended gross margin, and how a product company drifts into consultancy economics without ever deciding to — is the companion piece: why copying Palantir builds a consultancy.

What this stack does not fix

Steelmanning the alternatives: Foundry-scale data federation and analytics pipelines are Palantir’s home turf — if the engagement is about fusing petabytes across forty legacy systems, that’s a different tool class. Organizational change management — getting people to actually use the thing — no stack fixes. And a client already standardized on a closed platform may rationally stay. The claim is narrower: for the application layer of forward-deployed work — modeling a business and shipping governed apps on it — the five pains above are now removable, and the ontology can be handed over instead of held hostage.

The FDE checklist

Model the client’s nouns and verbs as objects and flows before any UI conversation.
Keep the whole definition context-sized so your agent can reason about and refactor it whole.
Default permissions conservative; make every authority change explicit in the diff.
Hand over the repo, the compiled artifact, and a review checklist — not a login to your tenant.
Leave MCP enabled so the client’s own AI operates the app under their permissions.
At deployment two, count the rename ratio. If nothing carried over, the problem is the substrate, not the engagement.

Try the loop

Point your coding agent at the open stack — the scaffold ships with AGENTS.md and the skills bundle, so the agent starts with the format’s rules loaded:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # the app, running — model the first object with your agent

For clients who want the platform operated, ObjectOS is the commercial production platform on ObjectStack — build & ask online, with managed or private deployment and governance included.

Companion piece, written for the founder rather than the engineer: The forward deployed engineer model — why copying Palantir builds a consultancy — the margin math behind an FDE org, and three tests for whether yours is compounding or billing.