Das Szenario, das alles verändert hat

Vor drei Monaten habe ich ein Make.com-Szenario gebaut, das Produktdaten von einer Lieferanten-Website scrapt, in ein Google Sheet schreibt und eine Slack-Benachrichtigung schickt. Klassiker. Lief zwei Wochen perfekt. Dann hat der Lieferant sein Website-Layout geändert — ein einziges div wurde umbenannt — und das gesamte Szenario ist zusammengebrochen. Kein Fehler, keine Warnung. Einfach falsche Daten. Ich habe 45 Minuten damit verbracht, den HTTP-Modul-Parser anzupassen und CSS-Selektoren zu korrigieren.

Zeitgleich lief ein AI Agent auf der gleichen Aufgabe. Selbe Website, selbes Layout-Update. Der Agent hat die Änderung registriert, die neue Seitenstruktur analysiert und die richtigen Daten extrahiert. Ohne mein Zutun. Das war der Moment, in dem mir klar wurde: Wir reden hier nicht über eine Evolution. Wir reden über einen Paradigmenwechsel.

Warum das alte Modell an seine Grenzen stößt

Make.com, n8n und Zapier basieren auf dem gleichen Grundprinzip: Trigger, Action, Condition. Wenn X passiert, tue Y. Optional: prüfe Z. Dieses Modell war revolutionär, als es auf den Markt kam. Es hat Tausenden von Nicht-Programmierern ermöglicht, Systeme zu verbinden und repetitive Aufgaben zu automatisieren. Dafür verdienen diese Tools enormen Respekt — und für einfache, deterministische Workflows funktionieren sie nach wie vor einwandfrei.

Aber die Realität ist: Die meisten Geschäftsprozesse sind nicht deterministisch. Ein Kunden-Onboarding erfordert Urteilsvermögen. Soll dieser Lead in Segment A oder B? Die Antwort hängt vom Kontext ab — von der Branche, vom Verhalten auf der Website, von der Tonalität der ersten E-Mail. In Make.com baue ich dafür einen Router mit 15 Filtern und hoffe, dass ich jeden Edge Case abgedeckt habe. Ein AI Agent liest die Daten, versteht den Kontext und trifft eine fundierte Entscheidung — ähnlich wie ein erfahrener Mitarbeiter es tun würde.

Was AI Agents konkret anders machen

Der Unterschied lässt sich auf drei Fähigkeiten reduzieren, die regelbasierte Tools strukturell nicht bieten können:

  • Reasoning über unstrukturierte Daten: Ein Agent kann eine E-Mail lesen und entscheiden, ob sie eine Beschwerde, eine Anfrage oder ein Kompliment ist — ohne dass ich für jedes Szenario einen Regex oder ein Keyword-Matching bauen muss.
  • Adaptives Verhalten: Wenn sich eine Datenquelle ändert — ein neues Feld in einer API-Antwort, ein verändertes HTML-Layout, ein unerwartetes Datumsformat — kann ein Agent sich anpassen. Ein Make-Szenario bricht ab.
  • Multi-Step-Reasoning: Komplexe Aufgaben wie „Finde alle offenen Rechnungen, prüfe welche überfällig sind, formuliere individuelle Zahlungserinnerungen basierend auf der Kundenhistorie und schicke sie über den bevorzugten Kanal“ erfordern in Make.com ein Monster-Szenario mit 30+ Modulen. Ein Agent löst das als natürlichen Arbeitsauftrag.

Tools wie OpenClaw, Claude Computer Use oder Browser-Use-Agents gehen noch einen Schritt weiter: Sie können mit grafischen Oberflächen interagieren, Formulare ausfüllen und sogar Systeme bedienen, die keine API haben. Das macht eine ganze Kategorie von Automatisierungen möglich, die vorher schlicht undenkbar war.

Datenextraktion: Wo der Unterschied am deutlichsten wird

Ein konkretes Beispiel aus meiner Praxis: Ich extrahiere Geschäftsdaten aus Handelsregistereinträgen, PDF-Rechnungen und Unternehmenswebsites. Jede Quelle hat ein anderes Format. Jede PDF hat ein anderes Layout. In Make.com müsste ich für jeden Dokumenttyp einen eigenen Parser bauen — und selbst dann würde ein leicht abweichendes Format zum Fehler führen.

Ein AI Agent bekommt die Aufgabe: „Extrahiere Firmenname, Adresse, Geschäftsführer und Umsatzsteuer-ID.“ Er versteht, wonach er sucht — unabhängig davon, ob die Information in Zeile 3 oder Zeile 47 steht, ob das Label „Geschäftsführer“ oder „Managing Director“ heißt. Das ist kein Parsing. Das ist Verstehen.

Die unbequeme Wahrheit: Agents sind (noch) nicht perfekt

Wer jetzt denkt, man könne alle Make-Szenarien durch Agents ersetzen, liegt falsch. AI Agents haben reale Schwächen, die man kennen muss:

  • Kosten: Ein einfaches Make-Szenario kostet Bruchteile eines Cents pro Ausführung. Ein Agent-Aufruf mit einem großen Sprachmodell kann 5-50 Cent kosten — bei hohem Volumen summiert sich das schnell.
  • Latenz: Make.com verarbeitet einen Webhook in Millisekunden. Ein Agent braucht 10-60 Sekunden zum Nachdenken. Für zeitkritische Workflows ist das ein Problem.
  • Zuverlässigkeit: Agents können halluzinieren, Anweisungen kreativ interpretieren oder bei identischem Input unterschiedliche Ergebnisse liefern. Für Prozesse, die 100% Determinismus erfordern — etwa Buchhaltung oder Compliance — ist das ein ernstes Risiko.
  • Debugging: Wenn ein Make-Szenario fehlschlägt, sehe ich genau welches Modul und warum. Bei einem Agent ist die Fehlersuche oft eine Blackbox.

Die kluge Strategie ist deshalb nicht Entweder-oder, sondern ein hybrides Modell: Deterministische, hochvolumige Workflows bleiben in Make oder n8n. Alles, was Urteilsvermögen, Kontext oder Flexibilität erfordert, wandert zu Agents.

Der eigentliche Wandel

Der tiefere Punkt ist nicht technologisch — er ist konzeptionell. Make.com und n8n zwingen dich, in Flowcharts zu denken: Wenn dies, dann das, sonst jenes. AI Agents zwingen dich, in Aufgaben und Zielen zu denken: Was soll am Ende rauskommen? Das ist ein fundamental anderer Ansatz. Du beschreibst nicht mehr den Weg, sondern das Ziel. Der Agent findet den Weg selbst.

Für mich als jemand, der seit Jahren Automatisierungen baut, fühlt sich das an wie der Sprung von der Kommandozeile zur grafischen Oberfläche. Die alte Methode funktioniert noch. Aber sie ist nicht mehr die beste Antwort auf die meisten Fragen. Wer heute ausschließlich auf Make und n8n setzt, baut auf einem Paradigma, das seinen Zenit überschritten hat. Wer Agents in seinen Stack integriert, baut auf dem, was kommt.