AI-Agent gegen Zapier, Make und n8n: worin der Unterschied liegt und was Sie wählen
Die Frage klingt fast immer gleich: „Ich habe Zapier bereits eingerichtet, wozu brauche ich einen Agenten?“ Und das ist die richtige Frage. Die Hälfte dessen, was heute als AI-Agent verkauft wird, sind gewöhnliche Szenarien mit einem Sprachmodell in einem der Schritte.
Es gibt einen Unterschied, er ist grundsätzlich, und er besteht nicht darin, dass der Agent „klüger“ wäre.
Wie ein Szenario aufgebaut ist
Zapier, Make und n8n sind aus derselben Idee gewachsen: auf ein Ereignis warten und eine im Voraus gezeichnete Abfolge von Aktionen ausführen. Eine Mail mit Anhang kommt an — Datei im Ordner ablegen, Zeile in der Tabelle anlegen, Benachrichtigung in den Kanal schicken.
Agentenmodi haben inzwischen alle drei — Zapier Agents, Make AI Agents, die AI-Agent-Node in n8n. Ehrlicher ist deshalb der Vergleich nicht zweier Produkte, sondern zweier Arten, Arbeit zu organisieren: Route und Ziel. Darum geht es im Folgenden.
Das Schlüsselwort lautet im Voraus. Sie haben die Route beschrieben, und das System läuft sie ab. Jedes Mal gleich.
Das ist ein enormer Vorzug. Ein Szenario:
- läuft vorhersagbar: bei gleichem Input kommt Byte für Byte derselbe Output heraus;
- kostet Bruchteile eines Cents pro Vorgang und hält Tausende Durchläufe pro Stunde aus;
- lässt sich leicht prüfen — man sieht, welcher Schritt gelaufen und welcher gescheitert ist;
- erfindet nichts.
Wenn sich die Aufgabe als „wenn X passiert, mach immer Y“ formulieren lässt, ist das Szenario das richtige Werkzeug, und ein Agent wäre dort teurer und schlechter. Eine Zahlung aus Stripe in die Buchhaltung übernehmen, eine Benachrichtigung über eine neue Anfrage, zwei Tabellen synchron halten — das ist Zapiers Terrain, und es gibt keinen Grund, es ihm wegzunehmen.
Wo ein Szenario bricht
Die Probleme fangen dort an, wo der Input aufhört, gleich zu sein.
Das Format verrutscht. Der Kunde hat keine Rechnung als PDF geschickt, sondern ein Foto der Rechnung, schräg und bei schlechtem Licht aufgenommen. Ein Szenario kann nicht „verstehen, was das ist“. Es kann „das Feld amount nehmen“. Kein Feld — Zweig gescheitert.
Es braucht eine Entscheidung, keine Aktion. „Wenn der Betrag über zehntausend Euro liegt, zur Freigabe“ lässt sich als Bedingung beschreiben. „Wenn der Kunde in der Mail Unmut äußert, keine automatische Antwort schicken, sondern einen Menschen holen“ nicht. Unmut steht in keinem Feld.
Mehr Verzweigungen, als sich zeichnen lassen. Jede Ausnahme ist ein neuer Zweig. Ein halbes Jahr später hat das Schema zweihundert Blöcke, und niemand traut sich mehr daran, der Urheber eingeschlossen. Ein bekanntes Bild: Es ist einfacher, daneben ein neues Szenario anzulegen, als das alte zu durchdringen.
Allen drei Fällen ist eines gemeinsam: Die Wirklichkeit war reicher als das Schema, und das Schema kann sich nicht selbst erweitern.
Was ein Agent anders macht
Einem Agenten geben Sie keine Route, sondern ein Ziel und Grenzen. „Bearbeite eingehende Dokumente: bestimme, was es ist, leg es dorthin, wo es hingehört, und was fehlt, frag beim Kunden nach. Wenn du unsicher bist, rate nicht, sondern gib es an mich.“
Von da an entscheidet er selbst, welche Schritte der konkrete Fall braucht. Das schräge Foto liest er. Liest er es nicht, sagt er, was genau er nicht entziffern konnte, und bittet um eine neue Aufnahme. Kommt etwas Unerwartetes, beschreibt er es in eigenen Worten und gibt es an Sie weiter, statt mit einem Fehler abzubrechen.
Der praktische Unterschied: Ein Szenario bearbeitet die Fälle, die Sie vorgesehen haben, ein Agent auch die übrigen — entweder er erledigt sie, oder er hebt ehrlich die Hand.
Die Kehrseite
Hier beginnt das, worüber die Werbung für Agenten schweigt.
Nicht-Determinismus. Bei ähnlichem Input liefert ein Agent ein ähnliches, aber kein identisches Ergebnis. Beim Sortieren von Dokumenten ist das egal. Bei der Lohnabrechnung ist es so wichtig, dass ein Agent dort nichts zu suchen hat.
Die Prüfung ist aufwendiger. Im Szenario sieht man: Schritt 4 ist gescheitert. Beim Agenten muss man nachsehen, was er entschieden hat und warum. Ein gutes Produkt zeigt den Gedankengang Schritt für Schritt, aber das bleibt Lesen von Text statt ein Blick auf ein Schema.
Teurer pro Vorgang. Nicht um Größenordnungen, aber der Unterschied zwischen einem Modellaufruf und einem HTTP-Request ist real. Bei zehntausend gleichartigen Durchläufen am Tag fällt er auf.
Schablonen bei gleichen Daten. Geben Sie einem Agenten dieselben Vorgaben, kommt dasselbe Ergebnis heraus — das ist seine Eigenschaft, kein Defekt. Wir haben den Fall beschrieben, in dem eine Agentur feststellte, dass drei von sechs Strategien sich ähneln, weil sie nach demselben Schema aus ähnlichem Material gebaut waren.
Wie Sie wählen
Die brauchbare Regel ist einfach.
Nehmen Sie ein Szenario, wenn der Input immer dasselbe Format hat, sich die Entscheidung als Bedingung beschreiben lässt, das Volumen groß ist und der Preis eines Fehlers in einem Durchlauf niedrig.
Nehmen Sie einen Agenten, wenn der Input von Menschen kommt und deshalb unterschiedlich ausfällt, der Sinn zählt und nicht das Feld, es mehr Ausnahmen als Regeln gibt und das Volumen bei Dutzenden am Tag liegt statt bei Tausenden pro Stunde.
Eine Hilfsformulierung: Versuchen Sie, die Aufgabe mit „wenn … dann …“ zu beschreiben. In drei Sätzen geschafft — das ist ein Szenario. Sie mussten schreiben „na ja, normalerweise so, aber es kommt vor, dass es anders läuft, und dann muss man hinsehen“ — das ist ein Agent.
Gesondert zu n8n
Der Vergleich mit n8n fällt weniger sauber aus als der mit Zapier, und das sollte man offen sagen.
Erstens lässt es sich bei Ihnen selbst betreiben. Der Quellcode ist offen, die Lizenz aber im strengen Sinn nicht: Es ist die Sustainable Use License, „fair-code“ — im eigenen Unternehmen nutzen ist erlaubt, weiterverkaufen nicht. Beim Selbstbetrieb gehen die Daten nicht über einen Vermittler, und eine Gebühr pro Auslösung fällt gar nicht erst an. Eine Cloud hat n8n ebenfalls, und dort wird pro Ausführung abgerechnet.
Zweitens ist die Agenten-Node in n8n vollwertig: An sie lässt sich ein Speicher anschließen, und auf Postgres oder Redis übersteht dieser Neustarts. Die Grenze, um die es im ganzen Artikel geht, verläuft also bereits innerhalb von n8n.
Ein praktischer Unterschied bleibt, und er betrifft nicht die Möglichkeiten.
Wer die Konstruktion baut. In n8n entwerfen und pflegen Sie den Ablauf: Nodes, Verbindungen, Zweige, Fehlerbehandlung, Speicher und das, was darin liegt. Genau für diese Arbeit stellt man einen Integrator ein. Bei uns entsteht die Konstruktion im Gespräch in 15–30 Minuten, und danach passen Sie sie an: günstiger am Anfang, weniger flexibel an der Grenze.
Wenn jemand in Ihrem Team n8n mag und es bereits aufgesetzt hat, ist das eine starke Position, und Sie brauchen einen Agenten nicht anstelle davon, sondern darüber: an der Stelle, an der die Node mit uneinheitlichem Input nicht mehr zurechtkommt.
Man muss sie nicht gegeneinander stellen
In der Praxis funktioniert die Kombination besser als jedes der beiden für sich. Das Szenario macht, was es gut macht: Ereignis abfangen, API aufrufen, Daten übertragen. Der Agent übernimmt den Abschnitt, an dem man das Eingehende verstehen und entscheiden muss, was damit geschieht.
Die typische Aufteilung beim externen Buchhalter: Ein Szenario holt den Kontoauszug und legt die Transaktionen im System ab — das ist Mechanik, dafür braucht es keinen Agenten. Der Agent bearbeitet, was Mandanten in den Messenger schicken, denn dort sind Fotos, Sprachnachrichten und „braucht ihr das wirklich?“.
Was unterm Strich bleibt
Ein Agent ist kein verbesserter Zapier. Er ist ein anderes Werkzeug für eine andere Klasse von Aufgaben: dort, wo der Input uneinheitlich ist und die Arbeit Urteilsvermögen verlangt.
Und der ehrliche Schluss: Wenn sich Ihre Abläufe bereits gut als Szenarien beschreiben lassen und diese nicht scheitern, brauchen Sie höchstwahrscheinlich keinen Agenten. Gebraucht wird er dort, wo Automatisierung bisher gerade deshalb nicht gezündet hat, weil sich die Aufgabe nicht auf „wenn … dann …“ reduzieren ließ.