Zum Hauptinhalt springen

Automatisierung für Technische Nutzer

Diese Seite ist für Personen gedacht, die mit HTTP, JSON, APIs, Expressions und strukturierter Konfiguration arbeiten. Ziel ist ein mentales Modell, mit dem du im CLYE AI nicht nur einfache Regeln, sondern auch komplexere Automationen zuverlässig bauen kannst.

Mentales Modell​

Eine Automation besteht technisch aus fünf Bausteinen:

  1. Trigger: Wann startet sie?
  2. Trigger-Daten: Welche Daten stehen dem Lauf zur Verfügung?
  3. Condition: Soll dieser Lauf wirklich weitergehen?
  4. Action Tool: Welches Tool wird aufgerufen?
  5. Action Args: Mit welchen Parametern wird das Tool aufgerufen?

Praktisch ist das:

  • WHEN: Trigger
  • IF: JavaScript-Expression
  • THEN: Tool-Aufruf mit vorbereiteten Parametern

Ausführungsmodell​

Technisch läuft eine Automation in dieser Reihenfolge:

  1. Der Trigger erzeugt einen Laufkontext.
  2. Der Lauf stellt Trigger-Daten als event bzw. event.data bereit.
  3. Die Condition wird als JavaScript-Ausdruck ausgewertet.
  4. Wenn die Condition true ergibt, werden die Action-Parameter vorbereitet.
  5. In actionArgs werden {{ ... }}-Ausdrücke ausgewertet.
  6. Danach wird das konfigurierte Tool ausgeführt.
  7. QoS-Regeln bestimmen, ob bei Fehlern wiederholt, parallelisiert oder gestoppt wird.

Wichtig:

  • Eine fehlerhafte Condition stoppt den Lauf nicht mit einem harten Crash, sondern führt dazu, dass die Automation für diesen Lauf als nicht passend behandelt wird.
  • Ein Tool-Fehler ist etwas anderes als eine nicht passende Condition.
  • Für chat/send_message werden auch Rückgaben wie success: false als echter Fehler gewertet.
  • Fehler aus Automation-Code und Expressions werden jetzt verständlicher auf den Code im Editor bezogen. Statt interner Sandbox-Dateien oder Host-Zeilen wie worker.js siehst du im Fehlerfall typischerweise die Stelle im eigenen Skript, dazu einen passenden Ausschnitt und einen nutzbaren Trace.
  • Wenn ein Skript das Zeitlimit überschreitet, erscheint die Meldung als Skript-Timeout mit Hinweis auf das geltende Limit. Dadurch ist besser erkennbar, ob eher eine Endlosschleife, blockierende Logik oder ein zu großer Verarbeitungsschritt die Ursache ist.
  • Wenn ein Lauf fachlich bereits ein Ergebnis oder einen echten Skriptfehler erzeugt hat, wird dieses Ergebnis nicht mehr durch einen nachgelagerten QuickJS-Dispose-Abbruch überschrieben. Statt eines internen WASM-Asserts siehst du dadurch entweder weiterhin dein erfolgreiches Ergebnis oder eine nutzbare Fehlermeldung aus dem eigenen Skript.

Trigger-Arten​

Der CLYE AI unterstützt vier Trigger-Arten:

  • Event
  • Zeit
  • HTTP
  • Tool

Event​

Event-Trigger sind der Standard, wenn du auf interne Änderungen reagieren willst.

Typische Filter:

  • type
  • objectId

Zusätzlich kann bei Event-Triggern eine Condition feiner auf event.data prüfen.

Beispiel:

event.data.status == "open" && event.data.priority == "high"

Zeit​

Zeit-Trigger eignen sich für Routinen und periodische Jobs.

Relevante Muster:

  • interval
  • daily
  • weekdays
  • weekly
  • monthly

Die Zeitzone ist konfigurierbar und standardmäßig auf Europe/Berlin gesetzt.

HTTP​

HTTP-Trigger machen eine Automation von außen aufrufbar. Nach dem Speichern bekommt die Automation eine eigene URL mit nicht erratbarem Token.

Unterstützte Methoden:

  • GET
  • POST
  • PUT
  • DELETE

Der Request wird in Conditions, {{ ... }}-Templates, Action-Parametern und im Automation-Code als event.data bereitgestellt:

  • event.data.method
  • event.data.body
  • event.data.query
  • event.data.headers
  • event.data.url

Zusätzlich landet derselbe Roh-Request im Start-Event der Automation unter automation.run.started.data.parameters. So kannst du später in Event-Logs oder bei Tests nachvollziehen, mit welchen HTTP-Parametern ein Lauf gestartet wurde.

Tool​

Tool-Trigger machen eine Automation selbst zu einem aufrufbaren Baustein. Das ist sinnvoll, wenn:

  • andere Automationen sie wiederverwenden sollen
  • ein Assistent sie als Tool aufrufen soll
  • du größere Abläufe modularisieren willst

Technisch heißt das: Statt auf ein externes Ereignis zu warten, wird die Automation selbst als Tool exponiert.

Das event-Objekt verstehen​

Für Conditions und viele Expression-Auswertungen ist event das zentrale Objekt.

Welche event.type-Werte du im Event-Trigger typischerweise auswählen kannst, welche systemseitigen Typen es gibt und wie externe Typen als external.<type> auftauchen, steht gesammelt unter Event-Typen für Automationen.

Wenn ein echter Event-Trigger vorliegt, enthält event typischerweise mehr als nur data, zum Beispiel:

  • event.id
  • event.type
  • event.timestamp
  • event.data
  • event.metadata: fachlicher Kontext des Events als Facets, zum Beispiel customer, project, invoice oder task
  • event.userId
  • event.objectId
  • event.causedBy
  • event.spaceIds
  • event.sequence
  • event.actorId

event.causedBy bleibt dabei die ID des direkten Ursachen-Events. Wenn du nicht nur die ID, sondern den zugehörigen Event-Datensatz brauchst, stehen dir in Automationen jetzt zwei Helfer zur Verfügung:

  • await causedByEvent(): lädt das direkte Ursachen-Event des aktuellen Events
  • await rootCauseEvent(): folgt der Ursachen-Kette schrittweise bis zum ursprünglichen Event

Beide Helfer funktionieren in Conditions, in Action-Expressions, in {{ ... }}-Templates und in Automation-Code. Sie liefern jeweils den Event-Datensatz oder null, wenn kein passendes sichtbares Ursachen-Event vorhanden ist.

Beispiele:

const cause = await causedByEvent();
cause != null && cause.type == "task.created"
const root = await rootCauseEvent();
root != null && root.objectId == event.objectId
params:
  summary: "{{ (await rootCauseEvent())?.type ?? event.type }}"

Wichtige Praxisregeln:

  • Verwende weiter event.causedBy, wenn dir die Event-ID genügt, zum Beispiel zum Speichern oder Weiterreichen.
  • Verwende causedByEvent() oder rootCauseEvent(), wenn du Felder des verursachenden Events prüfen oder in Templates ausgeben willst.
  • Es werden nur Ursachen-Events aufgelöst, die in deinem Space sichtbar sind.

Wenn kein voller Event-Datensatz vorliegt, ist mindestens event.data relevant.

Expressions in der Oberfläche schreiben​

Wenn eine Condition oder ein {{ ... }}-Ausdruck fehlschlägt, zeigt die Oberfläche den Fehler jetzt gezielter am ursprünglichen Editor-Code an. Irreführende interne Positionsangaben aus der Sandbox stehen dabei nicht mehr im Vordergrund. Das macht Debugging vor allem bei längeren Expressions und Code-Schritten deutlich einfacher.

Expressions bearbeitest du direkt inline in der Oberfläche. Dafür gibt es einen kompakten Editor, der die bisherige Eingabe im gleichen Platzbedarf beibehält, aber deutlich mehr Unterstützung bietet.

Das hilft dir beim Schreiben von Conditions und {{ ... }}-Ausdrücken:

  • JavaScript-Syntaxhervorhebung direkt im Feld
  • kontextbezogene Autovervollständigung für event, verschachtelte Properties, verfügbare Helper und JavaScript-Built-ins
  • automatisches Wachstum des Feldes bei längeren Ausdrücken
  • unveränderte Anzeige von HTML-Tags einschließlich schließender Tags innerhalb von Templates

Praktisch ist das besonders bei längeren Pfaden wie event.data.body.customerId, bei optionalen Feldern und bei Expressions mit mehreren Bedingungen.

Conditions: JavaScript statt Regelsprache​

Conditions sind JavaScript-Ausdrücke, die zu true oder false ausgewertet werden.

Typische Muster:

event.data.amount >= 1000
event.data.customer != null && event.data.customer.tier == "enterprise"

Facet-Metadaten erlauben Bedingungen auf dem fachlichen Kontext eines Events:

event.metadata?.customer?.name == "Beispiel GmbH"
Array.isArray(event.data.items) && event.data.items.some((item) => item.price > 100)

Wichtige Praxisregel:

  • Verwende defensive Checks wie != null, typeof ... == "string" oder Array.isArray(...), wenn Daten optional sein können.

Beispiel aus der Praxis:

  • Bei chat.started kann event.data.botId leer sein, wenn der Chat in einem Space ohne Bot gestartet wurde.
  • Schreibe Conditions deshalb nicht so, als wäre botId immer vorhanden.

Defensives Beispiel:

event.type == "chat.started" && event.data != null && event.data.botId != null

Action Args: statische Werte plus {{ ... }}​

Die Parameter eines Action Tools können statisch sein oder Expressions enthalten. In Strings werden {{ ... }}-Blöcke ausgewertet.

Beispiele:

params:
  title: "Täglicher Bericht"
  source: "{{ event.data.query.source }}"
  summary: "{{ 'Kunde ' + (event.data.body.customerId ?? 'unbekannt') }}"

Das ist wichtig:

  • Die Condition selbst ist ein reiner JavaScript-Ausdruck.
  • In actionArgs werden Werte feldweise vorbereitet.
  • String-Felder können {{ ... }} enthalten.
  • Auch verschachtelte Objekte wie metadata können solche Ausdrücke enthalten.
  • Im Editor bekommst du dafür Autovervollständigung für Event-Daten, Helper und JavaScript-Built-ins direkt im jeweiligen Feld.

Action Tools richtig auswählen​

Technisch ruft eine Automation ein Tool auf. In der Oberfläche wählst du es aus der Tool-Liste des Spaces aus.

Praktisch sind Tool-IDs üblicherweise im Format:

  • <toolbox-id>/<tool-name>
  • <mcp-server-id>/<tool-name>

Beispiele:

  • chat/send_message
  • ein Tool aus einem angebundenen MCP-Server

Die Oberfläche hilft beim Auswählen und validiert die Eingaben auf Basis des Input-Schemas des jeweiligen Tools.

js_execute für Tool-Ketten und kleine Ergebnisse​

Wenn in einer Automation sowohl js_execute als auch On-Demand-MCP-Tools verfügbar sind, gilt diese Faustregel:

  • Einzelaufruf: Ein einzelnes Tool aus einem MCP-Server kannst du direkt als Action verwenden.
  • Kette, Join oder Filter: Nutze stattdessen ein einziges js_execute, rufe darin die benötigten Tools nacheinander auf und gib nur das kleine, fertige Ergebnis zurück.

Warum das hilfreich ist:

  • Zwischenergebnisse bleiben im Code statt als lange Tool-Antwort in der Automation.
  • Filter, Mapping, Joins und einfache Nachbearbeitung sind klarer und robuster.
  • Die Automation bekommt am Ende nur das Resultat, das im nächsten Schritt wirklich gebraucht wird.

Empfohlene Schreibweise im Code:

const customers = await tools.call_tool({ name: 'customer_list', server: 'crm', arguments: { limit: 50 } });
const openInvoices = await tools.call_tool({ name: 'invoice_list', server: 'billing', arguments: { status: 'open' } });

const result = openInvoices.items
  .filter(invoice => customers.items.some(c => c.id === invoice.customerId))
  .map(invoice => ({
    invoiceNumber: invoice.number,
    customerId: invoice.customerId,
    amount: invoice.amount,
  }));

return result;

Wichtig:

  • Für dynamische Tool-Aufrufe in js_execute ist await tools.call_tool({ name, server, arguments }) jetzt die kanonische Form.
  • Direkte Aufrufe wie await tools.rag_search({...}) oder andere tools.<name>(...)-Aufrufe bleiben weiterhin gültig und sind für bekannte Tools oft die kürzeste Schreibweise.
  • call_tool ist grundsätzlich verfügbar. search_tool ist dafür die kanonische Suche, wenn du On-Demand-MCP-Tools erst suchen oder auswählen willst. search_mcp_tool bleibt nur als veralteter Alias für ältere Chats und bestehende Aufrufe lesbar.
  • Ältere Schreibweisen wie tools.call_mcp(...), call_mcp_tool, Positionsparameter oder server/tool direkt im name bleiben aus Kompatibilitätsgründen weiter lesbar, gelten aber als veraltet.
  • Große Tool-Antworten werden innerhalb von call_tool und innerhalb verschachtelter js_execute-Aufrufe nicht mehr vorzeitig gekürzt. Wenn dein Code die vollständige Rohantwort weiterverarbeiten muss, steht sie dort vollständig zur Verfügung.
  • Gekürzt wird erst an der Grenze zum eigentlichen LLM-Aufruf. Gib deshalb weiterhin möglichst nur das reduzierte Endergebnis zurück, das der nächste Schritt wirklich braucht.
  • Wenn nur ein einzelner Aufruf ohne Nachbearbeitung nötig ist, reicht das jeweilige Tool direkt als Action meist aus.
  • fetch(...) ist in Chat und Playground nur dann verfügbar, wenn für den JavaScript-Server eine Fetch-Allowlist mit mindestens einem Muster konfiguriert ist. Ohne Allowlist bleibt fetch dort gesperrt.
  • Auch mit gesetzter Allowlist sind nur Ziele erlaubt, die auf ein freigegebenes Muster passen. Interne oder lokale Hosts bleiben weiterhin blockiert.
  • In Automationen bleibt fetch wie bisher verfügbar; dort gilt die Allowlist ebenfalls nur als zusätzliche Einschränkung für erlaubte externe Ziele.
  • Wenn du Secrets in fetch-Headern verwendest, kannst du Secret-Handles jetzt direkt in String-Interpolation oder Template-Strings mit Präfixen wie Bearer oder token einsetzen. Die Auflösung zum echten Secret erfolgt erst unmittelbar vor dem fetch-Aufruf.

Beispiel:

const token = await secrets.get('FORGEJO_TOKEN');

const response = await fetch('https://forgejo.example.com/api/v1/user', {
  headers: {
    Authorization: `token ${token}`
  }
});

Das ist vor allem für Authorization-Header hilfreich, weil der Klartext nicht im Guest-Code stehen muss und Präfixe wie Bearer oder token trotzdem korrekt funktionieren.

chat/send_message als Universalbaustein​

Für viele technische Integrationen ist chat/send_message das flexibelste Start-Tool.

Typische Einsatzfälle:

  • HTTP-Request an einen Assistenten weiterreichen
  • Event-Daten automatisch zusammenfassen lassen
  • Vorprüfung, Klassifikation oder Antwortentwurf auslösen
  • Follow-up-Fragen in bestehende Chats einspeisen

Wichtige Parameter:

  • threadId: in bestehenden Chat-Thread schreiben
  • chatId: weiterhin als Alias für bestehende Integrationen
  • spaceId: neuen Chat im Space starten
  • Für neue Chats muss spaceId die UUID des Ziel-Spaces sein, nicht die UUID eines Bots oder Assistenten.
  • message: Text oder Nachrichtenobjekt
  • metadata: Zusatzdaten
  • intention: menschenlesbare Beschreibung des Schritts

Wenn du in Antworten oder Vorlagen MDX-Karten wie <taskcard>, <taskrow> oder <threadcard> erzeugst, kannst du die Objekt-ID jetzt robuster übergeben: Neben id und data.id akzeptieren die Karten auch Aliasnamen wie taskId, taskid, task-id sowie threadId, threadid, thread-id. Das ist besonders hilfreich, wenn Attribute aus HTML-Parsern, Low-Code-Tools oder LLM-Ausgaben kleingeschrieben oder in Kebab-Case geliefert werden.

Faustregel:

  • Nutze spaceId, wenn jeder Trigger einen neuen Vorgang erzeugen soll.
  • Nutze bevorzugt threadId, wenn du denselben Vorgang fortschreiben willst. chatId bleibt dafür als Alias nutzbar.

Kosten und Effizienz​

chat/send_message ist fachlich oft sehr stark, aber auch der Schritt, der typischerweise echte LLM-Kosten und zusätzliche Laufzeit verursacht.

Darum gilt als technische Best Practice:

  • zuerst mit Condition, Code oder vorgeschalteten Tools prüfen, ob der Fall überhaupt relevant ist
  • zuerst einfache Regeln, Filter, Deduplizierung und Datentransformation ausführen
  • erst dann chat/send_message aufrufen, wenn wirklich Zusammenfassung, Klassifikation, Formulierung oder ein anderer KI-Schritt gebraucht wird

Beispiel:

  • Eine Automation prüft regelmäßig E-Mails oder ein externes System.
  • Code oder Filter entscheiden zuerst, ob es überhaupt neue und interessante Fälle gibt.
  • Nur diese Treffer werden dann per chat/send_message an einen Assistenten gegeben.

HTTP-Trigger als Integrations-API​

Ein HTTP-Trigger kann wie ein kleiner interner Endpoint behandelt werden. Das ist besonders nützlich, wenn du kein vollständiges eigenes Backend bauen willst, aber strukturierte Requests in Automationen einspeisen möchtest.

Einfache Schutzschicht​

Die Trigger-URL enthält bereits einen geheimen Token. Für zusätzliche Absicherung kannst du die Condition als Shared-Secret-Prüfung verwenden.

Beispiele:

event.data.headers.authorization == "Bearer MEIN_SHARED_SECRET"
event.data.headers["x-api-key"] == "MEIN_SHARED_SECRET"
event.data.method == "POST" && String(event.data.headers["content-type"] ?? "").includes("application/json")

Typisches Muster​

  1. Externes System ruft die HTTP-Trigger-URL auf.
  2. Condition prüft Methode, Auth und Pflichtfelder.
  3. chat/send_message oder ein anderes Tool verarbeitet den Request.
  4. Das Ergebnis wird als Tool-Ergebnis im Automationslauf sichtbar.

Eigene Events als Entkopplung​

Ein sehr gutes technisches Muster ist, Erkennung und Reaktion über eigene Events zu trennen.

Das bedeutet:

  1. Eine Automation erkennt etwas technisch oder fachlich.
  2. Sie dispatcht daraus ein oder mehrere klar benannte Events.
  3. Andere Automationen reagieren auf genau diese Events.

Beispiel:

  1. Eine Automation prüft regelmäßig, welche Dateien sich geändert haben.
  2. Für jede Änderung erzeugt sie ein Event wie file.changed.
  3. Andere Automationen reagieren darauf, z. B. mit Indexierung, Benachrichtigung oder chat/send_message.

Warum das oft besser ist:

  • retrybar: Die Schritte sind sauber getrennt und können unabhängig erneut laufen.
  • einfacher: Jede Automation hat nur eine klarere Verantwortung.
  • flexibler: Ein Eingang kann auf mehrere Ziel-Events gemappt werden.
  • erweiterbar: Mehrere Folgeautomationen können auf dasselbe Event reagieren.

Gerade wenn aus einem technischen Polling oder Vergleich mehrere fachliche Fälle entstehen können, ist dieses Muster meist sauberer als eine große monolithische Automation.

Event-Policy und Entdoppelung​

Für Event-Trigger gibt es neben type und objectId noch die Event Policy.

Wichtig ist vor allem:

  • default: jedes passende Event kann einen Lauf auslösen
  • latestPerObject: bei mehreren Events pro Objekt wird nur das neueste verarbeitet

Das ist besonders nützlich bei:

  • Reindexing
  • mehrfachen Statusupdates in kurzer Folge
  • idempotenten Folgeschritten pro Objekt

QoS: Retries, Parallelität, Fehlverhalten​

Für technisch robuste Automationen ist der QoS-Bereich wichtig.

Relevante Felder:

  • qos.maxRetries
  • qos.stopOnFailure
  • qos.maxParallelRuns

Praktische Bedeutung:

  • maxRetries: 0: keine Wiederholung
  • maxRetries > 0: fehlgeschlagene Läufe werden erneut versucht
  • stopOnFailure: true: eine Automation mit „Bei Fehler stoppen“ deaktiviert sich erst nach dem wirklich letzten fehlgeschlagenen Versuch, also nach maxRetries + 1 Ausführungen insgesamt.
  • Nach dem Reaktivieren wird das zuletzt endgültig fehlgeschlagene Event erneut zuerst aus der Warteschlange verarbeitet, statt als erledigt zu gelten.
  • maxParallelRuns: 1: strikt sequentiell
  • maxParallelRuns > 1: parallele Abarbeitung möglich

Faustregeln:

  • Für API-Aufrufe mit Seiteneffekten lieber konservativ starten.
  • Für reine Lese- oder Analysejobs kann mehr Parallelität sinnvoll sein.
  • Wenn Doppelausführung problematisch ist, zuerst Idempotenz und Event-Policy klären.

YAML als Code pflegen​

Automationen können nicht nur in der UI, sondern auch als Dateien gedacht werden. Im technischen Dateimodell liegt eine Automation als YAML-Datei unter /automations/<name>.yml.

Beispiel:

title: Ticket an Assistenten weitergeben
description: Nimmt HTTP-Requests entgegen und schickt sie an einen Assistenten.

reactions:
  inbound-ticket:
    on:
      http: true
    condition: event.data.method == "POST" && event.data.headers.authorization == "Bearer MEIN_SHARED_SECRET" && event.data.body != null && typeof event.data.body.message == "string"
    run:
      call: chat/send_message
      params:
        spaceId: "11111111-1111-4111-8111-111111111111"
        intention: "Ticket an Assistenten senden"
        message: "{{ 'Neues Ticket: ' + (event.data.body.message ?? '') }}"
        metadata:
          source: "http-trigger"
          ticketId: "{{ event.data.body.ticketId }}"

Wichtige Kurzschreibweisen:

  • run.call wird in der Oberfläche als actionTool geführt.
  • run.params wird in der Oberfläche als actionArgs geführt.
  • on.http: true aktiviert einen HTTP-Trigger.
  • on.tool: true aktiviert einen Tool-Trigger.

Wichtig für automation_patch:

  • Neue Reactions brauchen immer on und run.call.
  • Ältere Alias-Felder wie action oder tool werden beim Patchen auf run.call normalisiert.
  • input wird auf run.params normalisiert, auch in verschachtelten Objekten.
  • Verbotene Felder wie cron, ein Top-Level-schedule oder ein falsches type werden mit gezielten Hinweisen abgelehnt.
  • Für stündliche Pläne verwende on: { interval: 60 } statt time.pattern: "hourly".

So lassen sich typische Validierungsfehler schneller beheben, weil die Hinweise direkt auf das betroffene Feld und die erwartete Schreibweise verweisen.

Das ist besonders nützlich, wenn du:

  • Automationen versionieren willst
  • Änderungen im Team reviewen willst
  • mehrere ähnliche Automationen reproduzierbar erzeugen willst

Gute technische Muster​

1. Klein anfangen, dann generalisieren​

Zuerst einen klaren Trigger und ein einfaches Tool wählen, danach erst Expressions und Wiederverwendung ausbauen.

Wenn ein Ablauf wächst, ist ein eigener Event-Schritt oft der beste nächste Schnitt.

2. Condition für Routing, nicht für komplette Business-Logik​

Die Condition sollte Läufe grob zulassen oder ablehnen. Komplexe Nutzlastaufbereitung gehört eher in actionArgs oder in das aufgerufene Tool.

Wenn die Vorlogik größer wird, ist ein Code-Schritt meist besser als ein früher LLM-Aufruf. Das spart Kosten und macht das Verhalten stabiler.

3. Nachrichten explizit bauen​

Wenn du chat/send_message nutzt, formuliere im message-Feld bewusst, welche Daten wichtig sind. Externe Rohdaten ungefiltert an einen Assistenten weiterzugeben ist selten die beste Variante.

4. Metadaten mitschreiben​

Zusätzliche Felder in metadata helfen bei Nachvollziehbarkeit und späteren Folgeautomationen.

5. Idempotenz mitdenken​

Wenn derselbe externe Request mehrfach auftreten kann, sollte entweder:

  • die Event-Policy passend gesetzt sein
  • ein bestehender threadId-Pfad verwendet werden, bei älteren Integrationen weiter auch chatId als Alias
  • oder das Zielsystem Mehrfachläufe tolerieren

6. Technische Erkennung von fachlicher Reaktion trennen​

Wenn eine Automation zunächst nur erkennt, dass etwas passiert ist, sollte sie oft lieber ein eigenes Event dispatchen statt sofort alle Folgeschritte selbst zu erledigen.

Das ist besonders sinnvoll bei:

  • Dateiänderungen
  • Polling von externen Systemen
  • Delta-Abgleichen
  • Mapping von einem Eingang auf mehrere unterschiedliche Reaktionen

Wo die Grenzen liegen​

Automationen sind sehr flexibel, aber kein Ersatz für eine komplette Integrationsplattform.

Ein eigenes vorgeschaltetes Backend ist oft sinnvoll, wenn du:

  • komplexe Authentifizierung brauchst
  • HMAC-Signaturen oder aufwendige Request-Validierung brauchst
  • mehrere externe Systeme zusammenführen willst
  • lange Transformationsketten außerhalb eines Tool-Aufrufs brauchst

In solchen Fällen ist der CLYE AI oft der Orchestrierungs- oder LLM-Schritt, nicht zwingend der einzige Integrationspunkt.

Empfohlene Arbeitsweise​

  1. Trigger-Daten zuerst verstehen.
  2. Condition defensiv formulieren.
  3. Mit einem kleinen Tool-Aufruf starten.
  4. QoS bewusst setzen.
  5. Erst danach Ketten, Wiederverwendung und YAML-Pflege ausbauen.

Kurz gesagt​

Mit dem CLYE AI kannst du technisch anspruchsvolle Automationen bauen, wenn du Trigger, event.data, JavaScript-Conditions, Code-Schritte, eigene Events, templated actionArgs und Tool-Aufrufe sauber zusammendenkst. Für viele Integrationen ist die Kombination aus Vorprüfung per Condition oder Code, Dispatch eigener Fach-Events und chat/send_message nur bei echtem KI-Bedarf der sauberste Einstieg.

Inhalt