Forward Deployed Engineer: erst der Prozess, dann Agenten

"Become a $1M/yr FDE." So heisst eine aktuelle Folge des Startup Ideas Podcast. FDE steht für Forward Deployed Engineer. Der Titel ist gut. Die Daten erzählen eine kleinere Geschichte.

Die Nachfrage ist echt. Die Stelleninserate für Forward Deployed Engineers auf Indeed sind zwischen Januar und September 2025 um 800% gestiegen. Der Lohn ist hoch, aber nicht magisch. Eine Branchen-Auswertung nennt ein Grundgehalt von rund 174'000 US-Dollar im Median, bei AI-Labs liegt die Gesamtvergütung zwischen 350'000 und 550'000 Dollar. Die Rechnung der Folge für die Million ist ein Anteil am Wert: Liefere 10 Millionen Dollar, behalte 10%.

Vergiss also den Lohn. Brauchbar ist die Methode dahinter. Sie erklärt, warum die meisten AI-Projekte stecken bleiben. Und sie gilt für eine Firma mit 60 Leuten genauso wie für einen US-Konzern.

Der Gast ist Vasuman Moza von Varick Agents. Die Firma setzt Forward Deployed Engineers in grosse Unternehmen und baut dort Prozesse rund um AI-Agents neu. Ein Forward Deployed Engineer ist ein Engineer, der im Betrieb des Kunden arbeitet, nicht am Schreibtisch des Anbieters.

Host Greg Isenberg verlangt konkrete Beispiele, und Moza bringt Zahlen aus Mandaten. Die Details sind verfremdet. Lies die Zahlen als Richtung, nicht als Benchmark.

Was du lernst

• Warum der dokumentierte Prozess nie der echte ist
• Die vier Töpfe, in die jeder Prozessschritt gehört
• Warum Agenten in dein CRM oder ERP gehören, nicht daneben
• Was ein erstes Projekt bringt, in Zahlen

Ein Agent ist nur so gut wie die Prozesskarte darunter

Das ist die These. Mozas Version ist kürzer: Don't apply AI. AI lässt sich nicht auftragen wie eine Schicht Farbe. Wenn niemand aufgeschrieben hat, wie die Arbeit wirklich fliesst, automatisiert der Agent eine Vermutung.

Zuerst kommt also die Karte, dann der Agent. Der Rest dieses Artikels ist der Beleg, vom Ursprung des Problems bis zu den Zahlen.

Warum bleiben die meisten AI-Piloten stecken?

Die meisten AI-Piloten bleiben stecken, weil sie den dokumentierten Prozess automatisieren. Der dokumentierte Prozess ist aber nicht der echte. Der echte lebt in Köpfen, in Ausnahmen und in Schleifen, die niemand gezeichnet hat. Ein Agent, der auf der offiziellen Version gebaut ist, scheitert an der ersten Ausnahme.

Das Muster ist gut gemessen. Der Report GenAI Divide des MIT zeigt: Rund 95% der Piloten mit generativer AI in Unternehmen liefern keinen Ertrag. Die Autoren sehen die Ursache in der Lücke zwischen den Tools und den echten Abläufen, nicht in der Qualität der Modelle. In einer Celonis-Umfrage unter 1'620 Führungskräften, auch aus Deutschland, Österreich und der Schweiz, sagen 89%, dass AI verstehen muss, wie ihre Prozesse laufen, um Resultate zu liefern.

Mozas erstes Beispiel macht es konkret. Eine börsenkotierte Software-Firma mit 5 Milliarden Dollar Umsatz hatte ihren Offertprozess in 7 sauberen Schritten dokumentiert. Sein Team liess Process Mining über das CRM laufen.

Der echte Prozess hatte 20 Schritte und 7 Schleifen. 61% der Anfragen gingen zurück an den Start. Legal schickte 12% zurück. In 30% der Fälle musste eine neue Offerte nochmals durch die Freigabe.

Nichts davon stand auf Papier. In jeder Firma, die er sieht, ist jemand seit 20 Jahren dabei und erledigt es einfach. Ich nenne das verstreutes Wissen: Product kennt einen Teil, Sales einen anderen, und jeder Agent startet bei null. Aus demselben Grund ist ein CRM-Trichter nicht dein echter Sales-Prozess.

Es erklärt auch, warum so viele Firmen hier bei Schritt eins stehen bleiben. In Deutschland nutzen inzwischen 57% der Unternehmen AI, aber 9 von 10 sehen sich erst am Anfang.

Wie ein Forward Deployed Engineer einen Prozess kartiert

Ich zähle fünf Schritte in seiner Methode. Der grösste Teil der Arbeit passiert, bevor jemand einen Agenten baut.

1. Die Leute befragen. Starte mit einer Abteilung. Frag, warum es jeden Schritt gibt, wer wirklich entscheidet, welcher Schritt Theater ist und wie oft Ausnahmen vorkommen.
2. Die führenden Systeme auswerten. Sein Team lässt Process-Mining-Agenten drei bis vier Wochen über CRM oder ERP laufen, die Systems of Record. Welche Datensätze kommen rein, wer korrigiert sie, wohin gehen sie danach?
3. Lesen, was es gibt. Alte Dokumentation, Chat-Verläufe, Tabellen. Manchmal veraltet, manchmal gut.
4. Jeden Schritt in einen von vier Töpfen sortieren. Streichen. In einfachen Code giessen, wenn es eine klare Wenn-dann-Regel ist. Einem Agenten geben, wenn der Schritt Urteil braucht und du Historie zum Lernen hast. Oder als menschlichen Entscheid behalten, wenn ein Fehler teuer ist.
5. Messen, bevor du baust. Durchlaufzeit, Ausnahmequote, Kosten pro Fall. Ohne Ausgangswert kannst du später nichts belegen.

Eine Quelle allein reicht nicht. Eine grosse Firma hat zehn Jahre CRM-Historie. Eine kleine hat vor allem Köpfe. Interviews ohne Daten liefern Meinungen, Daten ohne Interviews liefern das halbe Bild.

In Schritt 4 liegt der Wert. Moza zitiert Michael Hammer. Dessen Artikel von 1990 in der Harvard Business Review forderte, Prozesse neu zu entwerfen, statt sie zu automatisieren.

Der Punkt, den er von Hammer nimmt: Beschleunige jeden von 20 Schritten, und der Prozess wird vielleicht nicht schneller, weil die Zeit zwischen den Schritten liegt. Das ist die Übergabe zwischen Teams. Kein Agent repariert eine Übergabe, die es gar nicht geben sollte.

Die Aufteilung ist weniger agentenlastig, als der Hype vermuten lässt. Eine Beschreibung der Varick-Methode nennt ein typisches Redesign: Von 8 Schritten werden 4 automatisiert, bei 3 bleibt ein Mensch beteiligt, 1 bleibt manuell.

Sein Zeitplan ist kurz. 4 Wochen für das Audit und die ersten Proofs of Concept. 4 Wochen für den Bau. Danach ein Vorher-nachher-Vergleich 3 und 6 Monate später. Die fertige Karte hat noch einen zweiten Job: Sie ist das Briefing für den Agenten, so wie ein gutes Ticket ein Kontext-Container für Agenten ist.

Muss ich mein CRM oder ERP für AI-Agents ersetzen?

Nein. Die Agenten, die funktionieren, laufen in den Systemen, die du schon hast. Sie lesen und schreiben in deinem CRM oder ERP und holen die Freigabe im Chat-Tool, das dein Team ohnehin nutzt. Ein Migrations-Pitch verliert den Raum und verzögert das Resultat um Jahre.

Moza ist da direkt. Kunden erzählen ihm von ERP-Wechseln, die mehrere Jahre und mehrere Millionen Dollar gekostet haben, in einem Fall rund 10 Millionen. Niemand will eine zweite Runde. Seine Agenten werten also das CRM aus und handeln im CRM, und eine menschliche Freigabe ist eine Nachricht in Slack. Das Team braucht keine Schulung, weil sich auf dem Bildschirm nichts ändert.

Damit ist das führende System das eigentliche Tool. Es hält die Historie, die ein Agent braucht, um einen Fall zu beurteilen. Was du daraus willst, ist Kontext, nicht nur Daten.

Zwei weitere Entscheide aus der Folge. Erstens trennt er Chat-Assistenten von Hintergrund-Agenten. Ein Hintergrund-Agent erledigt denselben Job jedes Mal ohne Aufforderung und meldet sich nur, wenn er einen Entscheid braucht. Seine Schätzung: Ein Assistent bringt 10 bis 20% schnelleren Output, ein Hintergrund-Agent 70 bis 80%.

Zweitens brauchen die meisten Schritte nicht das neueste Modell. Er testet jeden Workflow gegen mehrere Modelle und wählt pro Workflow.

Ein Punkt für den DACH-Raum. Er sieht bei seinen Kunden keine Nachfrage nach eigener Hardware im Haus, auch nicht bei Banken und Pharma-Firmen. Seine Firma bezieht die Modelle über die grossen Cloud-Plattformen, mit Bedingungen, die Training und Datenspeicherung ausschliessen.

Musst du einen Forward Deployed Engineer einstellen?

Am Anfang eher nicht. Ein Forward Deployed Engineer verbindet drei Fähigkeiten: verstehen, wie die Arbeit läuft, produktiven Code mit Audit und Security ausliefern, und wissen, was man einem Modell anvertrauen kann. Das lässt sich im eigenen Team aufbauen, wenn du mit einem Prozess startest.

Moza sagt, Leute, die in allen dreien stark sind, seien selten. Die meisten haben eine oder zwei. Obendrauf kommt eine vierte: das Ganze der Geschäftsleitung erklären.

• Der Prozess. Wie funktionieren Salesforce, NetSuite oder Dynamics wirklich, und wie sollte die Funktion aussehen?
• Der Code. Agenten, die diese Systeme ansprechen, mit Audit-Trail, Governance und Security. Das ist Agentic Engineering mit Disziplin, keine Demo.
• Die AI-Schicht. Welches Modell für welchen Schritt, Evals als Tests dafür, und ein Rollback, wenn ein Agent falsch handelt.

Seine Einstiegsübung dauert vier Tage und nimmt dein eigenes Leben als Testfall. Liste jede App auf, die deine Sachen hält, und welche gewinnt, wenn zwei sich widersprechen. Nimm 20 Dinge, die du letzte Woche erledigt hast.

Schreib eines davon Schritt für Schritt auf, mit jeder Ausnahme. Sortiere die Schritte in die vier Töpfe. Dasselbe Playbook würde er einer Firma geben, die eigene FDEs aufbauen will.

Meine Ergänzung: Mach es danach für einen echten Prozess in einem Team. Ein Prozess, ein Owner.

Was bringt Prozess-Reengineering in Zahlen?

Im Kreditoren-Fall aus der Folge wurden aus 17 Prozessschritten 7. Die Durchlaufzeit fiel von 24 Tagen auf 6. Die Kosten pro Rechnung sanken von 31 auf 6 US-Dollar. Der Anteil der Rechnungen, die ohne Ausnahme durchlaufen, stieg von 18% auf 87%.

Lies die letzte Zahl nochmals. Vor dem Projekt nahmen 82% der Rechnungen einen Ausnahmeweg. Das ist kein fehlender Agent. Das ist ein kaputter Prozess.

Moza sagt es selbst: Dieser Gewinn ist Prozess-Reengineering, es geht nicht nur um Agenten. Die Kartierung dauerte zwei bis drei Wochen mit Interviews und Process Mining.

Niemand entwirft so einen Prozess. Er wächst. In einem weiteren Beispiel fuhren fünf Portfolio-Firmen auf demselben ERP die gleiche Art Prozess in 12, 9, 15, 18 und 13 Schritten.

Eine Einschränkung. Das sind die eigenen Zahlen eines Anbieters, aus einzelnen Mandaten, mit verfremdeten Details. Prüf sie also an einem publizierten Fall.

Moza verweist auf Thrive Holdings. Die Gruppe kauft Treuhand- und IT-Service-Firmen und setzt Engineers hinein. Sie besitzt über 70 Firmen. Ihre Steuer-Agenten haben über 7'000 Steuererklärungen mit 98% Genauigkeit verarbeitet und die Vorbereitungszeit um mehr als 30% gesenkt. Andere Firma, gleiches Muster: Engineers im Betrieb, Prozess zuerst.

Wo das funktioniert, wo nicht, und die Falle

✅ What shines. Abläufe mit hohem Volumen und vielen Regeln, mit einem führenden System und Jahren an Historie: Rechnungen, Offert-Freigaben, Abstimmungen. Es gibt einen klaren Owner, einen messbaren Ausgangswert und ein sichtbares Resultat innert Monaten.

❌ What doesn't shine. Kleine Firmen, in denen nichts aufgeschrieben ist und kein führendes System existiert. Dort gibt es keine Historie zum Auswerten, also tragen die Interviews alles. Persönliche Assistenz-Agenten gehören auch dazu. Moza sieht noch keine Governance, um ihnen Firmenprozesse zu überlassen.

⚠️ Warning. Lass Menschen an Freigaben und Zahlungen. Ein Agent, der jede Rechnung zahlt, die echt aussieht, ist ein Geschenk für Betrüger.

Und rechne die Margen-Mathematik der AI-Roll-ups mit Abschlag. Eine Studie von Stanford und BetterUp zeigt, dass 40% der Mitarbeitenden AI-Output erhalten, der poliert aussieht, aber keine Substanz hat. Das kostet rund 186 Dollar pro Person und Monat. Gartner erwartet, dass über 40% der Agentic-AI-Projekte bis Ende 2027 gestoppt werden. Die Gründe: steigende Kosten, unklarer Nutzen oder schwache Risikokontrolle.

Zurück zur Million. Niemand zahlt sie dafür, dass jemand Agenten kennt. Wenn sie jemand zahlt, dann dafür, dass jemand den Prozess kennt.

Die vier Töpfe beschreiben schlicht, wie Teams aus meiner Sicht arbeiten sollten. Ich nenne es Get Multiplayer: Menschen setzen Ziele, entscheiden und geben frei. Agenten bereiten vor und übernehmen wiederkehrende Aufgaben. Gemeinsame Ziele und gemeinsamer Kontext halten die Arbeit zusammen.

Die Prozesskarte ist dieser gemeinsame Kontext, aufgeschrieben. AI repariert keinen unklaren Prozess. Sie macht ihn schneller und lauter.

Wenn du pro Ausgabe einen solchen Bau sehen willst: abonniere den Newsletter The Science of GTM.