Eine Einkaufsleiterin, mit der wir letztes Jahr sprachen, beschrieb ihren Job als «eine sehr langsame API zwischen sechs Systemen». Sie las eine Zahl von einem Dashboard ab, tippte sie in ein anderes, wartete auf eine Freigabe-Mail und tippte sie dann woandershin. Niemand hat diesen Job entworfen. Er hat sich angesammelt.
Diese Beschreibung ist der Grund, warum die Debatte «KI-Agenten gegen SaaS» Biss hat. Die interessante Frage war nie, ob Agenten Text schreiben können. Sondern ob die Software, die Sie pro Sitzplatz mieten, noch einen Menschen braucht, der mittendrin sitzt.
Was einen Agenten wirklich von einem Feature trennt
Fast jeder SaaS-Anbieter liefert inzwischen etwas mit dem Etikett KI aus. Das meiste davon ist ein Feature: Fasse diesen Thread zusammen, entwirf diese Antwort, schlage den nächsten Schritt vor. Nützlich — aber es wartet auf seinen Aufruf und reicht das Ergebnis an Sie zurück.
Einen Agenten definiert, was nach dem Vorschlag passiert. Er nimmt ein Ziel, entscheidet die Schrittfolge selbst, ruft Werkzeuge zur Ausführung auf, prüft, ob das Ergebnis zum Ziel passt — und versucht es erneut, wenn nicht. Die Schleife schliesst sich ohne Sie.
Diese Unterscheidung klingt akademisch, bis man schaut, wohin das Geld geht. Sie bezahlen Ihren SaaS-Anbieter nicht wirklich für die Datenbank — Speicher ist fast gratis. Sie bezahlen für die Oberfläche: die Formulare, die Workflows, die Berechtigungen, die Berichte — das ganze Gerüst, das einen Menschen die Daten sicher bedienen lässt.
Bedient stattdessen ein Agent die Daten, wird ein grosser Teil dieses Gerüsts optional.
Abb. — Die Oberflächenschicht ist, was Sie mieten. Agenten ändern, wer sie benutzt.
Die Vorhersage, die einfach nicht eintritt
Alle paar Jahre verkündet jemand das Ende der Unternehmenssoftware. Low-Code sollte es richten. Dann Chatbots. Beide taten es nicht — und die Gründe lohnen die Erinnerung, denn sie gelten weiter.
Software besteht nicht hauptsächlich aus Features. Sie besteht hauptsächlich aus angesammelten Entscheidungen über Randfälle — die Steuerregel für einen Kanton, die Freigabeschwelle, die sich zum Quartalsende ändert, der Kunde, der auf einem anderen Rechnungsformat besteht. Ein Anbieter hat ein Jahrzehnt damit verbracht, das zu kodieren. Ein Agent, der bei einem leeren Prompt beginnt, nicht.
Compliance ist der andere Anker. Regulierte Branchen brauchen nicht nur die richtige Antwort — sie brauchen einen belastbaren Nachweis, wie die Antwort zustande kam, produziert von einem System, das jemand zertifiziert hat. «Das Modell hat entschieden» ist keine Audit-Spur.
Und die Daten leben in diesen Systemen. Salesforce ist auch deshalb wertvoll, weil das Verlassen schmerzt. Das ist kein Zufall des Designs.
Was sich also ändert
Die ehrliche Antwort: Agenten fressen die Oberfläche, nicht das System.
Achten Sie darauf, wo die Sitzplatzzahlen zuerst fallen. Rollen, die hauptsächlich existieren, um strukturierte Daten zwischen Systemen zu bewegen — Auftragserfassung, Erst-Triage von Tickets, Spesenkontierung, CRM-Pflege — sind die, in denen ein Agent wirklich den ganzen Job macht statt zu assistieren. Die Anbieter wissen das — weshalb mehrere bereits von Pro-Sitzplatz- auf Verbrauchspreise umgestellt haben. Wenn die Software ohne eingeloggten Menschen arbeitet, ergibt Abrechnung pro Mensch keinen Sinn mehr.
Die zweite Verschiebung ist leiser und folgenreicher. Sind Agenten die primären Nutzer, wird die API zum Produkt und die Oberfläche zur Prüffläche. Anbieter, die ihre API als widerwilligen Nachgedanken behandelt haben, sind plötzlich exponiert — denn ein Agent kann sich nicht durch einen Screen klicken, der kein programmatisches Gegenstück hat.
Drittens hört Integration auf, Rohrleitung zu sein, und wird zum eigentlichen Unterscheidungsmerkmal. Ein Agent, der nur ein System erreicht, ist ein Chatbot mit Extraschritten. Sein Wert skaliert mit der Zahl der Werkzeuge, die er aufrufen kann — der Burggraben wandert also zu dem, der die Verbindungen hält.
Das Integrationsproblem, das niemand gelöst hat
Hier trifft die Vision auf eine Wand, die mit Modellqualität nichts zu tun hat.
Ein Agent, der über Ihren Stack hinweg arbeitet, braucht Zugangsdaten für jedes System, das er berührt — und diese Zugangsdaten müssen auf das beschränkt sein, was er darf. Die meiste Unternehmenssoftware wurde auf der Annahme gebaut, dass Zugangsdaten einer Person gehören, die einen Vorgesetzten, einen Laptop und ein Austrittsdatum hat. Nicht-menschliche Identität — ein Agent mit eigenen Berechtigungen, eigener Audit-Spur und eigenem Widerrufspfad — ist in den Produkten der meisten Anbieter genuin unreif.
Das praktische Ergebnis: Frühe Deployments lassen Agenten mit einem Service-Konto laufen, das weit mehr Zugriff hält, als die Aufgabe verlangt — weil es nur so funktioniert. Das ist eine Sicherheitshaltung, die niemand verteidigen würde, wenn man direkt fragte. Und sie ist derzeit sehr verbreitet.
Die zweite Wand ist Fehlerbehandlung über Systeme hinweg. Trifft ein Mensch in einem Werkzeug auf einen unerwarteten Zustand, hält er an und fragt jemanden. Trifft ein Agent ihn auf halbem Weg einer Mehrsystem-Sequenz, kann am Ende eine angelegte Bestellung stehen, ein aktualisierter Lagerbestand — und eine Freigabe, die nie gefeuert hat: eine halbfertige Transaktion ohne offensichtlichen Besitzer. Die Verteilte-Systeme-Leute kennen dieses Problem seit dreissig Jahren. Die meisten Agent-Frameworks entdecken es gerade neu.
Wo das heute wirklich funktioniert
Überspringen Sie die Demos und schauen Sie auf Deployments, die den Kontakt mit der Produktion überlebt haben.
Der Kundensupport ist am weitesten — wenn auch nicht so, wie er üblicherweise verkauft wird. Die Gewinne sind nicht volle Autonomie, sondern Agenten, die die obersten paar repetitiven Tickettypen durchgängig lösen — inklusive Rückerstattung oder Adressänderung — und alles andere mit bereits gesammeltem Kontext an eine Person leiten.
Finanzoperationen sind das andere. Rechnungsabgleich, Spesenrichtlinien-Prüfungen und Abstimmung sind volumenstark, regellastig und langweilig — genau das Profil, das einem Agenten liegt. Auch der Fehlermodus ist eingehegt: Eine falsche Buchung fällt bei der Prüfung auf, nicht beim Kunden.
Vertriebsoperationen liegen dazwischen. Anrufe protokollieren, Datensätze aktualisieren, Kontakte anreichern funktioniert gut. Zu entscheiden, was ein Deal wert ist, nicht — und Teams, die diese Linie verwischen, verbrennen sich.
Beachten Sie, was diese Fälle teilen: begrenzten Umfang, umkehrbare Aktionen und einen Menschen, der das Ergebnis prüfen kann, bevor es zählt. Keiner davon ist der voll autonome digitale Mitarbeiter aus der Keynote. Es sind enge Jobs mit klarer Definition von fertig — genau deshalb haben sie den Piloten überlebt. Die Teams mit den grössten Enttäuschungen haben fast immer offen angefangen — «übernimm unsere Abläufe» statt «leere diese eine Warteschlange» — und geschlossen, die Technologie sei nicht reif. Dabei war der Auftrag das Problem.
Was Sie konkret damit anfangen
Wenn Sie Software kaufen, lautet die nahe Frage nicht, ob Sie Ihren Stack ersetzen. Sondern: Haben Ihre Anbieter eine API, auf die Sie einen Agenten richten könnten — und bepreist Ihr Vertrag Sitzplätze, die Sie in zwei Jahren vielleicht nicht brauchen? Beides lohnt sich bei der Verlängerung anzusprechen. Und beides sind ungewöhnliche Fragen aus Kundenmund — genau deshalb bekommen sie Aufmerksamkeit.
Wenn Sie Software bauen, landet der Druck an einer unbequemeren Stelle. Ein Produkt, dessen Wert die Bequemlichkeit seiner Oberfläche ist, steht schwächer da als zuvor. Ein Produkt, dessen Wert proprietäre Daten, ein hart erarbeitetes Integrationsnetz oder echte Domänenlogik ist, steht stärker. Ehrlich zu sein, welches von beiden Sie sind, nützt mehr, als einen Assistenten in die Seitenleiste zu schieben.
Es gibt eine dritte Gruppe, die es zu benennen lohnt: die Teams, die 2026 interne Agenten auf Software bauen, die sie bereits bezahlen. Dort landet dieses Jahr der Grossteil des echten Werts — und es braucht keinen Anbieter, der irgendetwas ändert. Die Voraussetzung ist unglamourös: saubere Stammdaten, dokumentierte APIs, und jemand, der besitzt, was der Agent darf.
Der Stack verschwindet nicht. Die Annahme, dass den ganzen Tag ein Mensch davor sitzt, ist der Teil, der nicht mehr hält — und die meiste Software wurde vollständig um diese Annahme herum entworfen.
Zu entscheiden, welches Ihrer Systeme einen Bediener verdient und welches einen Agenten, ist der erste Workshop in jedem Agent-Projekt, das wir fahren — bringen Sie uns Ihre Stack-Liste mit.
