Automatisierungskonzepte

Nutze eine Automatisierung für Arbeit mit einem wiederholbaren Ablauf. Der Workflow beschreibt die Schritte; gespeicherte Versionen erhalten jede Fassung, die Bereitstellung wählt die Version für Live-Läufe und ein Trigger kann sie nach Zeitplan oder Ereignis starten. Jeder Lauf zeigt Eingabe, Ergebnisse und Aktionen.

Lieber erst zusehen? Episode 5 öffnet die Triage-Automatisierung von vorne bis hinten und entscheidet eine Freigabekarte vor der Kamera, mit Untertiteln — aufgenommen auf der früheren Version, wo die Karte im Chat saß; in dieser Version sitzt sie auf der Detailseite des Laufs.

Das Workflow-Dokument

Der name identifiziert die Automatisierung. Verwende kleingeschriebene Segmente mit Bindestrichen; / fasst verwandte Automatisierungen in Ordnern zusammen, etwa billing/dunning-reminder. Das erste Segment darf kein reservierter Seitenname sein: asks, builder, catalog, listing, metrics, runs, serving-preview oder upload.

Das Dokument enthält außerdem eine description, ein JSON-Schema inputs für die Eingabe eines Laufs, die ausführenden nodes und einen output-Ausdruck für das Ergebnis. Seine tests beschreiben Beispiele und erwartete Ergebnisse, die vor der Bereitstellung geprüft werden.

name: billing/dunning-reminder
description: Einen Kunden an eine überfällige Rechnung erinnern.
inputs:
  type: object
  properties:
    invoiceId: { type: string }
  required: [invoiceId]
nodes:
  - id: invoice
    type: transform
    input:
      id: '{{ input.invoiceId }}'
    code: 'return { id: input.id, daysLate: 14 };'
  - id: message
    type: llm
    model: openai/gpt-4o-mini
    prompt: 'Schreibe eine höfliche Erinnerung zu Rechnung {{ nodes.invoice.output.id }}.'
output:
  text: '{{ nodes.message.output.text }}'
tests:
  - name: erzeugt eine Erinnerung
    input: { invoiceId: 'inv-1' }

Tale ordnet den Canvas anhand der Verweise zwischen den Nodes an, niemand platziert eine Node von Hand. Ein ui-Block ist freie Metadaten: Tale behält ihn unverändert und ignoriert ihn.

Kanten entstehen, sie werden nicht deklariert

Es gibt keine Kantenliste. Eine Node liest eine andere, indem sie sie referenziert — {{ nodes.invoice.output.id }} —, und genau diese Referenz ist die Kante, die der Canvas zeichnet. Die Reihenfolge ergibt sich aus einer topologischen Sortierung über diese abgeleiteten Kanten. Deshalb verschwindet mit einer gelöschten Referenz auch eine Linie, und deshalb weist die Plattform zwei Nodes zurück, die einander lesen.

Templates nutzen eine einzige {{ }}-Grammatik aus JavaScript-Ausdrücken über input, nodes.<id>.output und, innerhalb einer iterierenden Node, item und index.

Die Ablaufsteuerung sitzt an der Node

Verzweigen und Wiederholen sind Felder an einer Node statt eigener Schritttypen. Der Canvas zeichnet jedes davon dort, wo es wirkt: Aus when wird eine Bedingung über ihrer Node, eine Alternative per elseOf hängt als Zweig Nein an dieser Bedingung, forEach und repeatUntil setzen die Node in einen Rahmen, und onError: continue gibt ihr einen Chip.

Node-Typen

Vier Typen sind eingebaut, und jede Connector-Aktion sowie jede Plattformfunktion — Wissenssuche, Dokumentoperationen — reiht sich in dieselbe Tabelle daneben ein.

transform führt reines JavaScript aus, um Daten umzuformen. Ohne Netzwerk und ohne Imports: Der Rumpf liest die aufgelöste input der Node und muss einen Wert zurückgeben.

llm ruft ein Sprachmodell mit einem Prompt-Template auf. model ist Pflicht und immer ausdrücklich — eine Automatisierung wählt nie eines für dich (das Auto der Chat-Eingabezeile ist eine reine Chat-Sache). Die Ausgabe ist {text} oder das Objekt in Form des Schemas, wenn die Node ein outputSchema deklariert. Jeder Aufruf in einem Live-Lauf ist Nutzung des Laufs: Er wird vorher gegen die Budgetlimits geprüft, und ein Aufruf, den ein Limit ablehnt, lässt die Node mit budget_exceeded fehlschlagen, was den Lauf abbricht, außer ihr onError ist continue. Vor dem Anbieteraufruf reserviert jeder Versuch die geschätzten Prompt-Kosten und das maximale Antwortbudget in allen für diesen Versuch berücksichtigten Projekten. Dafür braucht das Modell Katalogpreise. Sobald der Aufruf endet, ersetzt die gemeldete Nutzung die Reservierung. Bleiben die Kosten wegen einer Zeitüberschreitung, einer unterbrochenen Verbindung oder fehlender Nutzungsdaten unbekannt, bleibt die Reservierung bis zur Anfragefrist bestehen und wird danach als reservierter Schätzwert verbucht; das ist eine Schätzung, keine Anbieterrechnung. Änderungen an Projektzuordnungen während des Aufrufs verschieben dessen Verbrauch nicht.

agent führt einen Agent-Turn eines Coding-Agents (Claude Code, Codex und die übrigen Agent-Laufzeiten) in der Sandbox aus. Er liest bereitgestellte files, nutzt skills, vermittelte connectors, gewährte Plattform-tools und eingespielte secrets und gibt {text, files, status} zurück; model ist Pflicht. Die aufgelöste input der Node erreicht den Agenten als JSON in /agent/workspace/input.json, und seine Anweisungen nennen diese Datei. In einem Live-Lauf schlägt die Node fehl, bevor der Agent startet, wenn dieses JSON größer als 1 MiB ist oder ihre files zusätzlich einen Eintrag namens input.json enthalten. Hat ein Admin die Bildgenerierung eingeschaltet, kann er auch Bilder erstellen, die unter seinen files zurückkommen. Greif zu llm, wenn eine einmalige Completion reicht, und zu agent nur, wenn der Schritt Werkzeuge, Dateien oder mehrere Turns braucht — eine live geschaltete Agent-Node läuft als asynchroner Turn, sitzt daher auf der obersten Ebene statt in einer subautomation und iteriert nicht mit forEach.

subautomation führt eine andere gespeicherte Automatisierung als einzelne Node aus; ihr Feld automation benennt "name" oder "name@version". Ohne Version läuft die live geschaltete, und die Verschachtelung endet bei drei Ebenen.

http.get und http.send rufen jede HTTPS-API auf, für die es keinen eigenen Connector gibt, mit gespeicherten Zugangsdaten oder ohne. Siehe Eine API aus einer Automatisierung aufrufen.

knowledge.search durchsucht deine Dokumente und indexierten Websites und gibt die Passagen zurück, die am besten zu einer Anfrage passen, für einen späteren Schritt. Die Suche liest, was ihr Lauf lesen darf. Siehe Dein Wissen aus einer Automatisierung durchsuchen.

task.create erstellt eine Aufgabe in einem Projekt, in dem die Automatisierung installiert ist, einmal pro Ausführung des Schritts. Siehe Aufgaben aus einer Automatisierung anlegen.

task.list listet die Aufgaben eines Projekts auf, die neueste zuerst, eingegrenzt auf Status und einen Erstellungszeitpunkt, damit ein späterer Schritt darüber berichtet. Es liest das Projekt so, wie ein Erstellen dort es darf. Siehe Aufgaben aus einer Automatisierung anlegen.

notify.member teilt Mitgliedern der Organisation etwas mit — Titel, Text und Link — in ihren Benachrichtigungen und per E-Mail, einmal pro Ausführung des Schritts. Siehe Mitglieder aus einer Automatisierung benachrichtigen.

Strukturierte und unstrukturierte Ausgabe

Eine strukturierte Ausgabe hat benannte Felder, die du über nodes.<id>.output.<field> referenzierst. Eine unstrukturierte Ausgabe enthält freien Text. Verwende dafür nodes.<id>.output.text in einem Textausdruck; behandle die Ausgabe nicht wie ein Objekt mit weiteren Feldern.

Ein Werkzeug ohne Ausgabeschema liefert unstrukturierte Ausgabe. Soll daraus strukturierte Eingabe für weitere Schritte entstehen, nutze eine llm-Node mit outputSchema. Die Validierung nennt bei einem Fehler die ungültige Referenz und die zulässigen Felder oder Kontexte. Korrigiere die Referenz, bevor du erneut speicherst.

Pfade, die ein Lauf nehmen kann

Jede Bedingung und jede Node, die fehlschlagen darf, während der Lauf weitergeht, eröffnet einem Lauf zwei Möglichkeiten. Tale probiert jede Kombination davon aus und behält die unterschiedlichen Wege, die ein erfolgreicher Lauf nehmen kann; jeder davon ist ein Pfad. Ein Pfad nennt die Bedingungen, die über ihn entscheiden, etwa welche Nodes laufen, welche übersprungen werden und welche fehlschlagen, während der Lauf weitergeht, und die Nodes, die auf ihm laufen. Eine Node, die auf jedem Pfad läuft, läuft immer; eine Node, die auf keinem läuft, kann nie laufen, und Tale warnt davor.

Tale führt bis zu 32 Pfade auf und zählt die übrigen. Bei mehr als 12 Bedingungen und hingenommenen Fehlern sind die Kombinationen zu viele zum Durchgehen, deshalb führt Tale dann keinen Pfad auf; es sagt aber weiterhin bei jeder Node, wann sie läuft. Außerdem nennt Tale die Nodes, deren Fehler den Lauf beendet, und was jede von ihnen fehlschlagen lassen kann. Der Editor zeigt die Pfade im Canvas, wie Den möglichen Pfaden folgen beschreibt; ein Client des MCP-Endpoints liest dieselben Pfade aus analysis.paths.

Was Tale vor einem Lauf prüft

Tale prüft das ganze Dokument, wenn du es speicherst, wenn du eine Version bereitstellst und wann immer ein Client validate_automation aufruft. Ein Fehler beschreibt etwas, das sicher scheitert, oder Code, der die Analysegrenzen überschreitet. Er verhindert Speichern wie Bereitstellen. Eine Warnung zeigt auf etwas, das scheitern kann oder nichts Nützliches tut. Sie verhindert weder Speichern noch Bereitstellen; du entscheidest selbst, ob du etwas änderst. Jedes Problem nennt seine Node und sein Feld und, in einem Template, einer Bedingung oder in Code, den genauen Ausdruck.

Damit die Prüfung zügig bleibt, ist jeder Ausdruck auf 8192 UTF-16-Codeeinheiten und 512 JavaScript-Tokens begrenzt. Für transform-Code gelten 16384 Codeeinheiten und 4096 Tokens. Beide dürfen höchstens 64 Verschachtelungsebenen in der Syntax oder im Syntaxbaum enthalten. Leerraum um einen Template-Ausdruck zählt nicht zu seiner Größe; Leerraum im Transform-Code zählt mit. Reiner Text außerhalb von Templates ist kein Code. Diese Grenzen können zuvor gültigen Code ablehnen. Kürze ihn oder verteile die Arbeit auf mehrere Nodes, bevor du erneut speicherst oder bereitstellst.

Referenzen und Namen

Jedes nodes.<id> muss eine bestehende Node nennen, ihr Ergebnis über .output lesen und darf keinen Kreis von Nodes schließen, die einander lesen. Liest eine Referenz ein Feld, das ihre Quelle nicht hat, etwa beim Tippfehler nodes.calc.output.cuont, gibt es eine Warnung mit dem ähnlichsten Feld als Vorschlag. Tale meldet auch Namen, die ein Ausdruck nicht sieht, etwa item außerhalb von forEach oder ein vertipptes input, und ein input.<key>, das inputs nicht deklariert.

Typen

Tale kennt die Form der meisten Werte: die Eingabe des Laufs aus inputs, die Ausgabe einer Capability aus ihrer Signatur im Katalog, die Ausgabe einer llm-Node aus ihrem outputSchema und die einer transform-Node aus dem Objekt, das ihr Code zurückgibt. Tale warnt, wenn ein Wert an einer Stelle landet, die einen anderen Typ braucht, etwa eine Zahl, wo eine Capability Text erwartet, oder ein Objekt, wo forEach eine Liste braucht. Außerdem warnt Tale, wenn ein Wert, der in Text eingesetzt wird, fehlen kann, denn ein fehlender Wert lässt die Node dort scheitern.

Übersprungene und fehlgeschlagene Nodes

Eine Node wird übersprungen, wenn ihr when falsch ist, wenn ihr elseOf-Partner läuft oder wenn eine Node übersprungen wird, die sie in input, prompt, system, files, code oder forEach liest. Eine Node mit onError: continue wird übersprungen, wenn sie fehlschlägt. Die Ausgabe einer übersprungenen Node ist null, und eine Node, die eine übersprungene Node in einem dieser Felder liest, wird ebenfalls übersprungen. Ein Lesezugriff in when oder repeatUntil überspringt die Node nicht: Die Bedingung läuft und liest null.

Liest eine Bedingung oder die output der Automatisierung ein Feld einer Node, die übersprungen werden kann, schlägt das Lesen also in den Läufen fehl, in denen diese Node nicht lief. Dasselbe passiert, wenn der Wert einer solchen Node in Text steht, etwa in Summary: {{ nodes.summary.output?.text }}: ?. liefert dort keinen Wert, und Text lehnt einen fehlenden Wert ab. Tale warnt bei jedem solchen Lesezugriff und sagt eigens dazu, wenn die Ursache ein Fehler ist, den onError: continue toleriert. Sichere den Lesezugriff mit ?. und einem Ersatzwert ab: {{ nodes.check.output?.ok ?? false }} in einer Bedingung, {{ nodes.summary.output?.text ?? null }} in der Ausgabe. Alternative Zweige treffen sich in der output der Automatisierung, nicht in einer Node, die beide liest:

output:
  message: '{{ nodes.summary.output?.text ?? nodes.summary_empty.output?.text }}'

Nodes, die nie laufen können

Manche Nodes können nie laufen: eine, deren Bedingung immer falsch ist, die Alternative einer Node, die immer läuft, oder eine Node, die zwei Zweige liest, die nie zusammen laufen. Tale warnt bei jeder davon. Eine Node, deren Ausgabe niemand liest und die nichts bewirkt, meldet Tale als unbenutzt.

Bedingungen und Schleifen

Eine Bedingung, die immer dieselbe Antwort liefert, entscheidet nichts. Text um ein Template macht when zum Beispiel zu einem nicht leeren String, und der gilt immer als wahr. Ein repeatUntil, das immer falsch ist, durchläuft alle maxRepeats Durchgänge, und eines, das das Ergebnis des Durchgangs (output) nie liest, liefert nach jedem Durchgang dieselbe Antwort.

Iteration

forEach muss ein einzelnes Template sein, das eine Liste ergibt. Reiner Text, Text um ein Template oder ein fester Wert, der keine Liste ist, ist ein Fehler, denn die Node scheitert bei jedem Lauf. when und forEach werden einmal gelesen, bevor die Node ihre Elemente durchläuft. item und index gibt es dort deshalb nicht, und sie dort zu verwenden ist ebenfalls ein Fehler. Eine agent-Node kann forEach und repeatUntil noch nicht verwenden.

Aufgerufene Automatisierungen

Eine subautomation-Node wird gegen die Version geprüft, die ein Lauf aufrufen würde: die genannte Version, sonst die bereitgestellte, sonst die neueste. Diese Version muss existieren und darf keine agent-Node enthalten. Tale warnt, wenn die Eingabe nicht zu ihren inputs passt und wenn sie einen Schreibzugriff ausführt, den eine Freigabe aufhalten könnte, denn eine aufgerufene Automatisierung kann nicht warten. Auch ein Zeitplan-Trigger, dessen Starteingabe die inputs der Automatisierung ablehnen, wird gemeldet.

Was die Organisation hat

Tale vergleicht eine agent-Node außerdem mit deiner Organisation. Es warnt, wenn die Node einen Skill verlangt, den kein Lauf der Automatisierung verwenden kann, einen Connector, den niemand verbunden hat, ein Secret, das niemand gespeichert hat, oder eine Agent-Laufzeit, die dieses Deployment nicht ausführen kann. Dieselbe Warnung bekommt eine Node, die eine Connector-Aktion ausführt, deren Connector niemand verbunden hat, und ein Ereignis-Trigger, der auf ein Ereignis wartet, das Tale nicht auslöst. Im Lauf schlägt die Node fehl, wenn ihr Skill oder ihre Agent-Laufzeit fehlt; ohne ihren Connector erreicht sie die App nicht, und ein fehlendes Secret ist einfach nicht vorhanden. Auch eine Connector-Node, die Zugangsdaten nennt, die ihr Connector nicht in Betrieb hat, erhält eine Warnung; ein Live-Lauf scheitert an dieser Node.

Es bleiben Warnungen, weil sich deine Organisation bis zum Lauf ändern kann: Verbinde den Connector oder füge den Skill hinzu, dann meldet die nächste Prüfung nichts mehr. Über Secrets erfahren nur Inhaber, Admins und Entwickler etwas, denn nur sie sehen, welche Secrets es gibt.

HTTP-Schritte

Eine http.get- oder http.send-Node ohne Zugangsdaten erhält eine Warnung für eine einfache http://-Adresse, die ihr Lauf ablehnen würde. Zugangsdaten in ihrer Adresse, etwa ein Token in einem Query-Parameter, und ein Authorization- oder Cookie-Header, den die Node setzt, sind Fehler: Speichere die Zugangsdaten stattdessen unter Einstellungen › Connectors und nenne sie im Feld credential der Node. Siehe Eine API aus einer Automatisierung aufrufen.

Tests

Die Eingabe eines Tests muss zu inputs passen, jeder erwartete Effekt muss von einer Node stammen, die ihn ausführt, und ein erwarteter Ausgabewert muss einen Typ haben, den die Automatisierung zurückgeben kann. Ein Test, der gegen eine dieser Regeln verstößt, kann nie bestehen, deshalb warnt Tale, bevor du ihn ausführst.

Versionen ändern sich nie

Speichern legt eine neue Version an, statt die vorige zu überschreiben. Die Nummerierung beginnt für jede Automatisierung bei 1; jede Version enthält die Änderungsnotiz ihres Autors. Der Workflow einer vorhandenen Version bleibt unverändert.

Ein laufender Workflow behält die Version, mit der er gestartet wurde. Spätere Bearbeitungen ändern seine Schritte nicht. Öffne bei der Prüfung eines älteren Laufs dessen aufgezeichnete Version, um Eingabe und Ablauf zu vergleichen. Unveränderlichkeit ist keine unbegrenzte Aufbewahrung: Beim Löschen einer Automatisierung oder ihrer Historie können die Datensätze entfernt werden.

Live-Schalten ist ein eigener Schritt

Genau eine Version pro Automatisierung ist live, und diese Version führen die Trigger aus. Eine Version live zu schalten oder auf eine ältere zurückzugehen ist ein einzelner Schritt, der keine Historie umschreibt — die Versionsliste bleibt exakt, wie sie war, und nur der Zeiger wandert. Eine Automatisierung darf auch gar nichts live haben und rein als Entwurf existieren.

Eine Version mit einem fehlgeschlagenen Test lässt sich nicht live schalten; eine Version, deren Tests bestanden sind oder die gar keine Tests hat, schon. Tests liegen im Dokument: Jeder hat einen Namen, eine Eingabe und Erwartungen an die Ausgabe sowie an die Auswirkungen, die der Lauf erzeugen soll. Tale führt die Tests einer Version beim Speichern aus und beim Live-Schalten noch einmal, und die Version behält das letzte Ergebnis. Eine Automatisierung testen zeigt, wie du sie schreibst und ausführst.

Was einen Lauf startet

Eine gespeicherte Version kannst du manuell testen; die bereitgestellte Version lässt sich live ausführen. Für automatische Starts richtest du eine von drei Trigger-Arten ein: einen Zeitplan, der sich zu festen Uhrzeiten oder in einem Intervall in seiner Zeitzone wiederholt, eine durch ein Token geschützte Webhook-URL oder ein benanntes Plattformereignis. Jeder davon kann eine feste Eingabe mitgeben, die jeder Lauf erhält.

Der Trigger gehört zum Namen der Automatisierung. Bei einer neuen Bereitstellung bleiben Konfiguration und Webhook-URL erhalten; nachfolgende Starts verwenden die neu bereitgestellte Version. Deaktiviere den Trigger, um automatische Starts zu pausieren. Workflow-Trigger erklärt Zeitsteuerung, Anmeldung und die Eingabe jeder Trigger-Art.

Was ein Lauf festhält

Ein Lauf speichert Status (queued, running, waiting, success, failed oder cancelled), Modus, Auslöser, Eingabe, Ausgabe und einen Checkpoint für jede abgeschlossene Node. Die Ablaufspur zeigt die vom Ausführungssystem versuchten Schritte.

Gibt die Verarbeitung vorübergehend ab, setzt derselbe Lauf anhand seiner Checkpoints fort, ohne abgeschlossene Nodes erneut auszuführen. Die Liste der Auswirkungen erfasst Connector-Schreibaktionen. Sie ist kein vollständiges Verzeichnis der Änderungen durch eine Sandbox oder direkte Werkzeuge. Für die Laufhistorie gelten weiterhin Löschung und Aufbewahrungseinstellungen.

Im Modus Test werden externe Aktionen simuliert. Live kann sie tatsächlich ausführen und benötigt zum Starten Entwicklerrechte. Unter Ausführungsprotokolle erfährst du, wie du gespeicherte Version, aufgelöste Eingaben, Fehler und protokollierte Auswirkungen prüfst.

Wo ein Mensch entscheidet

Eine erforderliche Freigabe hält den Lauf vor einer geschützten Schreibaktion im Status waiting an. Die Freigabe erlaubt den Ausführungsversuch, garantiert aber keinen Erfolg. Ablehnen verhindert die Aktion und lässt den Lauf fehlschlagen. Eine Frage pausiert ebenfalls, verlangt jedoch Informationen statt einer Erlaubnis.

Der Status waiting kann auch bedeuten, dass ein Agent noch arbeitet, dass ein Agent-Schritt für seinen Start auf einen Sandbox-Platz wartet oder dass eine Node ihre Bedingung wiederholt prüft. Lies deshalb waitingFor: approval, ask und in_doubt brauchen eine Person; agent, room und repeat setzen normalerweise automatisch fort. in_doubt heißt, dass ein Schritt gerade etwas an einen externen Dienst gesendet hat, als der Lauf unterbrochen wurde, und Tale nicht erkennen kann, ob der Dienst es erhalten hat. Niemand wird benachrichtigt; entscheide es auf der Seite des Laufs, wie Automatisierungsläufe prüfen und Fehler beheben es beschreibt. Freigaben in Workflows erklärt, wie du die menschlichen Anfragen prüfst und beantwortest.

Chat, Aufgabe oder Automatisierung wählen

Prüfe vor dem Erstellen die mitgelieferten Automatisierungen. Ein Webhook startet eine Automatisierung; er ist keine eigene Art von Projektagent.

Das Modell in die Praxis bringen

Workflow, Versionen, Bereitstellung und Trigger sind getrennte Bestandteile einer Automatisierung. Folge dem Workflow-Editor, um eine Änderung zu testen und live zu schalten. Die Ausführungsprotokolle zeigen, was ein Lauf getan hat.