Verliert Software ihren Kopf?

• Mit der Einführung eines Headless-Produkts wettet Salesforce darauf, dass nicht die UI, sondern die Datenebene im Zentrum des Werts steht, und wirft damit die Frage auf, wo im Agenten-Zeitalter noch die Defensibilität von SaaS liegt
• Im SaaS-Zeitalter bestand der Burggraben von Systemen of Record in über die UI geformten Nutzergewohnheiten, doch in einer Struktur, in der Agenten direkt aus der DB lesen und in sie schreiben, schwindet dieser Vorteil
• Die Defensibilität verlagert sich nach unten zu Datenmodellen, Berechtigungen, Workflow-Logik und Compliance und nach oben zu Netzwerken, der Erzeugung proprietärer Daten und realer Ausführungsfähigkeit
• Systeme of Record der nächsten Generation brauchen neue Maßstäbe: agentenfreundliche Datenmodelle, agentenbasierte Berechtigungsverwaltung und geschlossene Execution-Loops
• Die vielversprechendsten Unternehmen der nächsten Generation gehen über bloße Datenspeicherung hinaus und erweitern sich bis zur Ausführung in der realen Welt und zur Koordination mehrerer Parteien

---

Die Frage hinter der Headless-Ankündigung von Salesforce

• Salesforce kündigte vergangenen Monat die Öffnung seiner APIs und die Einführung eines Headless-Produkts an – eine Wette darauf, dass im Agenten-Zeitalter der Wert in der Datenebene statt in der UI liegt
  • Technisch hat sich kaum etwas geändert — die APIs, die jetzt als Headless-Produkt vermarktet werden, existieren seit Jahren, also ein typischer Marketing-Launch von Salesforce
  • Die Kernidee ist eine Struktur, in der Agenten direkt auf die Daten eines Systems of Record zugreifen, ohne eine für Menschen gedachte UI zu durchlaufen
• Wenn man die UI entfernt und nur die DB übrig bleibt, stellt sich die grundlegende Frage, worin noch der Unterschied zu Postgres + gut entworfenem Schema + API besteht
  • Es muss geprüft werden, ob die Elemente, die bisherige Systeme of Record getragen haben, weiterhin gelten oder ob neue Kriterien nötig sind

Das SaaS-Zeitalter, in dem die UI das Produkt war

• Ein System of Record ist die maßgebliche Single Source of Truth für eine bestimmte Domäne
  • CRM ist das System of Record für Umsätze, HRIS das System of Record für Personal, ERP das System of Record für Finanzen
  • Die eigentliche Stärke liegt nicht im bloßen Speichern, sondern darin, eine von der gesamten Organisation geteilte Realität bereitzustellen
• Was Salesforce in den vergangenen 20 Jahren verkauft hat, ist die Art, wie Vertriebsleiter ihre Teams steuern
  • Dashboards, Pipeline-Ansichten, Forecasting-Tools und Activity-Feeds waren das eigentliche Verkaufsobjekt, und das Geschäftsmodell basierte auf dem Verkauf von User Seats
  • Die darunterliegende DB war zentral, aber nachrangig
• Die UI erzeugte Stickiness
  • Sie erzwingt Datenhygiene, schafft ein gemeinsames Vokabular (Lead, Opportunity, Account) und bringt Vertriebsmitarbeiter dazu, Daten einzugeben, die sie sonst nicht erfassen würden
  • Viele Vertriebsleiter nehmen bei einem Jobwechsel Salesforce mit – nicht weil die UI so gut ist, sondern wegen der eingeübten Nutzungsgewohnheiten (muscle memory)
• Agenten beginnen dieses Modell umzukehren
  • Sie können Daten direkt lesen und schreiben, ohne die UI zu durchlaufen
  • Auch rund um SAP breitet sich schnell ein AI-freundliches Ökosystem aus
  • Computer-Use-Agenten hebeln mit der Zeit menschenbasierte Faktoren wie Präferenzen, Training und undokumentierten Kontext aus

Frühere Maßstäbe zur Bewertung der Stickiness von Systemen of Record

• Faktoren, die auf der Art und Weise beruhen, wie Menschen mit Software interagieren, und auf ihren Präferenzen

• Wie häufig wird sie genutzt

  • CRM wird von GTM-Teams täglich genutzt → wird zur Kerninfrastruktur
  • Die Arbeitsroutinen, eingeübten Bedienmuster und über Jahre aufgebaute Management-Kadenz darüber sind am schwersten zu verlagern
  • Häufig wird es nicht einmal als etwas wahrgenommen, das migriert werden könnte

• Write-only oder Read-write

  • Stickiness entsteht bei Systemen of Record, die read-write sind
  • CRM wird ständig gelesen — jedes Call-Log, jedes Stage-Update und jede Task-Erstellung ist Teil eines bidirektionalen Flusses
  • Da mit Live-Betriebsdaten gearbeitet wird, gibt es keinen sicheren Umschaltzeitpunkt → ist es einmal eingeführt, lässt es sich nur schwer wieder verlassen
  • ATS (Applicant Tracking System) liegt dagegen näher an write-only — nach Abschluss eines Hiring-Prozesses schaut man die Daten kaum noch an

• Wie viele undokumentierte SOPs es gibt

  • Geschäftskritischer Kontext ist nicht in Wikis, sondern in Workflow-Regeln kodiert
  • Beispiel Vertrieb: Enterprise-Deals über 100.000 Dollar brauchen VP-Freigabe, EMEA-Deals erfordern zwingend eine Privacy-Prüfung, Rabatte für strategische Logos dürfen Finanzvorgaben nur am Quartalsende umgehen
  • Dieser Kontext entscheidet über rechtzeitige Bearbeitung oder Versäumnisse
  • Eine Migration bedeutet, sämtliche Automatisierungen zu reverse engineeren oder das institutionelle Gedächtnis der Organisation zu verlieren

• Größe interner und externer Abhängigkeiten

  • Dazu zählen nachgelagerte interne Systeme sowie die Notwendigkeit direkten Zugriffs für externe Prüfer, Buchhalter und Regulierungsbehörden
  • Je stärker die Vernetzung in beide Richtungen, desto mehr Knoten müssen bei einer Migration gelöst werden

• Bedeutung von Compliance

  • Payroll-, ERP- und HR-Daten erfordern eine rechtlich belastbare Single Source of Truth, strikte Admin-Zugriffskontrollen und direkten Eingriff durch Prüfer und Regulierer
  • Sie sind daher extrem sticky
  • Vertriebsdaten oder Customer-Support-Tools wie Zendesk liegen auf der anderen Seite — Kontinuität und Kontext sind wichtig, aber es gibt kein regulatorisches Exposure

• Vergleich der Wechselkosten je System of Record

  • ATS ist ein Workflow-Tool mit klar abgegrenztem Prozess Recruiting, schmalen Integrationen und wenigen Nutzern
  • ERP ist das genaue Gegenteil — das Hauptbuch ist zugleich der Audit Trail, und Buchhalter, Prüfer und Regulierer sind direkte Stakeholder
  • Ein ATS auszutauschen ist schmerzhaft, aber machbar; ein CRM auszutauschen ist eine Operation am offenen Herzen; ein ERP auszutauschen ist eine Operation am offenen Herzen bei einem Patienten, der gerade einen Marathon läuft

• Traditionell schwache Burggraben-Elemente

  • Proprietäre Daten — CRM verfügte zwar über reichhaltige Daten, doch Versuche, daraus kundenübergreifende Insights zu erzeugen, blieben begrenzt (nur einige Versuche wie Salesforce Einstein)
  • Netzwerkeffekte — lange der heilige Gral, aber historisch in Systemen of Record schwach ausgeprägt

Was bleibt übrig, wenn die UI verschwindet und Agenten ankommen

• Agenten brauchen keinen Browser — API, Kontext, Instruktionen und Handlungsfähigkeit genügen

• Zwei Veränderungen machen das möglich

  • Verbesserte Schlussfolgerungsfähigkeit von LLMs: Agenten können Kontext lesen, Pläne erstellen, Tools auswählen, ausführen und Ergebnisse prüfen – ohne menschliches Eingreifen
  • Standardisierung des Tool-Zugriffs durch MCP: Agenten rufen externe Funktionen über eine gemeinsame Schnittstelle auf
  • Computer-Use-Agenten können mit dem passenden Kontext selbst ohne API bestehende SW-Interfaces navigieren

• Drei Wege für Softwarekäufer

  • Bestehendes System + Agenten: CLI/API etablierter SaaS-Anbieter nutzen, native Agenten-Produkte (Salesforce Agentforce, SAP Joule) einsetzen oder eigene Agenten bauen — vorausgesetzt, die APIs sind vollständig und nutzbar und der Headless-Übergang ist operativ einfach
  • Eigenes System of Record bauen (DIY): eigenes Datenmodell, eigene Betriebslogik, Berechtigungen, Audit, Integrationen und eigene Agenten von Grund auf aufbauen (ggf. mit Third-Party-Tools)
  • AI-native Alternativen kaufen: neue Softwaregeneration, von Anfang an auf Machine Readability ausgelegt, mit eingebauter Agenten-Orchestrierung als First-Class-Funktion und Headless-Fähigkeit

• Was von den alten Bewertungskriterien überlebt

  • Auf menschlichem Verhalten basierende Faktoren (Nutzungshäufigkeit, read vs. read-write) → verschwinden mit den Nutzungsgewohnheiten
  • Agenten töten den Burggraben aus Gewohnheit, aber nicht den Burggraben aus Betriebslogik und Kontext
  • Im Gegenteil: Damit Agenten sicher handeln können, brauchen sie explizite Regeln, Berechtigungen und Prozessdefinitionen – dadurch wird dieser Teil noch wichtiger

• Kurzfristig bleiben undokumentierte SOPs wichtig

  • In Workflow-Regeln kodierte Organisationslogik ist entscheidend dafür, dass Agenten korrekt arbeiten
  • Sie lässt sich nicht sauber exportieren (insbesondere wenn Menschen noch in Teilen des Prozesses verbleiben)
  • Je leichter sich Kontext erfassen lässt und je mehr Agenten Arbeit ersetzen, desto irrelevanter wird das langfristig jedoch

• Konnektivität bleibt schwierig und weitet sich weiter aus

  • Statt Menschen zu folgen, steht nun die Aufrechterhaltung der Konnektivität zwischen fragmentierten Funktionen und Software im Mittelpunkt
  • Ein CRM-Agent muss Daten und Kontext zwischen Vertrieb, Billing und Customer Success zusammenfügen
  • Wird es zu einem Knoten, an dem Agenten mehrerer externer Organisationen handeln, werden die Abhängigkeiten noch tiefer
  • Sowohl die Kombination aus etabliertem Anbieter + Agenten als auch DIY-DB + Agenten tut sich schwer damit, sich über viele nachgelagerte Softwaresysteme hinwegzusetzen

• Compliance-Daten bleiben wichtig

  • Daten mit regulatorischem oder rechtlichem Risiko brauchen weiterhin eine einheitliche, vertrauenswürdige Datenquelle
  • Dass Unternehmen Payroll- oder Buchhaltungsdaten selbst bauen und pflegen, ist unwahrscheinlich
  • Das schwierigste ungelöste Problem einer vollständig agentischen Welt: Welcher Agent ist in wessen Namen wofür mit welcher Auditierbarkeit autorisiert?
  • Systeme of Record, die die Identitäts- und Berechtigungsschicht für Interaktionen zwischen Agenten werden, erzwingen eine Vertrauensarchitektur und sind daher strukturell schwer zu ersetzen

Neue Defensibilitätsfaktoren für AI-native Startups

• Wie schwer sich ein System of Record nachbauen lässt

  • Kurzfristig ist entscheidend, wie leicht sich auf einem System-of-Record basierende Daten extrahieren und reproduzieren lassen
  • Etablierte SaaS-Anbieter erschweren dies, indem sie APIs schmerzhaft, gated, unvollständig oder wirtschaftlich unattraktiv machen
  • Mit dem Fortschritt von Extraktionstools, besonders Computer-Use-Agenten, wird das immer einfacher
  • Gleichzeitig entstehen neue Unternehmen, die aus E-Mails, Telefonie, Voice Agents und internen Dokumenten reichhaltigere Daten rekonstruieren
  • AI senkt die Kosten, die ersten 80 % eines Systems of Record nachzubauen, aber die übrigen 20 % (Exception Handling, Freigaben, Compliance, Edge-Case-Workflows) entscheiden über echte Alternativen und den Wedge

• Ob bedeutende proprietäre Daten vorhanden sind

  • Verteidigungsfähige Daten sind nicht importierte Daten, sondern Daten, die das Produkt selbst einzigartig erzeugt hat
  • Ein Data Walled Garden — Daten, die proprietär sind, regulatorisch geschützt sind oder laufende Aktualisierung benötigen
  • Softwareanbieter, die in autoritative und vollständige Daten investieren, haben Vorteile gegenüber generischen Anbietern
  • Intern erzeugte verhaltensbasierte Daten: beobachtetes Verhalten, Response Rates, Timing-Muster, Prozessergebnisse, Benchmarks, Ausnahme-Muster, Tracking der Agentenleistung
  • Data is the context

• Ob die Action Layer kontrolliert wird

  • Früher reichte es, Aufzeichnungen zu speichern, doch im neuen Zeitalter handeln Agenten
  • Defensibilität verschiebt sich zu Produkten mit geschlossenem Loop aus Aktion → Ergebniserfassung → Feedback → verbesserte Entscheidung
  • ERP-Beispiele: Ausgabenfreigaben, Payroll-Trigger, Rechnungsabgleich, Versand von Benachrichtigungen
  • Produkte, die den Loop schließen, sitzen nicht nur auf Beobachtung, sondern auf Ausführung → erzeugen einzigartige Daten, verbessern sich mit der Nutzung und lassen sich nicht entfernen, ohne den Workflow zu brechen

• Elemente realer Ausführung

  • Geschäftsmodelle mit Konnektivität zu realen Abläufen, die nicht vollständig automatisiert werden
  • Beispiel Betriebsnetzwerke wie DoorDash — historisch keine Systeme of Record, aber dennoch aufschlussreich
  • Software, die den Loop über Services, Fulfillment, Logistik, Außendienst und Zahlungen schließt, besitzt eine andere Art von Defensibilität als reine SaaS-Angebote
  • Sie speichert nicht nur Daten oder gibt Empfehlungen, sondern entsendet Menschen, bewegt Dinge und führt Services aus
  • Für Builder ergeben sich Chancen in Märkten, in denen Software zunehmend entscheidet und Agenten koordinieren, die letzte Meile aber reale Ausführung erfordert — etwa vertikale Software mit integriertem Field Service

• Netzwerkeffekte

  • In früheren Systemen of Record waren sie schwach, weil die Software primär intern genutzt wurde
  • Sobald sie in Multi-Party-Workflows eingebettet ist, könnten Netzwerkeffekte deutlich wichtiger werden
  • Bei der Vermittlung wiederkehrender Interaktionen wie Käufer-Verkäufer, Arbeitgeber-Beschäftigte, Unternehmen-Prüfer, Vendor-Kunde, Payer-Provider steigt mit mehr Teilnehmern auch der Netzwerkwert
  • Umsetzungsformen
    • Gemeinsame Workflow-Koordination — die Software wird zum Ort, an dem beide Seiten Transaktionen ausführen, Kontext austauschen und Ausnahmen lösen
    • Benchmarking und Intelligence — Bereitstellung von Normen, Auffälligkeiten und Empfehlungen auf Basis von Netzwerk-Mustern
    • Vertrauen und Standardisierung — wenn sie zum gemeinsamen Rail für Freigaben, Handoffs, Compliance und Zahlungen wird, ist sie nicht mehr nur DB, sondern Teil einer Markt-Koordinationsinfrastruktur

• Die technische Kompetenz der Käufer

  • Auch wenn theoretisch jeder Agenten bauen kann, gibt es in der Praxis enorme Unterschiede in der Fähigkeit dazu
  • In vertikalen Endmärkten und bei Funktionskäufern mit schwachen internen Engineering-Ressourcen ist die Wahrscheinlichkeit gering, dass sie eigene DBs, Workflow-Logik, Agenten-Stacks und Governance selbst aufbauen, pflegen und verbessern
  • Auch die Kosten sind zentral — DIY senkt zwar Lizenzkosten, verlagert sie aber auf Implementierung, Wartung und interne Komplexität
  • Chancen bestehen in operativ komplexen, aber technisch unterversorgten Kategorien — Fertigung, Backoffice im Bauwesen, industrielle und Field-Service-Workflows, Buchhaltung

Weitere Pflichtmerkmale (table stakes)

• Neue Datenmodelle (Ontologien)

  • Das Denken in „DIY DB“ unterschätzt den Wert des Objektmodells selbst
  • Bestehende Software wurde gebaut, um Dashboards, Reports und menschliche Workflows zu erfassen → Opportunity, Ticket, Candidate usw.
  • Ein Schema für Agenten muss Schlussfolgern, Aktionen, Statusverfolgung, Exception Handling, Delegation und Koordination zwischen Systemen erfassen
  • Das native Objektmodell verschiebt sich in Richtung task, intent, thread, policy, outcome

• Berechtigungsverwaltung für Agenten

  • Es braucht ein Berechtigungssystem nicht nur für Menschen, sondern auch für die Steuerung von Agenten
  • Zu definieren ist, wer über welchen Agenten unter welcher Policy mit welchen Freigaben, Audit Trails, Rollbacks und Exception-Mechanismen was tun darf

• Kostenkontext

  • Kosten für Aufbau und Betrieb von Agenten und DBs sowie API-Zugriffskosten
  • Das hängt auch mit der Schwierigkeit der Datenreproduktion und der Zahl der Abhängigkeiten zusammen

Fazit — wohin sich Systeme of Record entwickeln

• Dass etablierte SaaS-Anbieter auf Headless setzen, ist eine implizite Wette darauf, dass die Datenebene die Quelle des Werts bleibt
• In stark compliance-getriebenen Kategorien wie Finanzdienstleistungen bleibt diese Wette noch eine Weile valide, und auch der Headless-Übergang liegt dort weiter in der Zukunft
• Aus Sicht von Buildern verändert sich damit die Gelegenheitsstruktur, mit etablierten Anbietern zu konkurrieren, die auf Headless umstellen
• Das System of Record der nächsten Generation ist kein bloßes Aufzeichnungssystem mehr, sondern eine agentenfreundliche Form, die Kontext erfasst, Aufgaben anstößt und Data Exhaust protokolliert
• Die spannendsten Geschäftsmodelle erweitern sich in die reale Ausführung — koordinieren Außendienstkräfte, Logistikdienstleister, Serviceteams und physische Assets oder positionieren sich zwischen mehreren Parteien
• Sie verbinden die Kernelemente alter Geschäftsmodelle und traditioneller Systeme of Record (Daten), wobei die Daten im Hintergrund stehen