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 — hiring up roughly 1,000% year over year, OpenAI committing $4B to a dedicated deployment company. The playbook that works is Palantir’s ontology-first method. But ask a working FDE about their actual week and you hear five recurring pains: plumbing eats the engagement, demos die in security review, requirements change faster than code, patterns never compound across clients, and the handover poisons the relationship. This article goes through all five, concretely, and shows how an open, ontology-first stack removes each one — ending with 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). 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. Five pains, one by one.

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 — a complete CRM is 1,792 lines, roughly 16k tokens (count it: find examples/app-crm/src -name '*.ts' | xargs cat | wc -l). That means 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 already read every line — it’s 16k tokens, 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, roughly 170k tokens, and the whole thing still fits in a single agent context window.

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

1. Model the client’s nouns and verbs as objects and flows before any UI conversation.
2. Keep the whole definition context-sized so your agent can reason about and refactor it whole.
3. Default permissions conservative; make every authority change explicit in the diff.
4. Hand over the repo, the compiled artifact, and a review checklist — not a login to your tenant.
5. Leave MCP enabled so the client’s own AI operates the app under their permissions.

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 runtime on the same open definition — build & ask online, governance included.