For forward-deployed engineers
Ship like the best FDE teams. Hand over what they never do: the ontology.
The forward-deployed model won: embed with the client, model their business, deliver working software fast. Its weak point is the handover — the ontology stays locked in a platform the client rents forever. ObjectStack makes the ontology typed, open files in the client’s repo; ObjectOS runs them governed, in our cloud or theirs.
- 16k tokens
- A complete CRM — small enough for the client to review whole
- Ontology-first
- Model nouns and verbs before any screen is built
- Client-owned
- The definition lives in their repo, Apache-2.0
The deliverable
The handover is the product: an ontology in the client’s repo
A forward-deployed engagement ends. What remains decides what it was worth: typed objects, permissions, and flows that the client’s own team — and their AI agents — can read, run, and keep changing without you.
client-repo/
├── objectstack.config.ts # the app manifest
├── src/objects/ # the client's nouns — typed, validated
├── src/flows/ # the client's verbs — approvals, automation
├── src/permissions/ # who may see and do what
└── dist/objectstack.json # one artifact, runs on any ObjectStack runtime The playbook
Ontology-first, like the model that proved it
The FDE method that works front-loads the business ontology before any AI application ships — generic models give generic answers; value lives in the client’s nouns and verbs.
1. Discover
Embed with the operators. Capture the objects, relationships, permissions, and approval paths that actually run the business.
2. Model
Turn discovery into typed metadata with your coding agent — objects, flows, permissions as compact, validated definitions.
3. Ship
The runtime derives the database, REST APIs, admin Console, and MCP tools from the definition. Demo on real workflows the same week.
4. Govern and leave
Permissions, approvals, and audit are enforced by the runtime — the system stays inside its fence after you roll off.
Why open
The client keeps the ontology. You keep the client.
An open definition changes the economics of forward-deployed work: nothing about the engagement depends on reselling a platform seat.
No seat to sell
The framework is Apache-2.0. Your bid is your engineering, not a license markup the client resents later.
Security review reads the diff
Permissions and audit are metadata. The client’s security team reviews 2,000 readable lines, not a black-box platform boundary.
Any AI, under governance
The app is an MCP server out of the box — the client’s Claude, Cursor, or local models operate it inside user permissions.
Patterns compound
Every engagement leaves you reusable, typed patterns — objects, flows, permission sets — that your agent applies to the next client.
Decision surface
What changes, who reviews it, what runs
| Engagement concern | Closed platform (e.g. Foundry) | ObjectStack / ObjectOS |
|---|---|---|
| Where the ontology lives | Inside the vendor’s platform | Typed files in the client’s repo (Apache-2.0) |
| What the client pays for | Platform seats, indefinitely | Operations (ObjectOS) — or self-host at no license cost |
| Who maintains it later | Vendor-trained specialists | Any coding agent plus a human reviewer |
| AI access | Platform-native assistants only | Open MCP — Claude, Cursor, local models |
| Security review | Trust the platform boundary | Read the diff — permissions and audit are metadata |
Review checklist
FDE engagement 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 can operate the app under their permissions.
FAQ
Questions this page should answer
Is this a Palantir Foundry replacement?
For the ontology-first application workflow — modeling a business and shipping governed apps on it — the overlap is real, and the definition layer here is open instead of proprietary. Foundry remains stronger for massive-scale data federation and analytics pipelines; many clients need only the application layer.
Do I need ObjectOS to serve clients?
No. The open-source ObjectStack runtime self-hosts with no license, Console and governance included. ObjectOS is the commercial platform for clients who want it operated — the browser-based AI Builder, cloud or Enterprise deployment, and support.
Next pages