Agenten erledigen jetzt SaaS-Arbeit. Die meisten Teams sind nicht vorbereitet

Heute kaufst du keine SaaS-Software mehr. Du kaufst dir einen Ort, um auf Buttons zu klicken, die ein Agent schneller drücken könnte, um drei Uhr morgens, ohne Login-Upgrade zu verlangen.

Das klingt leichtfertig. Es ist auch zunehmend wahr.

Multi-Agent-Deployments stiegen um 327% in den vier Monaten bis Q1 2026, nach Daten aus Andreessen Horowitz State-of-AI-Report. Unternehmen warten nicht, bis ihre SaaS-Anbieter KI-Features ausliefern. Sie holen sich spezifische Workflows aus diesen Plattformen heraus und bauen sie als Custom Apps mit Modellen im Kern neu. Nicht weil SaaS stirbt. Weil die Bedienoberfläche für einen großen Teil der Arbeit zum Engpass geworden ist.

Dieser Teil macht etwa 20 bis 30% der täglichen operativen Arbeit aus, 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 in Kosten und Geschwindigkeit zu zählen. Und es ist die Art von Arbeit, bei der eine sechsmonatige SaaS-Implementierung anfängt, wie das völlig falsche Werkzeug auszusehen.

Die Workflows, die es wert sind, automatisiert zu werden, sind die langweiligen

Das Gegenkulturelle daran. Die besten Kandidaten für Agent-Ersatz sind nicht deine komplexesten Prozesse. Es sind deine standardisiertesten. Das Zeug, das so routiniert ist, dass dein Team kaum darüber nachdenkt, aber immer noch Stunden pro Woche kostet.

Rechnungsabgleich. Status-Update-E-Mails. Daten von einem Dashboard kopieren und in ein anderes einfügen. Nachverfolgungstermine basierend auf CRM-Status planen. Diese Workflows existieren in SaaS-Plattformen, weil SaaS-Plattformen der Ort sind, wo die Daten sind. Aber die kognitive Arbeit, um sie auszuführen, ist nahe null. Das ist genau das, was sie zu Agent-Territorium macht.

Der Haken. Standardisiert bedeutet 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, das einfach wusste. Bevor du etwas an einen Agent übergibst, brauchst du einen schriftlichen Entscheidungsbaum, dem ein neuer Mitarbeiter folgen könnte. Wenn dieses Dokument nicht existiert, schreib es zuerst. Die Agent-Arbeit kommt danach.

Fang mit dem an, das dein Team nervt. Nicht mit dem, das in einem Board-Update beeindruckend klingt.

Kaufen, bauen oder laufen lassen

Sobald du die Kandidaten erfasst 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 die Zusatzgebühr und gehst weiter. Das ist öfter die richtige Antwort, als Builder zugeben wollen. Wenn HubSpot oder Linear einen Workflow-Agent ausliefern, der 80% von dem macht, was du brauchst, muss die Custom-Build gegen die laufenden Wartungskosten verdienen.

Bauen. Der Workflow ist so spezifisch für dein Business, dass kein vorgefertigter Agent ohne großes Verbiegen passt. Oder die Daten liegen über Systeme verteilt, die kein Anbieter verbindet. Hier bekommen Custom Apps auf Basis von Modellen wie Claude dir einen Vorteil. Nicht weil Custom immer besser ist, sondern weil manche Workflows wirklich dein Eigentum sind.

Laufen lassen. Manche Workflows, die wie Agent-Kandidaten aussehen, sind eigentlich Urteile, die sich als Routine tarnen. Ein Mensch trifft jedes Mal eine kleine, aber echte Entscheidung, und ihre Automatisierung beseitigt Verantwortung ohne Komplexität zu senken. Diese lässt man vorerst in Ruhe. Nicht für immer. Aber bis die Entscheidungslogik explizit genug ist, um kontrolliert zu werden.

Der Haken beim Bauen. Die meisten Teams unterschätzen die Maintenance-Fläche. Ein Agent, der im Januar funktioniert, kann bis April driften, während sich upstream Datenschemas ändern. Rechne dafür. Oder arbeite mit einem Team zusammen, das das von Tag eins in die Architektur einbaut.

Überwachung ist die Fertigkeit, nicht Bedienung

Hier machen es die meisten Transformationspläne falsch.

Wenn du einen Agent für einen Workflow einsetzt, schrumpft die Aufgabe deines Teams nicht. Sie verschiebt sich. Sie führen den Prozess nicht mehr aus. Sie überwachen ein System, das den Prozess ausführt, was einen ganz anderen Satz von Instinkten braucht.

Ein Werkzeug bedienen bedeutet, seiner Logik zu folgen. Einen Agent überwachen bedeutet zu wissen, wann seine Logik eine falsche Antwort produzieren wird, sie abzufangen bevor sie sich ausbreitet, und dieses Signal zurück ins System zu speisen, damit es nicht wieder passiert. Das ist näher an Qualitätskontrolle in einem Fertigungskontext als an Software-Schulung.

Die konkrete Konsequenz. Schulte dein Team nicht darin, die Agent-Schnittstelle zu nutzen. Schulte 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 Eskalationsweg. Dann beobachte die Checkliste. Die Punkte, die immer wieder auftauchen, sind deine nächste Verbesserungsrunde.

Nebenbemerkung. Die Teams, die am meisten mit Agent-Adoption kämpfen, sind nicht diejenigen, die Automatisierung ablehnen. Sie sind diejenigen, die ihr in der ersten Woche zu sehr vertrauen und aufhören zu prüfen. Setz eine verpflichtende Review-Kadenz und halte sie mindestens drei Monate lang.

Warum eine Boutique hier schneller ist als eine Plattform

Eine SaaS-Implementierung dieser Art von Workflow dauert normalerweise fünf bis sieben Monate von Scoping bis Go-live. Diese Timeline existiert aus guten Gründen: Change Management, Integrationstests, Trainingsrollout, Anbieterkoordination. Das ist keine Verschwendung. Das ist Overhead, der mit organisatorischer Komplexität skaliert.

Das Problem ist, dass die meisten der Workflows, die es in H2 2026 wert sind automatisiert zu werden, nicht organisatorisch komplex sind. Sie sind technisch spezifisch. Der richtige Zug ist ein kleiner, fokussierter Build, der die Systeme verbindet, die du bereits hast, die Modelllogik einwickelt, die du brauchst, und etwas Benutzbar in Wochen statt Monaten liefert.

Studio Hyra baut diese als Track-B-Custom-Apps mit Claude Code als primärem Motor. Die Architektur ist von Natur aus schlank, nicht als Kompromiss. Ein kleines Team bedeutet weniger Handoffs. Weniger Handoffs bedeutet, dass die Person, die das Problem scoped hat, die gleiche Person ist, die es in Woche drei debuggt. Diese Kontinuität ist kein Luxus. Sie ist, wie du die Situation vermeidest, in der das gelieferte Produkt technisch funktioniert, aber niemand auf Kundenseite versteht, warum.

Wir haben diesen Prozess für Kunden durchgeführt, die zu uns nach einem fehlgeschlagenen Enterprise-Rollout kamen. Die Story ist normalerweise dieselbe: zu viele Stakeholder, zu viele Anforderungsdokumente, nicht genug Kontakt zwischen den Buildmachern und dem echten Workflow. Die Lösung ist nicht eine bessere Methodik. Sie ist eine kürzere Kette zwischen dem Problem und den Leuten, die es lösen.

Was du vor Q3 tun solltest

Wenn du Gründer oder Operations-Lead bist und darüber für die zweite Jahreshälfte 2026 nachdenkst, hier ist die praktische Abfolge.

Zuerst ordne deine standardisiertesten Workflows. Nicht die aufregenden. Die langweiligen, die dein Team in drei Sätzen beschreiben könnte. Sortiere sie nach Stunden pro Woche und Anzahl der beteiligten Menschen. Die Spitze dieser Liste ist dein Startpunkt.

Zweitens wende den Kaufen-Bauen-Laufen-Test auf jeden an. Sei ehrlich, was deine Anbieter in den nächsten sechs Monaten ausliefern werden. Ein Roadmap-Versprechen ist keine Bereitstellung. Wenn das Vendor-Feature nicht heute in Produktion ist, behandle es für Planungszwecke als nicht existent.

Drittens, bevor ein Build startet, schreib die Entscheidungslogik auf. Jeder Branch. Jede Exception, die jemand je aus Gefühl bearbeitet hat. Dieses Dokument wird länger dauern, als du erwartest. Es wird dir auch mehr Zeit sparen als jede andere einzelne Investition ins Projekt.

Viertens, design die Überwachungsschicht, bevor du den Agent designst. Wer prüft die Outputs? Wie oft? Wie sieht ein Flag aus? Was passiert, wenn eines feuert? Wenn du diese Fragen nicht beantworten kannst, bist du nicht bereit zum Einsatz.

Das Zeitfenster, um das vor Table Stakes zu machen, ist nicht unendlich. Es schließt sich auch nicht morgen. Du hast genug Zeit, es richtig zu machen. Nicht genug Zeit, es zweimal zu machen.