Die meisten Unternehmen begegnen KI-Agenten erstmals über ein Tool, für das sie bereits bezahlen. Zapier hat AI Agents zur Plattform hinzugefügt. Make hat mit eigenen agentischen Szenariofunktionen nachgezogen. Beide sind tatsächlich nützlich — und beide haben Fehlermodi, die erst dann offensichtlich werden, wenn Sie einen Prozess betreiben, der wirklich zählt.
Dies ist eine Käuferbewertung, keine Produktrezension. Die Frage ist nicht, welche Plattform die bessere UX hat. Die Frage lautet: Welche Tool-Ebene ist bei den geschäftlichen Anforderungen Ihres Prozesses die rationale Wahl?
Warum “Agenten in jedem SaaS” die Kaufentscheidung erschwert
Automatisierungsplattformen, die “KI-Agenten” in ihr Produkt retrofitten, erzeugen ein Benennungsproblem. Das Wort “Agent” umfasst heute alles: von einem einfachen GPT-Prompt, der einen Notion-Eintrag umformatiert, bis hin zu einem zustandsbehafteten Mehrschrittsystem, das über externe APIs mit Recovery-Logik routet, entscheidet und handelt.
Die Plattformen lügen nicht — aber das Label verbirgt enorme Unterschiede in Zuverlässigkeit, Datenkontrolle, Kostenstruktur und Fehlerbehandlung. Ein Workflow, der ein LinkedIn-Update postet, wenn ein Blog live geht, gehört nicht zur gleichen Kategorie wie ein Agent, der eingehende Leads qualifiziert, Ihr CRM abfragt, eine personalisierte Antwort entwirft und das Ergebnis protokolliert. Wenn man sie als gleichwertig behandelt, wählt man das falsche Tool für die falsche Aufgabe.
Die drei Dimensionen, die für diese Entscheidung wirklich zählen:
- Ökonomie pro Ausführung — was kostet jeder Run, und wie skaliert das?
- Fehlermodi — wie verhält sich das System, wenn ein LLM-Aufruf schiefgeht, eine Drittanbieter-API langsam ist oder die Eingabedaten unordentlich sind?
- Datenkontrolle und Observability — wo landen Ihre Daten, und können Sie sehen, was der Agent tatsächlich getan hat?
Kosten pro Ausführung: wo Plattformkosten unvorhersehbar werden
Zapier und Make berechnen nach Operation oder Task-Verbrauch. Ein einfacher Zap mit einem Trigger und zwei Action-Steps kostet zwei Tasks — Trigger sind im Abrechnungsmodell von Zapier immer kostenlos. Ein “Agenten”-Run, der einen LLM aufruft, eine Tabelle abfragt, eine Slack-Nachricht sendet und einen CRM-Datensatz aktualisiert, kann zehn bis dreißig Operationen verbrauchen — je nachdem, wie er strukturiert ist — und das, bevor man die LLM-Tokenkosten berücksichtigt, die Plattformen typischerweise mit einem Aufschlag weitergeben.
Für einen geringvolumigen, risikoarmen Prozess — etwa 50 Runs pro Monat mit vorhersehbaren Eingaben — ist die Plattformpreisgestaltung völlig vertretbar. Sie zahlen für Deployment-Geschwindigkeit und null Infrastrukturaufwand. Das ist ein echter Mehrwert.
Die Ökonomie verändert sich, wenn:
- Das Volumen über einige Hundert bedeutungsvolle Runs pro Monat wächst
- Jeder Run mehrere LLM-Aufrufe umfasst (Retrieval, Klassifizierung, Generierung sind separate Aufrufe in den meisten Agentenmustern)
- Sie Retry-Logik benötigen, die Operationen erneut ausführt und den Verbrauch multipliziert
Ein konkretes Beispiel: Ein 10-köpfiges Vertriebsteam, das einen Zapier-basierten Agenten einsetzt, um 500 eingehende Formulareinreichungen pro Monat zu qualifizieren und weiterzuleiten, wobei jeder Run fünf Operationen und zwei LLM-Aufrufe berührt, könnte 5.000+ Tasks pro Monat plus LLM-Pass-through-Kosten verbrauchen. Bei diesem Volumen kostet ein custom gebauter Agent auf einer Cloud-Funktion nur einen Bruchteil pro Run — die variablen Kosten sind nur die direkten LLM-API-Ausgaben, typischerweise deutlich unter $0,01 pro Qualifizierungs-Run mit aktuellen Mid-Tier-Modellen (zur Referenz: GPT-4o mini ist mit $0,15 pro Million Input-Token und Claude Haiku mit $0,25 pro Million Input-Token Mitte 2026 bepreist).
Der Crossover-Punkt variiert je nach Anwendungsfall, aber für die meisten bedeutsamen agentischen Prozesse tritt er früher ein, als Käufer erwarten.
Wie Plattformagenten versagen — und warum es schwer vorherzusehen ist
Das tiefere Problem sind nicht die Kosten. Es ist, dass Zapier und Make für deterministische Workflows entwickelt wurden. Wenn Schritt A abgeschlossen ist, läuft Schritt B. Agenten sind nicht deterministisch — sie beinhalten LLM-Aufrufe, die unerwartete Formate, mehrdeutige Ausgaben oder direkte Fehler zurückgeben können. Die zugrunde liegenden Plattformen wurden nicht entwickelt, um das elegant zu handhaben.
In der Praxis äußert sich das als:
Stille Teilversagen. Ein Zap kann erfolgreich abgeschlossen werden, obwohl der LLM eine fehlerhafte Antwort zurückgegeben hat, weil der nachgelagerte Schritt einfach protokolliert, was er empfangen hat. Ihr CRM wird mit korrumpierten Daten aktualisiert, und Sie stellen es Wochen später fest.
Keine Retry-Intelligenz. Wenn ein API-Aufruf mitten im Run scheitert, stoppen die meisten plattformbasierten Agenten oder lösen einen generischen Fehler aus. Es gibt keine Logik, um den spezifisch fehlgeschlagenen Schritt zu wiederholen, ein Fallback-Modell zu verwenden oder einen menschlichen Prüfer für diesen spezifischen Fall zu benachrichtigen.
Debug-Tiefe. Die Debug-Sichtbarkeit variiert je nach Plattform. Zapier bietet Task-Level-Verlauf und Versions-Checkpoints. Das Reasoning Panel von Make (eingeführt im Februar 2026) liefert visuelle Schritt-für-Schritt-Traces der Agentenentscheidungen und Tool-Aufrufe. Keines der beiden erreicht die vollständige Observability eines custom gebauten Systems — Sie haben nicht den vollständigen LLM-Reasoning-Trace, rohe Token-Zählungen oder ein strukturiertes Audit-Log in dem von Ihnen definierten Format — aber der Abstand verringert sich. Für einen Prozess, der Kundendaten oder Finanzunterlagen berührt, sind selbst die verbesserten Plattformwerkzeuge möglicherweise nicht ausreichend.
Prompt- und Modellkontrolle. Plattformagenten variieren darin, wie viel Kontrolle sie freigeben. Sowohl Zapier als auch Make bieten mittlerweile Multi-Modell-Unterstützung und System-Prompt-Konfiguration; eine granulare Kontrolle über Modell-Versionierung und Inferenzparameter bleibt jedoch eingeschränkter als bei einem vollständig custom gebauten System. Wenn eine Plattform ihre zugrunde liegenden Modell-Defaults aktualisiert, kann sich das Verhalten Ihres Agenten ohne Vorwarnung ändern.
Für Prozesse, bei denen ein Fehler Geld kostet, eine Kundenbeziehung beschädigt oder regulierte Daten berührt, sind diese Fehlermodi von enormer Bedeutung.
Wo Plattformagenten die richtige Antwort sind
Um direkt zu sein: Zapier- und Make-Agenten sind in spezifischen Szenarien eine gute Wahl.
Gute Eignung:
- Prozesse, die weniger als einige Hundert Mal pro Monat laufen
- Risikoarme Content-Aufgaben: Formatierung, Zusammenfassung, interne Benachrichtigungen
- Teams ohne interne Entwicklungskapazität und echtem Bedarf, schnell voranzukommen
- Prototypen und Proof-of-Concepts, bei denen Iterationsgeschwindigkeit wichtiger ist als Produktionszuverlässigkeit
- Überbrückung von Lücken zwischen SaaS-Tools, die bereits Zapier-Integrationen haben
Wenn Sie eine fünfköpfige Beratung sind, die einen Agenten möchte, der Besprechungsnotizen mit Kunden aus Notion holt, sie zusammenfasst und eine Follow-up-E-Mail entwirft — Zapier oder Make werden einwandfrei funktionieren und Sie dort in einem Nachmittag hinbringen.
Das Problem entsteht, wenn ein Tool, das für seinen Komfort in einem risikoarmen Kontext gewählt wurde, zu einem hochriskanten Prozess befördert wird, weil “es bereits funktioniert”. Das ist der Weg zu stillen Versagen und unangenehmen Überraschungen.
Was “Custom” wirklich bedeutet — und wann es sich lohnt
“Custom” bedeutet nicht, von Grund auf neu ohne Abhängigkeiten zu beginnen. In der Praxis bedeutet es, auf offenen Agenten-Frameworks (LangGraph, CrewAI, benutzerdefinierte Orchestrierung) und Infrastruktur zu bauen, die Sie kontrollieren — statt innerhalb einer Automatisierungsplattform eines Drittanbieters.
Die Vorteile sind konkret:
- Vollständige Observability. Jeder LLM-Aufruf, jede Tool-Invokation und jede Entscheidung wird in einem von Ihnen definierten Format protokolliert. Sie können genau nachvollziehen, warum ein Agent eine bestimmte Aktion durchgeführt hat.
- Deterministische Fehlerbehandlung. Sie schreiben die Retry-Logik, die Fallback-Pfade, die Human-in-the-Loop-Trigger. Der Agent verhält sich nach Ihren Regeln, nicht nach dem generischen Error-Handler der Plattform.
- Daten bleiben, wo Sie es bestimmen. Custom-Agenten können in Ihrer Cloud-Umgebung oder on-premise laufen. Keine Kundendaten passieren Zapier- oder Make-Infrastruktur.
- Kosten skalieren linear mit der Nutzung, nicht exponentiell. Direkte LLM-API-Kosten sind vorhersehbar und typischerweise weit günstiger pro Run als Plattform-Pass-through-Preise bei hohem Volumen.
- Verhalten ist fixiert. Sie kontrollieren Modellversionen, Prompts und Update-Zyklen. Nichts ändert sich in Ihrem Agenten, weil ein SaaS-Anbieter ein Update eingespielt hat.
Der Trade-off ist real: Custom-Entwicklung erfordert längere Build-Zeit (Wochen, nicht Stunden), eine Spezifikation und einen fortlaufenden Verantwortlichen. Für wirklich hochriskante Prozesse — Kundenqualifikation, Extraktion von Finanzdaten, regulierte Kommunikation, Mehrschritt-Workflows, bei denen Fehler reale Kosten haben — amortisiert sich diese Investition typischerweise innerhalb weniger Monate. Für einfache interne Aufgaben ist es übertrieben.
Siehe Build vs Buy: ein Entscheidungsrahmen für KI-Agenten für einen strukturierten Ansatz, wann Custom-Entwicklung tatsächlich gerechtfertigt ist.
Eine praktische Entscheidungsmatrix
| Plattformagent (Zapier/Make) | Custom-Entwicklung | |
|---|---|---|
| Deployment-Geschwindigkeit | Stunden bis Tage | Wochen |
| Entwicklung erforderlich | Keine | Ja |
| Kosten pro Run bei hohem Volumen | Hoch (Task + Aufschlag) | Niedrig (direkte API) |
| Fehler-Transparenz | Begrenzt | Vollständig |
| Datenkontrolle | Plattform-gehostet | Sie kontrollieren |
| Prompt-/Modell-Fixierung | Begrenzt | Vollständig |
| Geeignet für | Geringes Volumen, intern, geringes Risiko | Hohes Volumen, kundenseitig, hohes Risiko |
| Ungeeignet für | Komplexe Logik, regulierte Daten, hohes Volumen | Schnelles Prototyping, keine Entwicklungsressourcen |
Diese Matrix vereinfacht, aber die zugrunde liegende Logik hält stand: Die Wahl sollte den Anforderungen des Prozesses folgen, nicht der Bequemlichkeit des Toolings.
Für mehr dazu, wo No-Code-Plattformen an strukturelle Grenzen stoßen, behandelt Wenn No-Code-KI-Agent-Builder an ihre Grenzen stoßen die Muster, die wir am häufigsten sehen.
Das Kostenbild über 12 Monate
Käufer vergleichen oft die Build-Kosten (Custom ist initial teurer), ohne das Gesamtbild zu modellieren. Ein einmal gebauter Custom-Agent, der ein Jahr lang läuft, verglichen mit einer Plattformlösung, die bei bedeutendem Volumen CHF X/Monat kostet, sieht oft im sechsten Monat sehr anders aus.
Die Variablen, die die Kalkulation kippen:
- Monatliches Run-Volumen
- Durchschnittliche Operationen pro Run
- Ob der Prozess wachsen wird (Volumen bleibt selten konstant)
- Die Kosten eines Fehlerereignisses (ein einziger schlechter Run, der ein falsches Angebot an 200 Kunden sendet, verändert die Mathematik vollständig)
Für eine ausgearbeitete Berechnung, wie diese Zahlen tatsächlich zusammenkommen, geht Die tatsächlichen Kosten von KI-Agenten: Custom vs Platform TCO tiefer in das Gesamtkostenmodell.
Die eigentliche Frage für Ihren spezifischen Prozess
Wenn ein Kunde zu uns kommt mit “wir denken daran, das in Zapier zu bauen”, fragen wir als erstes nicht nach dem Tool. Sondern: Was kostet ein schlechter Run? Wie hoch ist das erwartete monatliche Volumen in zwölf Monaten, nicht heute? Gehören einige der verarbeiteten Daten Kunden?
Diese drei Fragen lösen die Entscheidung in der Regel schneller als jeder Funktionsvergleich.
Wenn Ihre Antworten auf einen Plattformagenten hindeuten — nutzen Sie einen. Es sind gute Tools für das, wofür sie entwickelt wurden. Wenn Ihre Antworten auf etwas mit echten Anforderungen und Volumen hindeuten, wird Plattformautomatisierung wahrscheinlich technische Schulden und operationelle Risiken erzeugen, die den Deployment-Komfort überwiegen.
Unsere Arbeit in der KI-Agenten-Entwicklung beginnt typischerweise mit genau dieser Art von Scoping: Wir analysieren den Prozess, die Daten, die Fehlertoleranz und das Kostenmodell, bevor wir einen Ansatz empfehlen. Manchmal lautet die Antwort “behalten Sie Zapier dafür.” Oft nicht.
Wenn Sie eine Automatisierung bewerten, die über die “Proof of Concept”-Phase hinausgegangen ist, und eine ehrliche Einschätzung wünschen, ob die Tool-Ebene den tatsächlichen Anforderungen entspricht, buchen Sie ein 30-minütiges Gespräch mit uns. Wir analysieren den spezifischen Prozess, das Kostenmodell, und sagen Ihnen klar, welcher Ansatz sinnvoll ist — auch wenn das bedeutet, bei der aktuellen Lösung zu bleiben. Kein Pitch, nur die Analyse.