KI-Agenten vs. Make.com: Visual Workflows oder autonome Logik?

Make.com ist eine visuelle Automatisierungsplattform, die es Unternehmen erlaubt, Workflows zwischen verschiedenen Cloud-Diensten ohne klassische Programmierung zu erstellen. Nutzer bauen sogenannte „Szenarios“ aus vorgefertigten Modulen zusammen – jedes Modul repräsentiert eine Aktion in einem externen System wie Google Sheets, HubSpot, Slack, Stripe oder OpenAI. Verbunden werden die Module über visuelle Linien, die den Datenfluss von Trigger über Routing-Logik bis zur finalen Aktion abbilden.

Die Stärke des Tools liegt in der Breite: Über 1.500 Konnektoren stehen zur Verfügung, die alle gängigen SaaS-Tools abdecken. Für klassische Integrationsaufgaben – „wenn ein neuer Lead in HubSpot, dann eine Slack-Nachricht ins Sales-Channel und einen Eintrag in Google Sheets“ – ist Make in wenigen Minuten produktiv. Das Pricing skaliert mit der Anzahl der ausgeführten „Operations“ (jeder Modul-Aufruf zählt), was bei niedrigem Volumen sehr günstig, bei hohem Datenfluss aber schnell teuer werden kann.

Make positioniert sich als „Visual Automation Platform“ und nicht als KI-Plattform. Auch wenn sich OpenAI- oder Anthropic-Module einbinden lassen, ist Make primär ein Werkzeug zum visuellen Verdrahten von APIs. Reasoning-Logik, autonome Entscheidungen oder das Umgehen mit unstrukturierten Eingaben sind nicht das Kernfeature, sondern bestenfalls Zusatzfunktionen.

KI-Agenten verfolgen ein anderes Architekturparadigma. Statt einen Workflow visuell festzulegen, beschreibt man dem Agenten ein Ziel und stellt ihm eine Reihe von Werkzeugen (Tool-Aufrufen) zur Verfügung. Der Agent entscheidet auf Basis seines Reasoning-Layers selbständig, in welcher Reihenfolge welche Tools genutzt werden sollen, um das Ziel zu erreichen. Der „Workflow“ entsteht zur Laufzeit, nicht im visuellen Editor zur Designzeit.

Das hat tiefgreifende Konsequenzen. Ein Make-Szenario muss für jeden möglichen Pfad explizit ausmodelliert werden: Was passiert, wenn der Lead aus einer bestimmten Branche kommt? Was, wenn die E-Mail-Antwort ungewöhnlich formuliert ist? Was, wenn die API-Antwort zwei statt einem Treffer liefert? Jede dieser Verzweigungen wird als zusätzliches Modul oder Router angelegt. Mit der Zeit entstehen so „Szenario-Spaghetti“, die niemand mehr überblickt.

Ein KI-Agent nimmt diese Variabilität von Haus aus auf: Sein Reasoning-Layer kann aus einer ungewöhnlich formulierten E-Mail die Absicht extrahieren, aus zwei API-Treffern den richtigen auswählen, und bei einer unbekannten Branche eine plausible Klassifikation treffen. Statt jeden Edge Case zu modellieren, wird die Logik darauf trainiert, mit Varianz umzugehen. Das ist langsamer im Setup, aber drastisch günstiger im Betrieb.

Make-Szenarios folgen einer linearen oder verzweigten Topologie: Ein Trigger startet den Flow, die Daten wandern durch Module, Routing-Logik verzweigt nach Bedingungen, und am Ende stehen eine oder mehrere Aktionen. Jeder Pfad muss vom Designer vorgesehen sein. Was nicht modelliert wurde, kann nicht passieren – im positiven wie im negativen Sinne.

KI-Agenten arbeiten mit dem ReAct-Pattern (Reasoning + Acting): Der Agent beobachtet die aktuelle Situation, plant einen nächsten Schritt, ruft ein Tool auf, beobachtet das Ergebnis, plant erneut. Dieser Loop läuft so lange, bis das Ziel erreicht oder ein Abbruchkriterium getroffen ist. Die Pfade entstehen erst zur Laufzeit, sie sind nicht vorab modelliert.

In der Praxis bedeutet das: Wenn sich Geschäftsregeln ändern, Dokumentformate variieren oder neue Edge Cases auftreten, muss in Make das Szenario angepasst werden. Beim KI-Agenten reicht es oft, die Tool-Beschreibungen oder die System-Prompts zu erweitern. Operative Wartung verschiebt sich vom „Bauen“ zum „Anpassen“.

Stellen Sie sich vor, ein potenzieller Kunde füllt auf Ihrer Website ein Kontaktformular aus. In Make würde der Workflow typischerweise so aussehen: Webhook empfängt das Formular, ein OpenAI-Modul klassifiziert grob das Anliegen, ein Router verzweigt nach Use-Case, ein HubSpot-Modul legt den Kontakt an, ein Slack-Modul informiert den Account Manager, ein Gmail-Modul versendet eine vorbereitete Antwort. Soweit, so klassisch.

Was passiert aber, wenn das Anliegen nicht eindeutig klassifizierbar ist? Wenn der Interessent nach einer Lösung fragt, die Sie zwar haben, aber unter anderem Namen vermarkten? Wenn das Unternehmen bereits Kunde ist, sich aber mit einer neuen E-Mail-Adresse meldet? Wenn die Anfrage in einer Sprache eingeht, die Ihr Standard-Antwort-Set nicht abdeckt? Für jede dieser Fragen braucht Make zusätzliche Module, neue Verzweigungen, weitere Logikbausteine.

Ein KI-Agent erledigt denselben Vorgang anders: Er nimmt die Eingabe entgegen, prüft den Bestand im CRM (auch über Mail-Aliase und Domain-Matching), klassifiziert das Anliegen anhand des Produkt-Katalogs (auch wenn Begriffe nicht exakt passen), entscheidet kontextbasiert, welche Antwort sinnvoll ist, formuliert sie in der Sprache des Interessenten und löst – nur wenn nötig – die Eskalation an einen Mitarbeiter aus. Was im Make-Szenario zehn Module und drei Router benötigt, ist im Agenten ein einziger Vorgangs-Workflow mit klaren Tool-Definitionen.

Im Kundenservice zeigt sich der Unterschied besonders deutlich. Ein Make-Szenario kann eingehende Tickets nach Schlüsselwörtern an die richtige Warteschlange routen, eine Eingangsbestätigung schicken und ggf. eine SLA-Eskalation triggern. Was es nicht zuverlässig kann: den Kontext einer Reklamation verstehen, vergangene Interaktionen einbeziehen, eine sinnvolle Erstantwort formulieren oder eine Lösung anbieten, ohne dass ein Mensch den Vorgang öffnet.

Ein KI-Service-Agent übernimmt den gesamten Vorgang: Eingangs-E-Mail wird gelesen, Kunde wird im CRM identifiziert, Bestellhistorie wird abgerufen, Garantie- und Rückgabe-Bedingungen werden geprüft, eine konkrete Lösung wird vorgeschlagen, der Vorgang wird im Helpdesk-System dokumentiert und – falls eine Mitarbeiter-Entscheidung nötig ist – mit voller Vorgangs-Akte zur Freigabe übergeben. Der Service-Mitarbeiter steigt nicht mehr bei null ein, sondern entscheidet auf Basis eines vorbereiteten Vorgangs.

Make kann hier ergänzend Sinn machen, etwa um den Eingangs-Webhook aus dem Helpdesk in den Agenten zu routen oder um Side-Effects wie Slack-Benachrichtigungen oder Stripe-Erstattungen anzustoßen. Die Kernlogik – das Verstehen und Entscheiden – sollte beim Agenten liegen.

Make-Szenarios skalieren über die Anzahl der Module und Routing-Pfade. Ein Szenario, das anfangs aus 5 Modulen bestand, hat nach einem Jahr in der Praxis oft 30 oder mehr Module – jede Änderung der Geschäftsregeln führt zu einer neuen Verzweigung. Das ist nicht per se schlecht, erzeugt aber strukturelle Komplexität. Fehlerbehandlung ist ebenfalls explizit zu modellieren: Was passiert, wenn die HubSpot-API ausfällt? Was, wenn die OpenAI-Antwort leer ist?

KI-Agenten skalieren über Tool-Beschreibungen und Reasoning-Anweisungen. Eine neue Geschäftsregel wird oft als zusätzlicher Hinweis im System-Prompt oder als neue Tool-Beschreibung umgesetzt – kein neues Szenario, keine neue Verzweigung. Fehlerbehandlung ist auch hier nötig, lässt sich aber generischer formulieren: „Wenn ein Tool-Aufruf fehlschlägt, versuche eine alternative Methode oder eskaliere mit Kontext an einen Mitarbeiter.“

Im Betrieb zeigt sich der Unterschied bei Logging und Audit. Make liefert pro Modul ein detailliertes Execution-Log, was bei der Fehlersuche hilft. KI-Agenten brauchen ein eigenes Audit-Logging, das den vollständigen Reasoning-Pfad inklusive aller Tool-Aufrufe protokolliert – ein Punkt, der bei der Implementierung von Anfang an mitgeplant werden muss.

Make berechnet pro Operation: jeder Modul-Aufruf zählt, mit gestaffelten Tarifen ab ca. 9 € pro Monat (kostenlose Stufe verfügbar) bis 29 € im Pro-Tarif für 10.000 Operations und mehr je nach Volumen. Bei großen Datenmengen oder hochfrequenten Triggern können monatliche Kosten von mehreren hundert Euro entstehen, ohne dass die Lösung qualitativ wächst.

KI-Agenten werden meist nach Use-Case-Pauschale oder nach LLM-Token-Verbrauch berechnet. Ein produktiver Agent kostet typischerweise 2.000 € bis 5.000 € pro Monat (inkl. Hosting, Wartung und LLM-Kosten), je nach Komplexität und Volumen. Auf den ersten Blick teurer als Make – aber wenn der Agent einen kompletten Vorgang ersetzt, der zuvor mehrere Make-Szenarios und ein halbes Mitarbeiter-FTE band, ist die TCO-Bilanz deutlich besser.

Im Total Cost of Ownership lohnt es sich, drei Faktoren mitzurechnen: erstens die Lizenzkosten (oft am offensichtlichsten), zweitens die Wartungskosten (bei Make über die Zeit steigend, bei Agenten weitgehend konstant), drittens die opportunen Personalkosten (was würden Mitarbeiter ohne die Lösung tun und was kostet das?). Erst wenn alle drei Faktoren bewertet sind, lässt sich die wirtschaftlich richtige Wahl treffen.

Make bietet EU-Region-Hosting an, was für viele Standardfälle ausreichend ist. Allerdings rufen viele der 1.500+ Konnektoren US-APIs auf (HubSpot, Slack, OpenAI etc.). Wer DSGVO-konform mit personenbezogenen Daten arbeitet, muss daher nicht nur Make selbst, sondern auch jedes nachgelagerte Modul prüfen und ggf. einen Auftragsverarbeitungsvertrag mit den jeweiligen Anbietern schließen.

KI-Agenten lassen sich vollständig in deutscher oder europäischer Infrastruktur betreiben. Statt eines US-LLMs kann ein in Europa gehostetes Modell (Mistral, Llama in eigener Cloud) genutzt werden. Datenflüsse zu Drittsystemen werden bewusst gesteuert und können auf das Notwendige reduziert werden. Audit-Logging und rollenbasierte Zugriffe sind elementar Teil der Architektur.

Für regulierte Branchen (Finanzen, Versicherungen, Gesundheit) ist die Wahl daher meist eindeutig: Wo dokumentierte Compliance, Datenresidenz und nachvollziehbare Entscheidungen gefordert sind, hat ein selbst betriebener KI-Agent strukturelle Vorteile gegenüber einer SaaS-Visual-Plattform.

Make ist die richtige Wahl für drei klar definierte Szenarien. Erstens: Klassische Cloud-zu-Cloud-Integrationen ohne komplexe Logik – „neuer Stripe-Zahlungsempfang → Slack-Nachricht → Eintrag in Google Sheets → Buchung in DATEV“. Hier liefert Make in Stunden Ergebnisse, die ein KI-Agent nicht messbar besser machen würde.

Zweitens: Marketing- und Operations-Automatisierung mit standardisierten Triggern und Aktionen, etwa Newsletter-Anmeldungen in mehreren Tools synchronisieren, Webinar-Anmeldungen ins CRM übertragen, Social-Media-Posts terminieren. Klassische iPaaS-Disziplin.

Drittens: Schnelle Prototypen, mit denen Geschäftsbereiche erste Automatisierungs-Hypothesen testen, bevor in eine produktive Architektur investiert wird. Was sich in einem Make-Szenario bewährt, kann später konsolidiert in einen Agenten überführt werden – Make wird zum Sandbox-Tool, der Agent zur produktiven Lösung.

Sobald Vorgänge unstrukturierte Eingaben verarbeiten müssen (E-Mails, PDFs, Sprachnachrichten), sobald Entscheidungen kontextbasiert getroffen werden, sobald die Variabilität der Eingaben hoch ist oder sobald die Logik regelbasiert mit Geschäftslogik verschachtelt wird, sind KI-Agenten strukturell überlegen. Das gilt insbesondere für Vertriebs-, Service-, HR- und Dokumentenprozesse.

Ein typisches Anzeichen, dass Sie aus Make „herausgewachsen“ sind: Ihre Szenarios werden so groß, dass nur noch ein Spezialist sie überblickt. Änderungen ziehen sich durch zahlreiche Routing-Pfade. Edge Cases führen regelmäßig zu Fehlerbehandlungs-Modulen, die selbst wieder gewartet werden müssen. Die Operations-Kosten skalieren mit dem Volumen, ohne dass die Qualität entsprechend wächst.

In dieser Phase lohnt sich der Umstieg auf eine Agenten-Architektur. Häufig bleibt Make in einer ergänzenden Rolle erhalten – als reiner Eingangs-Trigger oder als Side-Effect-Layer für simple Aktionen. Die Kernlogik wandert in den Agenten und damit in eine Architektur, die mit Geschäftsentwicklung mitwächst, statt linear an Komplexität zu gewinnen.

Make.com und KI-Agenten sind keine Konkurrenten in jedem Anwendungsfall – sie adressieren unterschiedliche Klassen von Problemen. Make brilliert bei strukturierten, gut definierten Cloud-zu-Cloud-Workflows. KI-Agenten brillieren bei variablen, kontext-abhängigen Vorgängen, in denen Reasoning-Logik echten Mehrwert schafft.

Die Frage ist also nicht „Welches Tool ist besser?“, sondern „Welcher Vorgang welcher Charakteristik liegt vor?“. In vielen mittelständischen IT-Landschaften finden sich beide Welten gleichzeitig wieder. Die Aufgabe besteht nicht darin, eine Lösung gegen die andere auszuspielen, sondern jeden Use Case der jeweils passenden Architektur zuzuordnen – und dort, wo Make-Szenarios operativ erdrückend werden, gezielt auf Agenten umzustellen.

Wer heute eine Automatisierungs-Strategie aufsetzt, sollte für jeden geplanten Use Case eine bewusste Architektur-Entscheidung treffen. Die wichtigsten Kriterien sind Eingabe-Variabilität, Entscheidungs-Komplexität, Häufigkeit von Geschäftsregel-Änderungen und Datenschutz-Anforderung. Wer alle vier ehrlich bewertet, kommt meist zu einer klaren Antwort.