Welche Tools nutzen Forward-Deployed Engineers? Ein Ontologie-first Open Stack

Kurzfassung: Forward-Deployed Engineering ist die am schnellsten wachsende Rolle in Enterprise AI — Hiring rund 1.000 % im Jahresvergleich, OpenAI mit 4 Mrd. $ für eine eigene Deployment-Gesellschaft. Das funktionierende Playbook ist Palantirs Ontologie-first-Methode. Aber fragen Sie einen praktizierenden FDE nach seiner tatsächlichen Woche, und Sie hören fünf wiederkehrende Schmerzen: Klempnerei frisst das Engagement, Demos sterben im Security-Review, Anforderungen ändern sich schneller als Code, Muster verzinsen sich nie über Kunden hinweg, und die Übergabe vergiftet die Beziehung. Dieser Artikel geht alle fünf konkret durch und zeigt, wie ein offener, Ontologie-first Stack jeden einzelnen beseitigt — und endet mit der Frage, die aus unserer Sicht die nächste Welle dieser Rolle definiert: die Ontologie-Übergabe. Verlässt die Ontologie des Kunden das Engagement als typisierte, offene Dateien in seinem Repo — oder als Verlängerungshebel in der Plattform eines anderen?

Der Job, den niemand ehrlich beschreibt

Die Stellenanzeigen sprechen von „0→1-Ambiguität” und Gehaltsbändern von 300–550K $ (Perspective AI, TechTarget). Der tatsächliche Job: AI innerhalb fremder Mauern zum Laufen bringen — deren Daten, deren Berechtigungen, deren Compliance-Abteilung, deren Definition von „gut genug”. Palantir hat die Methode vor Jahren kodifiziert: AI FDEs bauen zuerst eine kundenspezifische Ontologie, bevor irgendeine LLM-Anwendung ausgeliefert wird, und verbringen 30–40 % der Woche mit Discovery (Palantirs AI-FDE-Leitfaden). Die Methode stimmt. Wohin die Woche wirklich geht, entscheidet das Werkzeug darunter. Fünf Schmerzen, einer nach dem anderen.

Schmerz 1 — Woche eins ist immer Klempnerei

Jedes Engagement beginnt gleich: Bevor auch nur ein Geschäftsobjekt auf einem Bildschirm erscheint, brauchen Sie Auth, SSO, Rollen, CRUD-APIs, eine Admin-UI, Dateispeicher und eine Audit-Tabelle. Nichts davon ist der Grund, warum der Kunde Sie engagiert hat. Ihr Differenzierungsmerkmal — die 30–40 % Zeit für das Verständnis seines Geschäfts — wird von den 60 % erdrückt, die in den Wiederaufbau desselben undifferenzierten Unterbaus fließen, den Sie beim letzten Kunden schon gebaut haben.

Was der Stack ändert: Der Unterbau ist schon da. Ein Befehl, und vor dem Mittagessen laufen Console, Sign-in und SSO, Rollen-/Zeilen-/Feld-Berechtigungen, Audit-Logging, REST-APIs und ein MCP-Server:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # Console auf :3000 — Auth, RBAC, Audit bereits durchgesetzt

Alles Ableitbare leitet die Runtime ab. Zu schreiben bleibt nur, was nur Sie schreiben können: die Objekte, Flows und Berechtigungsregeln des Kunden. Woche eins wird zu Discovery und Modellierung — der Arbeit, in der Sie tatsächlich differenziert sind.

Schmerz 2 — Die Demo, die im Security-Review stirbt

Sie kennen den Bogen. Freitag der ersten Woche: eine zusammengeklebte Demo — eine schnell gebaute UI über einer kopierten CSV — und der Raum applaudiert. Monat zwei: Infosec kommt mit drei Fragen. Was genau kann die AI sehen? Wessen Berechtigungen gelten, wenn sie handelt? Wo ist der Audit-Eintrag? Für einen Demo-Stack lautet die ehrliche Antwort: Neubau. Und der Neubau ist der Ort, an dem Engagements sterben.

Was der Stack ändert: Governance ist der Unterbau, kein Nachrüstsatz. Das Validierungsgate akzeptiert nicht einmal ein Objekt ohne deklariertes Sharing-Modell:

export const Ticket = ObjectSchema.create({
  name: 'support_ticket',
  label: 'Ticket',
  sharingModel: 'private',        // Pflicht — ohne lehnt das Gate ab
  fields: {
    subject:  Field.text({ label: 'Subject', required: true }),
    status:   Field.select({ label: 'Status', options: [/* die echten Zustände des Kunden */] }),
    approver: Field.lookup('sys_user'),
  },
});

Zur Laufzeit durchläuft jeder Aufruf — menschliche UI, REST oder ein AI Agent über MCP — dieselbe RBAC-, Zeilen- und Feldsicherheit und landet im selben Audit-Log. Fragt Infosec „was kann die AI sehen?”, ist die Antwort eine Datei, die sie lesen können: Berechtigungs-Metadaten, von der Runtime durchgesetzt, nicht auf einer Folie versprochen. Ihre Freitags-Demo und Ihr Produktions-Deployment sind dasselbe Artefakt. Es gibt keinen Neubau, weil es nie eine governance-freie Version gab.

Schmerz 3 — Anforderungen ändern sich schneller als Code

Mitten im Meeting sagt der Ops-Lead: „Ach ja — Rabatte über 20 % gehen zuerst über die Regionalleiter.” In einer handgebauten Codebasis ist das eine Schema-Migration, drei API-Änderungen, eine UI-Änderung und eine Woche — und in den Augen des Kunden wurden Sie in dem Moment langsam, in dem er konkret wurde. Forward-Deployed-Arbeit lebt und stirbt mit der Iterationsgeschwindigkeit im Raum.

Was der Stack ändert: Die gesamte Anwendung ist kompakte typisierte Metadaten — ein vollständiges CRM sind 1.792 Zeilen, rund 16k Tokens (zählen Sie selbst: find examples/app-crm/src -name '*.ts' | xargs cat | wc -l). Ihr Coding-Agent hält also das gesamte System im Kontext: Die Änderung an der Freigabekette ist ein kohärenter Diff über Flow, Berechtigungen und UI — geschrieben, während das Meeting noch läuft, von os validate geprüft, live in der Console voranschaubar. „Was geht kaputt, wenn wir das ändern?” ist eine Frage, die der Agent wirklich beantworten kann, weil er alles sieht. Anforderungsänderungen bedrohen den Zeitplan nicht mehr — sie werden zur Demo.

Schmerz 4 — Ihre Muster verzinsen sich nie

Der Freigabeketten-Code von Kunde A lässt sich nicht in die Codebasis von Kunde B heben — andere Framework-Versionen, andere Auth, alles anders. Also beginnt jedes Engagement bei null, und eine Drei-Personen-Boutique kann nie den Hebel aufbauen, der Palantirs Modellökonomie trägt. Das ist der stille Grund, warum Forward-Deployed-Beratungen klein bleiben.

Was der Stack ändert: Muster sind typisierte Metadaten, und typisierte Metadaten sind portabel. Die für Kunde A modellierte Freigabekette ist eine Flow-Definition, die Sie in das Repo von Kunde B legen und umbenennen. Über Engagements hinweg akkumulieren Sie eine Hausbibliothek — Objekte, Flows, Berechtigungssets, Seed-Daten — die Ihr Agent in Minuten auf den nächsten Kunden anwendet. Und Sie starten die Bibliothek nicht bei null: HotCRM ist eine vollständige, forkbare Referenz — 15 Objekte, 17 Flows, 4 Dashboards, 2 AI-Copiloten, 4 Sprachen — gebaut als kanonisches Beispiel der Konventionen. Forken, Namespace umbenennen, und Ihr Engagement beginnt mit einem laufenden System statt einem leeren Repo.

Schmerz 5 — Die Übergabe vergiftet die Beziehung

Jedes Engagement endet, und heute endet es schlecht — auf eine von zwei Arten. Übergeben Sie eine Plattform, mietet der Kunde seine eigene Ontologie für immer zurück — Sie sind zum Vertriebskanal geworden, und der Kunde hat gelernt, erfolgreiche Piloten zu fürchten: je besser die Ontologie, desto tiefer der Lock-in. Übergeben Sie eine Spezial-Codebasis, kann sein Team sie nicht warten; sie verrottet, und achtzehn Monate später trägt die Fäulnis Ihren Namen.

Was der Stack ändert: Das ist die Ontologie-Übergabe — das Ende, das das FDE-Playbook nie gelöst hat. Was Sie übergeben, ist das Repo des Kunden: typisierte Objekte, Flows und Berechtigungen unter Apache-2.0, dazu das kompilierte Artefakt und eine Review-Checkliste. Sein Security-Team hat bereits jede Zeile gelesen — es sind 16k Tokens, nicht 300.000 Zeilen. Seine eigenen Coding-Agents warten das System mit derselben Schleife, die Sie benutzt haben, denn das Format wurde agentenschreibbar gebaut. Will der Kunde die Plattform betrieben haben — Browser-AI-Builder, Cloud oder Self-Managed — gibt es ObjectOS, auf derselben offenen Definition; er kann gehen, ohne die Ontologie zu verlieren. Ihren nächsten Vertrag verdienen Sie mit neuer Arbeit, nicht mit Lock-in. Dieser Unterschied ist Ihre Reputation — mit Zinseszins.

Das komplette Metadaten-Toolkit des FDE

Die Ontologie ist nicht nur das Datenmodell. Ein Forward-Deployed-Engagement nutzt für jede Phase — von Discovery bis Übergabe — einen Metadatentyp, und alle sind dieselbe Art typisierter, validierbarer, portabler Definition:

Phase	Die Kundenfrage, die Sie beantworten	Genutzte Metadatentypen
1 · Substantive modellieren	„Was existiert in unserem Geschäft?”	Objekte & Felder (Beziehungen, Validierungsregeln, Formeln) · Datenquellen (bestehende Datenbanken anbinden, keine Migration) · Seed-Daten (für Demos und Abnahme)
2 · Verben modellieren	„Wie fließt die Arbeit wirklich?”	Flows (Freigabeketten, Zustandsmaschinen, Record-Trigger, Zeitpläne) · Freigaben (mehrstufig, Queues, Record-Locking) · Aktionen (rechtegeprüfte Buttons und Serveroperationen)
3 · Oberflächen für Menschen	„Wo arbeiten unsere Leute?”	Apps & Navigation · Views (Liste/Kanban/Kalender/Gantt) · Seiten & Formulare · Dashboards & Berichte (die KPIs, nach denen das Management fragt)
4 · Security-Review bestehen	„Wer darf was sehen und tun?”	Berechtigungssets & Rollen (RBAC) · Zeilen- und Feldsicherheit · Sharing-Regeln · Audit (in der Runtime eingebaut — deklariert, geliefert)
5 · Die AI, die der Kunde wirklich will	„Was kann AI für uns tun?”	AI Agents (Sales-/Service-Copiloten) · AI-Tools & Skills · MCP-Exposition (ai: { exposed: true })
6 · Übergabe & Zinseszins	„Was passiert, wenn Sie gehen?”	Übersetzungen (mehrsprachige Labels für globale Kunden) · App-Manifest & Packaging (kompiliert zu einer objectstack.json, installierbar in jede Umgebung)

Der Punkt: Alle sechs Schichten sind derselbe Stoff. Eine Freigabekette ist typisierte Metadaten genau wie das Datenmodell — und ein AI Agent auch. Dasselbe Validierungsgate prüft sie, derselbe Diff reviewt sie, dasselbe Repo übergibt sie:

// 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 ist die vollständige Demonstration dieses Vokabulars: 15 Objekte, 17 Flows, 10 Aktionen, 4 Dashboards, 2 AI-Copiloten, 6 Skills, 6 Berechtigungsprofile, 5 Sharing-Regeln und 4 Sprachen — jede Schicht vorhanden, rund 170k Tokens, und das Ganze passt noch in ein einziges Agent-Kontextfenster.

Was dieser Stack nicht behebt

Die Gegenseite fair behandelt: Datenföderation und Analytics-Pipelines im Foundry-Maßstab sind Palantirs Heimspiel — geht es darum, Petabytes über vierzig Legacy-Systeme zu fusionieren, ist das eine andere Werkzeugklasse. Change Management behebt kein Stack. Und ein Kunde, der bereits vollständig auf eine geschlossene Plattform standardisiert ist, bleibt womöglich rational dort. Die Behauptung ist enger: Für die Anwendungsschicht der Forward-Deployed-Arbeit — ein Geschäft modellieren und darauf kontrollierte Apps ausliefern — sind die fünf Schmerzen oben jetzt beseitigbar, und die Ontologie kann übergeben statt als Geisel gehalten werden.

Die FDE-Checkliste

1. Die Substantive und Verben des Kunden als Objekte und Flows modellieren, vor jedem UI-Gespräch.
2. Die gesamte Definition kontextgroß halten, damit der Agent sie als Ganzes durchdenken und refaktorieren kann.
3. Berechtigungen per Default konservativ; jede Autoritätsänderung explizit im Diff.
4. Übergeben werden Repo, kompiliertes Artefakt und Review-Checkliste — kein Login in Ihren Tenant.
5. MCP aktiviert lassen, damit die eigene AI des Kunden die App innerhalb seiner Berechtigungen bedient.

Die Schleife ausprobieren

Richten Sie Ihren Coding-Agent auf den offenen Stack — das Scaffold bringt AGENTS.md und das Skills-Bundle mit, der Agent startet also mit geladenen Formatregeln:

npm create objectstack@latest client-app && cd client-app
npx os dev --ui   # die App läuft — modellieren Sie das erste Objekt mit Ihrem Agent

Für Kunden, die die Plattform betrieben haben wollen, ist ObjectOS die kommerzielle Runtime auf derselben offenen Definition — online bauen & fragen, Governance inklusive.