KI-Agent vs. Make: Wofür die beiden Werkzeuge sind

Make und KI-Agents lösen unterschiedliche Probleme. Make führt Workflow-Abläufe zuverlässig aus, wenn die Eingaben vorhersehbar und die Schritte fest definiert sind. Ein KI-Agent liest Kontext, verarbeitet Variationen und entscheidet selbstständig, was zu tun ist. Unternehmen, die Make durch einen Agent für den falschen Aufgabentyp ersetzen, erhalten eine weniger zuverlässige Automatisierung. Die entscheidende Frage ist nicht, welches Werkzeug besser ist — sondern welche Aufgabe zu welchem Werkzeug gehört.

Eine Operations-Leitung in einem sechsköpfigen Beratungsunternehmen migriert den Kunden-Intake-Workflow von Make zu einem KI-Agent, weil die Demos beeindruckend wirken. Zwei Wochen später hat jede Intake-Bestätigungs-E-Mail leicht unterschiedliche Formatierungen — minimale Formulierungsvariationen, inkonsistente Feldnamen, gelegentliche Tondrift. Make hatte dieselbe E-Mail jedes Mal fehlerfrei gesendet. Der Agent war leistungsfähiger. Er war für diese spezifische Aufgabe schlechter geeignet. Das Problem war nicht der Agent. Die Aufgabe war das falsche Werkzeug.

Make vs. KI-Agent: Direkter Vergleich

Der Vergleich ergibt nur auf Aufgabenebene Sinn — beide Tools können Aktionen auslösen, beide verbinden sich mit externen Systemen, beide automatisieren Arbeit. Was sie nicht können, ist Rollen zu tauschen, ohne die Ergebnisse zu verschlechtern.

	Make	KI-Agent
Entscheidungslogik	Nur vorkonfigurierte Verzweigungen	Liest Kontext und entscheidet zur Laufzeit
Verarbeitet unstrukturierte Eingaben	Nein — überspringt oder gibt Fehler aus	Ja
Ausgabe-Konsistenz	Deterministisch — immer gleich	Variabel — passt sich dem Input an
Einrichtungszeit	Stunden bis Tage	2–8 Wochen
Bester Aufgabentyp	Strukturierte Datenflüsse, geplante Auslöser	Variable, kontextabhängige Aufgaben
Preisgestaltung	9–29 $/Monat (nach Credit-Volumen)	200–750 $/Monat Infrastruktur + API
Wartung	Gering — außer wenn sich die Workflow-Struktur ändert	Mittel — Prompt-Updates, Integrations-Drift
Fehlerverhalten	Stille Übersprünge oder Fehler bei unerwarteten Eingaben	Falsche Entscheidung bei mehrdeutigen Eingaben
Native Integrationen	3.000+ Apps⁶	Pro Deployment aufgebaut

Der Preisvergleich braucht Kontext. Make berechnet Credits — die Abrechnungseinheit für Modulausführungen — mit 10.000 Credits im 9-$-Core-Plan pro Monat.⁵ Ein KI-Agent berechnet Infrastruktur und API-Nutzung unabhängig davon, wie viele Elemente er verarbeitet. Bei hochvolumigen, strukturierten Aufgaben ist Make deutlich günstiger. Bei variablen Aufgaben, für die Make Hunderte benutzerdefinierter Verzweigungen bräuchte, ist der Agent die einzig praktikable Option.

Make automatisiert die Abläufe, die Sie bereits kartiert haben

Make.com ist ein visueller Workflow-Builder. Wenn ein Trigger auslöst — eine Formularübermittlung, ein Webhook, ein neuer CRM-Datensatz — führt Make die konfigurierte Modulsequenz aus. Der Output ist deterministisch: Derselbe Input erzeugt immer denselben Output. Make liest keinen Kontext, passt sich keinen Variationen an und trifft keine Entscheidungen. Make prüft eine Bedingung und führt aus.

Die Canvas-Architektur von Make erfordert, dass jeder Entscheidungsast im Voraus konfiguriert wird. Wenn Daten in einem Format ankommen, das nicht konfiguriert wurde, überspringt Make das Element stillschweigend oder gibt einen Fehler aus. Wenn eine neue Workflow-Variante auftritt, ist ein neuer Modulpfad erforderlich. Jede Route durch den Canvas muss explizit abgebildet sein, bevor der Workflow läuft.

Das ist keine Einschränkung — es ist das Design. Determinismus ist das, was Make für strukturierte Aufgaben zuverlässig macht. Eine Stripe-Zahlung erstellt immer denselben Notion-Eintrag. Eine Typeform-Übermittlung erstellt immer denselben HubSpot-Kontakt. Diese Konsistenz ist genau deshalb wertvoll, weil Make keine Variation einführt.

Make erfordert, dass jeder Ast vor dem Workflow-Start definiert wird. Wenn Daten in einem nicht konfigurierten Format ankommen, überspringt Make sie stillschweigend oder gibt einen Fehler aus. Ein KI-Agent liest die Daten und entscheidet selbstständig — kein vorab definierter Ast erforderlich.

Laut Gartner-Daten, die von Prefactor zitiert werden, werden 40 % der Unternehmensanwendungen bis Ende 2026 aufgabenspezifische KI-Agents einbetten, gegenüber weniger als 5 % im Jahr 2025.[¹] Das Wachstum spiegelt eine echte Arbeitsteilung wider — nicht Agents, die Workflow-Tools ersetzen, sondern Agents, die die Aufgabentypen übernehmen, für die Workflow-Tools nie konzipiert waren.

Make erfordert jeden Ast im Voraus kartiert

Der Router von Make braucht für jeden Fall einen definierten Pfad, bevor das Szenario läuft — Enterprise-Lead hier, SMB-Lead dort, alles andere übersprungen oder mit Fehler abgebrochen. Ein KI-Agent liest den Input, sobald er eintrifft, und entscheidet, welche Aktion passt — ohne dass ein Router-Pfad im Voraus existieren muss. Die vollständige Aufschlüsselung, wann ein Workflow Regeln und wann er Urteilsvermögen braucht, finden Sie unter KI-Agent vs. Automatisierung.

Aus welchen Bausteinen besteht ein Make-Szenario?

Ein Make-Szenario besteht aus fünf wiederkehrenden Elementen: Modulen, Routern, Iteratoren, Aggregatoren und einem Data Store.² Zu wissen, was jedes Element tatsächlich tut, erklärt sowohl, worin Make stark ist, als auch, wo sein Canvas an eine Grenze stößt.

Element	Was es tut	Wo es an seine Grenze stößt
Modul	Führt eine Aktion in einer verbundenen App aus	Läuft zuverlässig; kann Absicht nicht aus Inhalt schließen
Router	Teilt das Szenario in vorab gebaute Verzweigungen	Braucht für jeden Fall vorab eine definierte Verzweigung
Iterator	Wandelt ein Array in ein Bundle pro Element um²	Verbraucht einen Credit pro Element — Kosten skalieren mit dem Volumen
Aggregator	Führt Bundles zu einem einzigen Output zusammen²	Braucht eine feste Zusammenführungsregel, keine Bewertung
Data Store	Speichert Datensätze, die das Szenario mitten im Lauf liest und schreibt	Nur strukturierte Felder — keine freie Texterschließung
Fehlerbehandlung	Wendet eine von fünf festen Regeln an, wenn ein Modul fehlschlägt⁴	Folgt der Regel; erkennt nicht, warum das Modul fehlschlug

Module verbinden sich mit einer App und führen eine Aktion aus — einen HubSpot-Kontakt erstellen, eine Slack-Nachricht senden, eine Notion-Seite aktualisieren. Jedes läuft der Reihe nach entlang des Canvas.

Router teilen ein Szenario anhand einer Bedingung in parallele Routen. Ein Lead kommt an; der Router schickt ihn auf den Enterprise-Pfad oder den SMB-Pfad, jeweils vorab separat gebaut. Make improvisiert keinen dritten Pfad für einen Lead, der zu keinem der beiden passt.

Iteratoren wandeln ein Array in eine Reihe separater Bundles um, eines pro Element.² Ein einzelner Webhook mit 40 Bestellpositionen wird zu 40 einzelnen Durchläufen durch alles Nachgelagerte. Iteratoren sind die Art, wie Make Schleifen abbildet — und jedes Element verbraucht seine eigene Ausführung, was für die Kosten relevant ist.

Aggregatoren tun das Gegenteil: Sie sammeln mehrere Bundles und führen sie zu einem Output zusammen.² Vierzig verarbeitete Bestellpositionen werden zu einem Sammeldatensatz, der in eine Tabelle zurückgeschrieben wird.

Die fünf Fehlerbehandlungs-Direktiven von Make — Break, Resume, Ignore, Commit und Rollback — hängen an einzelnen Modulen, nicht am gesamten Szenario.⁴ Resume ersetzt einen Ausfallwert. Ignore lässt das Szenario trotz eines fehlgeschlagenen Moduls weiterlaufen. Rollback macht rückgängig, was möglich ist, und markiert den Lauf als Fehler. Keine dieser Regeln erschließt, warum das Modul fehlschlug — jede folgt einfach der Regel, die Sie ausgewählt haben.

Der integrierte Data Store von Make speichert strukturierte Datensätze, die das Szenario mitten im Lauf lesen und schreiben kann — eine leichtgewichtige Datenbank, ohne den Canvas zu verlassen.

Flussdiagramm eines Make-Szenarios: Ein Trigger verbindet sich mit einem Router, der sich in zwei — Fünf Bausteine, fünf Stellen, an denen der Pfad bereits feststehen muss, bevor das Szenario läuft.

Diese fünf Elemente sind das, was ein visueller Workflow-Builder in der Praxis bedeutet. Sie erklären auch, warum Make bei Volumen gut skaliert und bei Variation schlecht: Jede Router-Verzweigung, jede Fehlerbehandlungsregel und jedes Data-Store-Feld muss feststehen, bevor das Szenario live geht.

Wie verändert Makes Credit-Preismodell die Kosten bei Skalierung?

Make berechnet Szenarien in Credits — dem aktuellen Abrechnungsbegriff für das, was frühere Dokumentation Operationen nannte.⁵ Jede Modulaktion verbraucht einen Credit: eine Slack-Nachricht senden, einen CRM-Datensatz aktualisieren, eine Zeile abrufen. Code-Ausführung kostet mehr, mit 2 Credits pro Sekunde Laufzeit.⁵

Der kostenlose Plan enthält 1.000 Credits im Monat. Core startet bei 9 $/Monat für 10.000 Credits, Pro bei 16 $, Teams bei 29 $ — jeweils skalierend zu höheren Credit-Stufen mit wachsendem Volumen.⁵ Credits über das Plan-Kontingent hinaus kosten pro Einheit mehr als das enthaltene Kontingent.

Iteratoren sind der Punkt, an dem Credit-Kosten überraschen. Ein Iterator verbraucht keinen Credit für das Array — er verbraucht einen pro Element.² Ein Szenario, das 500 Bestellpositionen verarbeitet, führt 500 Modulausführungen durch alles aus, was diesem Iterator nachgelagert ist, nicht eine. Ein Workflow, der auf dem Canvas wie eine Handvoll Schritte aussieht, kann Tausende Credits im Monat verbrauchen, sobald der Iterator echtes Volumen verarbeitet.

Das ist das entgegengesetzte Kostenprofil zu einem Agent. Die Kosten eines Agents skalieren mit API-Tokens pro Aufgabe, weitgehend unabhängig davon, wie der Input strukturiert ist. Die Kosten von Make skalieren mit der Anzahl der Bundles, die durch den Canvas laufen — günstig bei niedrigem Volumen, beobachtenswert, sobald Router und Iteratoren einen Workflow in Hunderte Ausführungen pro Element auffächern.

Was kann Make besser als ein Agent?

Make übernimmt drei Aufgabentypen besser als ein KI-Agent. Das Verwenden eines Agents für diese Aufgaben führt zu Problemen.

Strukturierte Datenflüsse. Datensätze zwischen Systemen verschieben, wenn das Format konsistent ist — eine neue Typeform-Übermittlung erstellt einen HubSpot-Kontakt, eine abgeschlossene Stripe-Zahlung löst einen Notion-Eintrag aus, eine neue Airtable-Zeile erstellt eine Monday-Aufgabe. Das Eingabeformat ist definiert. Das Ausgabeformat ist definiert. Ein Agent führt unnötige Variabilität ein, wo Konsistenz erforderlich ist.

Zeitgesteuerte Trigger. Dieselbe Aktion in einem definierten Intervall ausführen — einen wöchentlichen Digest senden, eine Datenquelle stündlich synchronisieren, einen monatlichen Bericht erstellen. Make führt diese zuverlässig nach Zeitplan aus, für einen Credit pro Lauf. Ein Agent ist für zeitgesteuerte, nicht kontextbezogene Operationen nicht geeignet.

Hochvolumige Aufgaben ohne Entscheidungslogik. Formularübermittlungen verarbeiten, Kontakte systemübergreifend synchronisieren, Elemente nach einem festen Feldwert weiterleiten. Das Volumen ändert die Entscheidungslogik nicht, und jede Ausführung kostet weiterhin einen Credit, egal ob es der erste oder der zehntausendste Lauf ist. Für diese Aufgaben ist Make schneller, günstiger und zuverlässiger als ein Agent.

Was kann ein KI-Agent besser als Make?

Ein KI-Agent übernimmt Aufgaben, bei denen die richtige Aktion vom Inhalt des Inputs abhängt — nicht nur davon, dass der Trigger ausgelöst hat.

E-Mail-Triage und Weiterleitung. Eingehende E-Mails kommen in inkonsistenten Formaten an. Eine Support-Anfrage, eine Partnerschaftsanfrage und eine Rechnungsfrage können in derselben Inbox ankommen. Make kann sie nicht unterscheiden, ohne einen benutzerdefinierten Filter für jede Variante. Ein KI-Agent liest jede E-Mail, klassifiziert die Absicht und leitet weiter oder formuliert eine inhaltlich passende Antwort.

Follow-up-Sequenzen mit variablem Kontext. Ein Follow-up, das sich danach richten soll, ob der Interessent das Angebot geöffnet hat, am Call teilgenommen hat oder still geblieben ist, erfordert das Lesen von Kontext. Make kann ein Follow-up nach einem Timer senden. Ein Agent formuliert die Nachricht basierend auf dem aktuellen Stand der Beziehung.

Intake-Qualifizierung mit unvollständigen Daten. Neue Leads kommen über mehrere Kanäle mit inkonsistenten Informationen an. Ein Agent liest jede Übermittlung, identifiziert Fehlendes oder Unklares und leitet den Lead weiter oder formuliert eine Klärungsanfrage. Make kann basierend auf einem Feldwert weiterleiten, aber nicht darüber nachdenken, was das Feld bedeutet.

Die Entscheidungskriterien für die Bereitschaft finden sich in So wissen Sie, ob ein Geschäftsprozess bereit ist, an einen KI-Agent übergeben zu werden.

Zweispaltiges Diagramm. Linke Spalte beschriftet als Make zeigt strukturierte Aufgaben: Formular zu — Make übernimmt strukturierte Abläufe, die Agents unzuverlässig machen. Agents übernehmen variable Aufgaben, die Make ohne einen Ast für jede Variante nicht verarbeiten kann.

Wo ist Makes Konnektor-Bibliothek stark, und wo ist sie dünn?

Make listet über 3.000 vorgefertigte Apps in seiner Integrationsbibliothek.⁶ Das deckt die Software ab, die die meisten Dienstleistungsunternehmen bereits nutzen: HubSpot, Salesforce, Stripe, Airtable, Google Workspace, Slack, Notion.

Zapiers eigene Developer-Plattform gibt mehr als 9.000 verbundene Apps an — fast dreimal so viele wie bei Make.⁷ Die Lücke zeigt sich bei Nischen- und branchenspezifischer Software: regionale Zahlungsdienstleister, branchenspezifische CRMs und kleinere SaaS-Tools mit begrenzter Nutzerbasis haben eher eine Zapier-Integration als ein natives Make-Modul.

Für einen Workflow, der vollständig auf gängigen Tools aufgebaut ist, deckt Makes Bibliothek von 3.000+ Apps den Bedarf ab. Für einen Workflow, der ein Nischen-Tool ohne natives Modul einbezieht, bleibt die Wahl zwischen einer HTTP- oder Webhook-Verbindung innerhalb von Make, einer anderen Automatisierungsplattform oder einem Agent, der die API dieses Tools direkt anspricht. Eine Agent-Implementierung ist an keine der beiden App-Listen gebunden — sie verbindet sich mit jeder API, die das Unternehmen bereits nutzt, ob mit nativem Modul oder ohne.

Make und ein KI-Agent im selben Workflow betreiben

Das praktischste Setup für ein Dienstleistungsunternehmen ist nicht Make oder ein KI-Agent — es sind beide, die unterschiedliche Aufgaben im selben Workflow übernehmen.

Make übernimmt die strukturierten Übergaben. Ein neuer qualifizierter Lead landet im CRM. Make erstellt den Datensatz, weist den Verantwortlichen zu und benachrichtigt das Team in Slack. Diese drei Schritte laufen immer in derselben Reihenfolge mit denselben Outputs ab. Kein Agent erforderlich.

Der Agent übernimmt die variable Antwort. Der Agent liest den neuen Lead-Datensatz, prüft auf frühere Kontakthistorie und formuliert eine personalisierte Outreach-E-Mail zur Genehmigung. Der Entwurf hängt von dem ab, was der Datensatz enthält. Make könnte diesen Entwurf nicht ohne eine Vorlage für jedes Szenario erstellen.

Make selbst bietet inzwischen ein eigenes AI-Agent-Modul, in der Beta-Phase 2025 eingeführt und bis 2026 ausgebaut.⁸ Es lässt Sie einen Reasoning-Schritt in den Canvas einbauen: ein LLM wie OpenAI, Claude, Mistral oder Google Vertex AI verbinden, ihm ein Ziel geben und es entscheiden lassen, welches der bestehenden Module im Szenario als Nächstes ausgeführt wird.⁸ Makes eigene Dokumentation beschreibt das Modul als Ergänzung zur deterministischen Logik, nicht als deren Ersatz — es läuft weiterhin innerhalb eines Szenarios, mit Freigabepunkten, die eine Person konfiguriert, und ruft weiterhin nur Apps auf, die bereits mit Make verbunden wurden.⁹

Das ist die Grenze, die man vor einem Hybrid-Setup verstehen sollte. Ein Make-AI-Agent-Modul denkt über die rund 3.000 Apps nach, die Make bereits aufrufen kann.⁶ Es liest keinen weitergeleiteten E-Mail-Thread, der zwei Jahre zurückreicht, gewichtet ihn nicht gegen die vollständige Kontohistorie eines CRM und formuliert keine Antwort, die beides widerspiegelt — das erfordert Kontext, der über Durchläufe hinweg gehalten wird, nicht bei jedem neuen Trigger zurückgesetzt wird. Eine eigenständige Agent-Implementierung, aufgebaut auf etwas wie Hermes oder einem Custom Agent, trägt diesen Kontext weiter, statt bei jedem Lauf neu zu beginnen.

Die beiden Werkzeuge laufen in Sequenz: Make erstellt die Datenstruktur, der Agent handelt auf Basis des Inhalts. Keines ersetzt das andere.

Make kartiert den Prozess. Ein Agent übernimmt, was außerhalb der Karte liegt.

Die Entscheidung, welcher Workflow zuerst umgestellt wird, folgt derselben Sequenzierungslogik wie unter Welche Workflows zuerst automatisieren.

Wann man von Make zu einem Agent migriert — und wann nicht

Unternehmen migrieren Make-Workflows zu KI-Agenten häufiger aus falschen als aus richtigen Gründen. Der Auslöser für eine Migration ist meist, dass Make sich „begrenzt" anfühlt — aber eine Einschränkung ist kein Grund für einen Wechsel. Der richtige Grund für eine Migration ist, dass der Workflow Entscheidungslogik enthält, die Sie derzeit mit Filtern und Bedingungs-Verzweigungen simulieren.

Zeichen, dass ein Make-Workflow migrationsbereit ist:

10+ Bedingungsverzweigungen versuchen, jede Eingabevariante abzudecken
Neue Eingabeformate brechen den Workflow regelmäßig und erfordern neue Pfade
Der Workflow produziert Ausgaben, die manuelle Korrekturen benötigen, weil Make keinen Kontext lesen kann
Der Credit-Verbrauch steigt stetig, weil ein Router oder Iterator eine Bewertungsfrage in Hunderte Verzweigungen pro Element auffächert

Zeichen, dass ein Make-Workflow in Make bleiben sollte:

Strukturierter Input, strukturierter Output, keine Entscheidungslogik erforderlich
Hohes Volumen, niedrige Variabilität — dieselbe Aktion läuft tausende Male identisch
Der Workflow nutzt native Make-Integrationen, die im Agent individuelle API-Arbeit erfordern würden
Der Workflow läuft nach Zeitplan ohne kontextuelle Variation

So sieht das in der Praxis aus. Eine Hausverwaltung verarbeitet neue Wartungsanfragen über Make: Ein strukturierter Webhook aus dem Mieterportal erstellt ein Ticket, weist einen Dienstleister zu und benachrichtigt den Mieter. Das bleibt in Make — das Eingabeformat ändert sich nie. Dann fangen Mieter an, Anfragen direkt per E-Mail statt über das Portal zu senden — keine festen Felder, Fotos eingebettet im Text, Dringlichkeit irgendwo in der Formulierung versteckt. Der Webhook-Trigger von Make hat nichts zu parsen. Das ist der Migrationspunkt — nicht weil Make schlechter geworden ist, sondern weil der Input aufgehört hat, strukturiert zu sein. Ein Agent liest die E-Mail, extrahiert, was ein Webhook als saubere Felder geliefert hätte, und erstellt dasselbe Ticket, das Make erstellt hätte — aus einem Input, den Make gar nicht verarbeiten kann.

Wie man ohne Betriebsunterbrechungen migriert: Agent und Make-Workflow zwei bis vier Wochen parallel betreiben, bevor umgeschaltet wird. Ausgaben vergleichen. Wo der Agent bei den variablen Fällen bessere und bei den strukturierten Fällen gleichwertige Ergebnisse liefert, wechseln. Wo der Agent Variabilität einführt, die Make eliminierte, Make behalten.

Die meisten Dienstleistungsunternehmen landen bei beiden Werkzeugen im selben System — Make für Datenstruktur, Agents für Inhaltsentscheidungen. Diese Aufteilung ist zuverlässiger, als eines der beiden Werkzeuge zu zwingen, alles zu übernehmen.

Der häufigste Fehler ist die Migration eines strukturierten Workflows zu einem Agent, weil der Agent leistungsfähiger erscheint. Leistungsfähigkeit ist nicht die relevante Variable. Konsistenz ist es. Der Determinismus von Make ist ein Merkmal, keine Einschränkung. Die Variabilität eines Agents ist ebenfalls ein Merkmal — für die Aufgabentypen, die sie brauchen. Das Werkzeug zum Aufgabentyp passend zu machen, ist die gesamte Entscheidung. Treffen Sie sie richtig, laufen beide Werkzeuge zuverlässig. Treffen Sie sie falsch, funktioniert keines von beiden.

Für die breitere Version derselben Tool-vs-Agent-Frage über die gesamte Automatisierungstool-Kategorie hinweg siehe KI-Tools vs. Agenten.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Make und einem KI-Agent? Make führt vordefinierte Workflow-Sequenzen aus — wenn ein Trigger auslöst, werden die konfigurierten Module mit konsistenten Outputs ausgeführt. Ein KI-Agent liest Kontext und trifft Entscheidungen — derselbe Trigger erzeugt unterschiedliche Outputs, je nachdem, was der Input enthält. Make ist zuverlässig für strukturierte, vorhersehbare Workflows. Ein KI-Agent verarbeitet Variationen, die Make nicht verarbeiten kann.

Kann Make durch einen KI-Agent ersetzt werden? Nur für Aufgaben, bei denen der Input variiert oder die richtige Aktion vom Inhalt abhängt. Für strukturierte Datenflüsse, zeitgesteuerte Trigger und hochvolumige Aufgaben ohne Entscheidungslogik bleibt Make das bessere Werkzeug. Das Ersetzen von Make durch einen Agent für diese Aufgaben führt zu Output-Variabilität, wo Konsistenz erforderlich ist.

Funktionieren Make und ein KI-Agent gemeinsam im selben Workflow? Ja — und das ist die praktischste Architektur für die meisten Dienstleistungsunternehmen. Make übernimmt strukturierte Übergaben: Datensatzerstellung, Weiterleitung, Benachrichtigungen. Der Agent übernimmt variable Aufgaben: Formulieren, Kategorisieren, Qualifizieren. Jedes Werkzeug übernimmt den Teil des Workflows, den das andere nicht kann.

Was passiert, wenn ein KI-Agent für Aufgaben eingesetzt wird, die Make besser erledigt? Der Agent führt Variabilität in einen Workflow ein, der Konsistenz benötigt. Eine Bestätigungs-E-Mail wird bei jedem Versand leicht unterschiedlich. Eine Datensynchronisation erzeugt inkonsistente Feldformate. Der Agent versagt nicht — er tut, was Agents tun. Die Aufgabe war das falsche Werkzeug.

Kann Make.com einen KI-Agent betreiben? Make bietet ein eigenes AI-Agent-Modul, eingeführt 2025 und bis 2026 ausgebaut. Es lässt ein Szenario ein verbundenes LLM entscheiden, welches Modul im Szenario als Nächstes ausgeführt wird — mit eingebauten Freigabepunkten. Das Modul läuft innerhalb eines einzelnen Szenarios und erreicht nur die rund 3.000 Apps, für die Make native Verbindungen bietet — es behält kein Gedächtnis über getrennte Szenarien hinweg und liest keine Kanäle außerhalb der Make-App-Liste. Dafür ist eine eigenständige Agent-Implementierung erforderlich.

Was kostet Make.com im Vergleich zu einer KI-Agent-Implementierung? Make kostet je nach Plan und Credit-Volumen 9 bis 29 $ im Monat, wobei jede Modulaktion einen Credit verbraucht. Eine KI-Agent-Implementierung kostet im Voraus mehr — üblicherweise 2.000 bis 8.000 $ für den Aufbau — zuzüglich laufender API-Kosten. Make ist günstiger für hochvolumige, strukturierte Aufgaben. Ein Agent rechtfertigt die höheren Einrichtungskosten nur, wenn die Aufgabe Lesen und Entscheiden erfordert, statt eine kartierte Abfolge auszuführen.