Agenten ersetzen eure SaaS-Prozesse

Der SaaS-Umsatz zahlt in vielen Fällen nicht mehr für Software. Er zahlt für einen Ort, um Buttons zu drücken, die ein Agent schneller klicken könnte, um drei Uhr morgens, ohne dass jemand um eine Upgrade-Freigabe fragen muss.

Klingt etwas dünn. Aber es wird zunehmend zur Realität.

Multi-Agent-Deployments sind in den vier Monaten bis Q1 2026 um 327% gewachsen, laut Daten, die Andreessen Horowitz in ihrem State of AI Report veröffentlicht haben. Unternehmen warten nicht darauf, dass ihre SaaS-Anbieter KI-Features ausliefern. Sie reißen bestimmte Workflows komplett aus diesen Plattformen heraus und bauen sie als Custom Apps neu auf, mit Modellen im Kern. Nicht, weil SaaS stirbt. Weil die Interface-Ebene für einen großen Teil der Arbeit zum Bottleneck geworden ist.

Dieser Anteil liegt zwischen 20 und 30% der täglichen Operationsarbeit, basierend auf Workflow-Audits, die wir bei Kunden in Logistik, Fintech und Media durchgeführt haben. Es ist nicht die ganze Arbeit. Aber genug, um kosten- und geschwindigkeitsmäßig zu zählen. Und es ist die Art von Arbeit, bei der eine sechsmonatige SaaS-Implementierung wie das falsche Werkzeug aussieht.

Die Workflows, die sich lohnen, sind die langweiligen

Hier kommt der konträre Part. Die besten Kandidaten für Agent-Automatisierung sind nicht deine komplexesten Prozesse. Es sind deine standardisiertesten. Das Zeug, das so routinemäßig ist, dass dein Team kaum drüber nachdenkt, aber trotzdem jede Woche Stunden frisst.

Rechnungsabgleich. Status-Update-E-Mails. Daten aus einem Dashboard kopieren und in ein anderes einfügen. Follow-ups basierend auf CRM-Status planen. Diese Workflows existieren in SaaS-Plattformen, weil dort die Daten sind. Aber die kognitive Arbeit, um sie auszuführen, ist fast null. Das ist genau das, was Agenten zum Einsatz macht.

Der Knackpunkt. Standardisiert heißt nicht, einfach zu automatisieren. Ein Workflow, der wie zwei Schritte aussieht, hat oft sieben Edge Cases, die niemand dokumentiert hat, weil die Person, die ihn macht, es einfach wusste. Bevor du etwas an einen Agenten übergibst, brauchst du einen schriftlichen Entscheidungsbaum, den ein neuer Mitarbeiter befolgen könnte. Wenn dieses Dokument nicht existiert, schreib es erst. Die Agent-Arbeit kommt danach.

Fang mit dem an, das dein Team lästig findet. Nicht mit dem, das in einem Board Update beeindruckend klingt.

Kaufen, bauen oder laufen lassen

Sobald du die Kandidaten gemappt hast, ist die echte Entscheidung nicht technisch. Sie ist architektonisch. Für jeden Workflow wählst du einen von drei Wegen.

Kaufen. Dein SaaS-Anbieter liefert ein Agent-Feature, das den Fall abdeckt. Du konfigurierst es, zahlst den Aufpreis und gehst weiter. Das ist öfter die richtige Antwort, als Builder zugeben wollen. Wenn HubSpot oder Linear einen Workflow-Agent ausliefert, der 80% von dem macht, was du brauchst, muss der Custom Build sich gegen die laufenden Wartungskosten rechnen.

Bauen. Der Workflow ist spezifisch genug für dein Business, dass kein vorgefertigter Agent ohne großes Biegen passt. Oder die Daten liegen so fragmentiert über Systeme verteilt, dass kein Vendor sie verbindet. Das ist, wo Custom Apps auf Basis von Modellen wie Claude dir einen Vorteil geben. Nicht, weil Custom immer besser ist, sondern weil manche Workflows wirklich deine sind.

Laufen lassen. Manche Workflows, die wie Agent-Kandidaten aussehen, sind eigentlich Urteilsfälle im Routine-Kostüm. Ein Mensch trifft jedes Mal eine kleine, aber echte Entscheidung, und Automatisierung würde Verantwortung wegfallen, ohne Komplexität zu reduzieren. Das sind die zum Liegenlassen, erst mal. Nicht für immer. Aber bis die Entscheidungslogik explizit genug ist, um sie zu prüfen.

Der Knackpunkt beim Bauen. Die meisten Teams unterschätzen die Wartungsfläche. Ein Agent, der im Januar funktioniert, kann im April driften, wenn sich upstream Datenschemas ändern. Bau das ein. Oder arbeite mit einem Team, das es von Tag eins in die Architektur baut.

Überwachung ist die Fähigkeit, nicht Bedienung

Das ist der Teil, den die meisten Transformationspläne falsch verstehen.

Wenn du einen Agenten einsetzt, um einen Workflow auszuführen, schrumpft die Arbeit deines Teams nicht. Sie verschiebt sich. Sie führen den Prozess nicht mehr aus. Sie überwachen ein System, das den Prozess ausführt, und das braucht ein ganz anderes Set an Instinkten.

Ein Tool zu bedienen heißt, seiner Logik zu folgen. Einen Agenten zu überwachen heißt zu wissen, wann seine Logik eine falsche Antwort produzieren wird, sie zu fangen, bevor sie sich ausbreitet, und dieses Signal dem System zurück zu geben, damit es nicht wieder passiert. Das ist näher an Qualitätskontrolle im Fertigungskontext als an Software-Training.

Die konkrete Konsequenz. Trainier dein Team nicht darin, die Agent-Oberfläche zu nutzen. Trainier sie darin, wie Fehler aussehen. Welche Outputs eine Überprüfung auslösen sollten. Welche Edge Cases der Agent noch nicht gesehen hat. Gib ihnen eine kurze Checkliste und einen klaren Eskalationspfad. Dann beobachte die Checkliste. Die Punkte, die immer wieder auftauchen, sind deine nächste Verbesserungsrunde.

Nebenbemerkung. Die Teams, die am meisten mit Agent-Einführung kämpfen, sind nicht die, die Automatisierung ablehnen. Sie sind die, die ihr in den ersten zwei Wochen zu sehr vertrauen und dann aufhören zu prüfen. Setz eine verpflichtende Review-Rhythmus und halte sie mindestens drei Monate durch.

Warum ein Studio hier schneller ist als eine Plattform

Eine SaaS-Implementierung dieser Art von Workflow läuft typischerweise fünf bis sieben Monate vom Scoping bis zum Live-Gang. Diese Timeline existiert aus guten Gründen: Change Management, Integrationstests, Training Rollout, Vendor Koordination. Es ist keine Verschwendung. Es ist Overhead, der mit organisatorischer Komplexität skaliert.

Das Problem ist, dass die meisten Workflows, die sich in H2 2026 lohnen zu automatisieren, nicht organisatorisch komplex sind. Sie sind technisch spezifisch. Der richtige Move ist ein kleiner, fokussierter Build, der die Systeme, die du schon hast, verbindet, die Model-Logik einbaut, die du brauchst, und etwas Nutzbares in Wochen statt Monaten ausliefert.

Studio Hyra baut diese als Track B Custom Apps, mit Claude Code als primärem Engine. Die Architektur ist bewusst schlank, nicht als Kompromiss. Ein kleines Team bedeutet weniger Übergaben. Weniger Übergaben bedeutet, die Person, die das Problem definiert hat, ist dieselbe, die es in Woche drei debuggt. Diese Kontinuität ist kein Luxus. So vermeidest du die Situation, wo das gelieferte Produkt technisch funktioniert, aber keiner auf Client-Seite versteht, warum.

Wir haben diesen Prozess für Kunden durchlaufen, die nach einem fehlgeschlagenen Enterprise Rollout zu uns kamen. Die Geschichte ist meist gleich: zu viele Stakeholder, zu viele Requirements Dokumente, zu wenig Kontakt zwischen Builders und dem echten Workflow. Der Fix ist keine bessere Methodik. Es ist eine kürzere Kette zwischen Problem und den Leuten, die ihn lösen.

Das musst du vor Q3 tun

Wenn du Founder oder Operations Lead bist und das für die zweite Jahreshälfte 2026 denkst, hier ist die praktische Reihenfolge.

Erstens. Map deine standardisiertesten Workflows. Nicht die spannenden. Die langweiligen, die dein Team in drei Sätzen beschreiben könnte. Ordne sie nach Stunden pro Woche und Anzahl der beteiligten Personen. Das Top dieser Liste ist dein Startpunkt.

Zweitens. Wende den Buy-Build-Leave Test auf jeden an. Sei ehrlich, was deine Vendors in den nächsten sechs Monaten ausliefern werden. Ein Roadmap-Versprechen ist keine Deployments. Wenn die Vendor-Feature nicht heute in Production ist, behandle sie als nicht existierend für Planungszwecke.

Drittens. Bevor irgendein Build startet, schreib die Entscheidungslogik auf. Jeden Branch. Jede Exception, die jemand je mit Gefühl gehandhabt hat. Dieses Dokument wird länger dauern als du erwartest. Es wird dir aber mehr Zeit sparen als jede andere einzelne Investition in das Projekt.

Viertens. Designet die Überwachungsebene, bevor du den Agenten designest. Wer prüft die Outputs? Wie oft? Wie sieht ein Flag aus? Was passiert, wenn eins auslöst? Wenn du diese Fragen nicht beantworten kannst, bist du nicht bereit zum Deployen.

Das Fenster, das dafür zu tun, bevor es zur Table Stakes wird, ist nicht unendlich. Es schließt sich aber auch nicht morgen. Du hast genug Zeit, es richtig zu machen. Nicht genug Zeit, es zweimal zu machen.