Workflows Guide

So sehen Workflows in Langdock aus: Nodes auf einer visuellen Canvas verbinden – ohne Code.

Die Evolution: Chat → Agenten → Workflows

Du kennst Langdock bereits aus dem Chat und hast vielleicht schon eigene Agenten gebaut. Workflows sind der nächste logische Schritt: Statt manuell mit KI zu interagieren, automatisierst du komplette Prozesse von Anfang bis Ende.

Der Unterschied in einem Satz:

• Chat = Du fragst, KI antwortet (1:1 Dialog)
• Agenten = KI mit Spezialwissen und Kontext (konfigurierter Assistent)
• Workflows = Mehrere Schritte laufen automatisch ab – mit KI, Logik und Integrationen (End-to-End-Automation)

Wann lohnen sich Workflows?

Workflows sind dann sinnvoll, wenn du einen Prozess hast, der:

• Wiederkehrend ist (z.B. jeden Tag, jede Woche, bei jedem neuen Lead)
• Mehrere Schritte umfasst (Daten empfangen → analysieren → weiterleiten → dokumentieren)
• Keine menschliche Kreativität im Kern braucht (Routing, Kategorisierung, Standardkommunikation)
• Fehleranfällig ist, wenn manuell ausgeführt (vergessene Follow-ups, inkonsistente Kategorisierung)

Was Workflows NICHT ersetzen

Workflows sind kein Ersatz für kreative Arbeit, strategische Entscheidungen oder komplexe Einzelfallbearbeitung. Sie übernehmen die repetitive Vorarbeit, damit dein Team sich auf das Wesentliche konzentrieren kann.

Was ist ein Node?

Ein Node (Knoten) ist ein einzelner Schritt in deinem Workflow – vergleichbar mit einem Baustein. Jeder Node hat genau eine Aufgabe: Daten empfangen, KI etwas analysieren lassen, eine Bedingung prüfen, eine E-Mail senden, und so weiter.

Nodes werden auf einer visuellen Canvas (Arbeitsfläche) per Drag & Drop platziert und miteinander verbunden. Keine Programmierung nötig – es sei denn, du willst den Code-Node nutzen.

Anatomie eines Nodes

Jeder Node hat:

• Header: Zeigt Typ und Name. Hier findest du auch den Play-Button zum Testen.
• Input-Tab: Zeigt, welche Daten der Node empfangen hat (nach einem Test-Run).
• Output-Tab: Zeigt, welche Daten der Node produziert hat.
• Konfigurationspanel: Öffnet sich per Klick – hier stellst du alles ein.

Connections: Wie Daten fließen

Die Linien zwischen Nodes sind mehr als nur Dekoration: Sie bestimmen die Ausführungsreihenfolge und den Datenfluss.

• Links (Eingang): Woher die Ausführung kommt
• Rechts (Ausgang): Wohin die Ausführung weitergeht
• Mehrere Ausgänge: Condition-Nodes haben einen Ausgang pro Bedingung
• Roter Ausgang: Spezieller Error-Pfad (wenn aktiviert)

Ausführungsmodelle

Sequenziell (Standard): Nodes laufen nacheinander ab. Node B wartet, bis Node A fertig ist.

Parallel: Wenn mehrere Nodes an einen einzelnen Ausgang angeschlossen sind, laufen sie gleichzeitig. Das beschleunigt deinen Workflow, wenn die Schritte voneinander unabhängig sind.

                → E-Mail senden →
Trigger →       → Ticket erstellen →      → Weiter
                → Datenbank aktualisieren →

Error Handling

Für jeden Node kannst du individuell festlegen, was bei einem Fehler passiert:

• Workflow stoppen (Fail): Der gesamte Workflow wird als fehlgeschlagen markiert. Sinnvoll für kritische Schritte.
• Workflow fortsetzen (Continue): Der Fehler wird protokolliert, aber der Workflow läuft weiter. Sinnvoll für optionale Schritte.
• Error Callback: Die Ausführung wird über den roten Error-Ausgang an andere Nodes umgeleitet. Sinnvoll für Fallback-Logik.

Nodes deaktivieren

Einzelne Nodes können temporär deaktiviert werden, ohne sie zu löschen. Deaktivierte Nodes werden bei der Ausführung übersprungen – ideal zum Debuggen oder für optionale Schritte, die du vorübergehend ausschalten willst. Per Rechtsklick auf den Node oder über das Node-Menü kannst du den Status umschalten.

Canvas: Auswählen, kopieren, annotieren

Ab einer gewissen Größe ist ein Workflow kein Diagramm mehr, sondern ein Arbeitsplatz. Zwei Handgriffe machen daraus wieder etwas Lesbares:

• Mehrere Nodes auswählen und kopieren seit August 2026: Per Shift-Klick markierst du mehrere Nodes und kopierst ganze Subgraphen – samt Verbindungen und Layout. Ein einmal sauber gebauter Teilablauf (etwa Guardrail → Agent → Condition) wird damit zum Baustein, den du innerhalb eines Workflows oder in einen anderen dupliziert, statt ihn dreimal von Hand nachzubauen. Nachbauen ist die häufigste Quelle für Abweichungen, die niemand bemerkt.
• Sticky Notes seit August 2026: Du kannst Haftnotizen auf den Canvas legen – mit Markdown-Text und Farbpresets, und ohne Einfluss auf die Ausführung. Der richtige Ort für das, was sonst niemand rekonstruieren kann: warum die Schwelle bei 0,8 liegt, welcher Ansprechpartner hinter einer Webhook-URL steht, was beim nächsten Durchgang noch aufzuräumen ist.

Workflows als Bausteine: ein Workflow ruft den nächsten

Verschachtelte Workflow-Aufrufe seit September 2026: Ein veröffentlichter Workflow kann einen anderen veröffentlichten Workflow aufrufen, auf dessen Ergebnis warten und danach weiterlaufen. Im Editor wählst du den aufrufbaren Workflow aus und mappst seine Inputs, genau wie bei einer Action.

• Verschachtelungstiefe maximal 5: Ein aufgerufener Workflow darf selbst wieder aufrufen, insgesamt aber höchstens fünf Ebenen tief.
• Zyklus-Erkennung eingebaut: Ruft A den Workflow B und B wieder A, erkennt Langdock das und verhindert den Kreislauf. Du musst nicht selbst mitzählen.
• Sichtbar bleibt es auch: Verschachtelte Läufe erscheinen auf der Canvas, in der Run-Historie und in den Tabellen mit den Markierungen Called by und Nested in. Ein Fehler in Ebene drei lässt sich damit bis zum auslösenden Lauf zurückverfolgen.

Testlauf: Trigger only oder Full flow

Zwei Buttons statt Menü seit September 2026: Das Test-Panel hat zwei dauerhaft sichtbare Buttons, statt die Auswahl in einem Menü zu verstecken:

• Trigger only: Führt nur den Trigger aus und zeigt dir dessen Output. Der richtige Knopf, wenn du erst wissen willst, welche Felder ein Webhook oder eine Integration überhaupt liefert, bevor du die nachfolgenden Nodes darauf verdrahtest.
• Full flow: Lässt den kompletten Ablauf durchlaufen. Erst wenn die Feldnamen stimmen, sinnvoll, sonst zahlst du für Agent-Nodes, die auf leere Variablen schauen.

Workflow Builder Chat

Statt jeden Node manuell zu platzieren, kannst du Workflows auch per natürlichsprachlicher Beschreibung erstellen lassen. Der Workflow Builder Chat (Button unten links im Builder) generiert aus deiner Beschreibung einen kompletten Workflow.

• Workflows beschreiben: „Erstelle einen Workflow, der jeden Montag einen Report aus Google Sheets generiert und per Slack versendet.“
• Fix in Chat: Bei Fehlern erscheint ein Button, der die Fehlerdetails automatisch an den Chat übergibt – die KI analysiert das Problem und schlägt Korrekturen vor.
• Preferences: Über das Einstellungen-Panel kannst du bevorzugte Tools (E-Mail, CRM, Ticketing) und Custom Instructions hinterlegen.
• JSON-Import und -Export: Bestehende Workflows als .json importieren – per Datei-Upload oder direkt in den Chat einfügt – und über das Drei-Punkte-Menü neben dem Workflow-Namen wieder exportieren. Ideal für die Übertragung zwischen Workspaces. Wirfst du eine Datei aus n8n, Make oder Zapier hinein, erkennt Langdock das Fremdformat und verweist auf den Builder-Chat: Der Assistent baut den Ablauf dann als Langdock-Workflow nach, statt die Datei stumpf abzulehnen.
• Chat-Verlauf: Über das Chat-History-Icon oben rechts im Builder kommst du an frühere Unterhaltungen zu diesem Workflow zurück – hilfreich, wenn du nach ein paar Tagen nachvollziehen willst, warum ein Node so konfiguriert ist, wie er ist.
• Trigger-Parameter seit Juni 2026: Der Assistent berücksichtigt jetzt die Beschreibungen der Trigger-Eingabefelder und hilft dadurch deutlich gezielter beim Konfigurieren der Trigger-Parameter im Builder.
• Stärkere Modelle im Builder-Chat seit Juli 2026: Der Workflow-Chat unterstützt jetzt auch Opus und Reasoning-/Thinking-Modelle mit einem eigenen Extended-Thinking-Schalter. Für komplexe Workflows, die der Assistent aus einer Beschreibung aufbauen oder debuggen soll, liefert das spürbar durchdachtere Vorschläge.
• Dein Canvas-Layout überlebt die Chat-Edits seit Juli 2026: Früher ordnete der Assistent den Canvas bei jeder Änderung neu an – wer sich ein Layout zurechtgelegt hatte, fand es danach nicht wieder. Jetzt bleiben bestehende Nodes an ihrem Platz, und neue Nodes werden direkt neben dem Node platziert, an den sie andocken. Willst du doch aufräumen lassen, nutzt du den Auto-Reorder-Button auf dem Canvas oder bittest den Assistenten im Chat darum.
• Editor-Zugriff als Voraussetzung seit Juli 2026: Der Workflow-Chat lädt den Draft-Kontext eines Workflows erst, wenn du Editor-Rechte darauf hast. Wer nur Ausführungsrechte hat, bekommt keinen halb geladenen Chat mehr, der auf Lücken hin rät.
• Klartext bei kaputter Modell-Verbindung seit August 2026: Ist die Verbindung zu einem Modellanbieter im Workspace falsch konfiguriert, meldet der Workflow-Chat das jetzt konkret und mit Handlungsanweisung, statt generisch zu scheitern. Das spart die Suche an der falschen Stelle: Der Fehler liegt dann nicht am Workflow, sondern an den Workspace-Einstellungen.
• Antworten laufen im Hintergrund weiter seit September 2026: Schließt du das Chat-Panel, während der Assistent noch generiert, bricht die Antwort nicht mehr ab. Sie wird fertig gerechnet und steht vollständig da, sobald du das Panel wieder öffnest.
• Klare Fehler bei ungültigen Importen seit September 2026: Scheitert ein JSON-Import, öffnet sich ein Detail-Dialog mit konkreten Validierungsmeldungen und kopierbaren Fehlerpfaden auf die betroffene Stelle im JSON. Statt »Import fehlgeschlagen« weißt du, welcher Node und welches Feld das Problem sind.

Jeder Workflow braucht einen Startpunkt – den Trigger. Er bestimmt, wann und wodurch dein Workflow ausgelöst wird.

Übersicht der Trigger-Typen

Mehrere Trigger pro Workflow seit September 2026: Ein Workflow ist nicht mehr auf einen Startpunkt festgelegt. Du kannst mehrere Trigger an denselben Ablauf hängen, sodass dieselbe Automatisierung aus verschiedenen Quellen startet: der Rechnungs-Workflow per Gmail-Trigger im Regelbetrieb, zusätzlich per Manual Trigger für Nachzügler, die jemand von Hand einwirft. Das erspart die verbreitete Notlösung, denselben Ablauf zweimal zu bauen und danach doppelt zu pflegen.

Manual Trigger

Der einfachste Trigger: Ein Klick startet den Workflow. Perfekt zum Entwickeln und Testen. Jeder neue Workflow sollte zunächst mit einem Manual Trigger gebaut und getestet werden, bevor du auf einen automatischen Trigger umstellst.

Form Trigger

Erstellt ein Webformular, das den Workflow bei Absendung startet. Ideal für die Datenerfassung von internen oder externen Nutzern.

Verfügbare Feldtypen:

• Text (einzeilig), Long Text (mehrzeilig)
• E-Mail, Telefon, Nummer
• Datum, Dropdown, Checkbox
• Datei-Upload – strukturierte Datei-Felder nehmen seit August 2026 auch Video-Uploads an

Wichtige Einstellungen:

• Formulartitel und Beschreibung definieren
• Felder als Pflichtfelder markieren
• „Thank You“-Nachricht konfigurieren
• Öffentlichen Zugang aktivieren (für externe Nutzer)
• Erlaubte E-Mail-Domains: Ein E-Mail-Feld lässt sich über Allowed email domains auf eine oder mehrere Domains einschränken (kommagetrennt, etwa decaid.ai, decaid.studio). Eine Einreichung mit fremder Absenderdomain wird abgewiesen. Das ist die einfachste Zugangskontrolle für ein öffentliches Formular: Der Link darf herumliegen, absenden kann trotzdem nur, wer eine Adresse aus der Firma hat. Ersetzt keine Authentifizierung – die Domain wird nicht verifiziert, sondern nur geprüft.
• iframe-Einbettung (seit März 2026): Workflow-Formulare können per <iframe> in externe Webseiten, Intranets oder Portale eingebettet werden – Nutzer müssen Langdock nicht verlassen.
• Ergebnisseite mit Datei-Download seit August 2026: Nach dem Absenden eines öffentlichen Formulars landen Nutzer auf einer sicheren Ergebnisseite, auf der sie die vom Workflow erzeugten Dateien ansehen und herunterladen können. Damit wird das Formular vom reinen Eingabekanal zum vollständigen Selbstbedienungs-Ablauf: Angebot anfordern, PDF zurückbekommen – ohne dass jemand die Datei anschließend von Hand hinterherschickt.

Webhook Trigger

Stellt eine eindeutige URL bereit, die externe Systeme per HTTP POST aufrufen können. Der ideale Trigger, wenn du Langdock mit eigenen Anwendungen, GitHub, Stripe oder anderen Services verbinden willst.

Auth-Modi (drei Varianten):

• No Auth: URL ist öffentlich zugänglich. Nur für Tests oder bewusst öffentliche Endpoints.
• Query-Parameter: Token wird als URL-Parameter mitgeschickt (z.B. ?secret=xyz). Sichtbar in Logs, nur für interne Setups geeignet.
• X-Webhook-Secret Header (empfohlen): Token im HTTP-Header. Wird nicht in Logs/Referrern geleakt, der saubere Weg für Produktion.

Payload und Dateien:

Der Request-Body darf maximal 25 MB groß sein – inklusive Base64-kodierter Dateiinhalte. Neben JSON-Body und Query-Parametern nimmt der Webhook auch bis zu 20 Dateien entgegen: eine einzelne unter dem Key file, mehrere unter files, jeweils als Base64 (binär) oder Text. Im Workflow greifst du darauf mit {{trigger.output.body.files[0].path}} zu.

Rohen Request-Body erhalten Option: Schaltest du Preserve raw request body ein, bekommt der Workflow den unveränderten Body – nötig, wenn du eine Provider-Signatur selbst nachrechnen willst. Der Preis dafür ist ein kleineres Limit von 12 MB statt 25 MB. Zusätzlich gibt es Include signature headers: Damit reicht Langdock die Signatur-Header von Stripe, GitHub, Slack, DocuSign, Shopify, Svix und Standard Webhooks durch – in Kleinschreibung, darauf muss dein Vergleich achten. Beide Schalter liegen unter Advanced options und sind ab Werk aus. Schaltest du sie ein, landen headers und rawBody im Trigger-Output; andere eingehende Header bleiben weiterhin draußen.

Webhook-Link im Browser aufrufbar seit September 2026: Ein Webhook lässt sich jetzt auch dadurch auslösen, dass jemand seine URL im Browser öffnet. Damit wird aus dem Webhook ein Start-Link, den du hinter einen Button, in eine Slack-Nachricht oder in ein Intranet legen kannst, ohne dass der Auslöser ein System sein muss. Genau deshalb gehört ein solcher Link nie ohne Secret in Umlauf: Wer die URL hat, startet den Workflow mit einem Klick.

Response-Codes des Endpoints:

Praktisch fürs Debugging: Ein 429 ist fast nie ein Fehler im aufrufenden System, sondern ein Trigger-Storm oder ein erreichtes Kostenlimit – prüfe zuerst die Limits des Workflows, bevor du am Client suchst.

Scheduled Trigger

Führt den Workflow automatisch zu festgelegten Zeiten aus. Perfekt für wiederkehrende Aufgaben.

Zeitplan-Optionen:

• Alle X Minuten
• Stündlich / Täglich / Wöchentlich / Monatlich
• Benutzerdefinierter Cron-Ausdruck
• Zeitzone konfigurierbar

Beispiele:

• Täglicher Sales-Report um 9:00 Uhr
• Stündlicher Daten-Sync mit externem System
• Wöchentliche Cleanup-Aufgabe sonntags

Integration Trigger

Reagiert auf Events in verbundenen Apps: Neue Slack-Nachricht, neue E-Mail, neue Datei in Google Drive, Kalender-Event und mehr.

Unterstützte Integrationen (Auswahl):

• Kommunikation: Slack, Microsoft Teams, Gmail, Outlook Email
• Produktivität: Jira, Microsoft SharePoint
• Speicher: Google Drive
• CRM: Salesforce, HubSpot, Pipedrive
• Kalender: Google Calendar, Outlook Calendar
• Entwicklung: GitHub
• Sonstige: Stripe, Calendly, Ashby, Power BI

Konfiguration in drei Schritten:

1. Integration auswählen
2. Event-Typ wählen (z.B. „Neue Nachricht in Kanal“)
3. Filter konfigurieren (z.B. nur bestimmte Kanäle oder Schlüsselwörter)

Fehlgeschlagene Trigger-Abfragen werden jetzt sichtbar seit Juli 2026: Wenn ein Integration Trigger beim Abfragen (Polling) des Quellsystems auf einen Fehler läuft – abgelaufene Verbindung, Rate-Limit, Auth-Problem – taucht das jetzt als fehlgeschlagener Run mit klarer Fehlermeldung in der Run-Historie auf, statt still zu verpuffen. Damit merkst du sofort, wenn ein Trigger nicht mehr zuverlässig feuert, und musst nicht raten, warum ein erwarteter Lauf ausgeblieben ist.

Neue Trigger-Quellen seit Juli 2026: Microsoft SharePoint liefert zwei neue Workflow-Trigger: New item created (neues Element in einer Liste oder Bibliothek) und File updated (Datei geändert). Damit lassen sich Dokumenten-Prozesse endlich am Ort ihrer Entstehung anstoßen, statt sie per Zeitplan nachzuschauen. Neu dazugekommen ist außerdem die Integration Pipedrive mit sechs Polling-Triggern über Deals, Personen, Organisationen, Aktivitäten, Leads und Notizen.

Workflow-Start aus Chat und Agents seit März 2026

Seit März 2026 können Workflows direkt aus Chat-Konversationen und Agenten-Chats heraus gestartet werden – über das @-Menü. Tippe @ im Chat-Eingabefeld und wähle einen Workflow aus der Liste.

Ideal für On-Demand-Automatisierungen: Du bist mitten in einer Konversation, brauchst eine Auswertung oder möchtest einen Prozess anstoßen – und kannst den Workflow direkt starten, ohne die Chat-Oberfläche zu verlassen.

Zwei Wege in den Chat

• Direkt per @-Menü: Du tippst @, wählst den Workflow und schickst die Nachricht ab. Du entscheidest, was wann läuft.
• Über einen Agenten: Hängt der Workflow als Action an einem Agenten, entscheidet der Agent selbst, wann er ihn braucht – genauso wie bei jeder anderen Action.

Welche Trigger im Chat funktionieren

Aus dem Chat heraus starten lassen sich nur Workflows mit Manual-, Form- oder Scheduled-Trigger. Ein Scheduled-Workflow läuft dann zusätzlich zu seinem Zeitplan auf Zuruf. Webhook- und Integration-Trigger sind im Chat nicht ansprechbar – sie warten definitionsgemäß auf ein externes Ereignis. Wer einen ereignisgesteuerten Workflow auch manuell anwerfen will, braucht dafür eine zweite Variante mit Manual- oder Form-Trigger.

Bestätigung ist Pflicht

Kein Workflow startet im Chat ohne ausdrückliche Freigabe – einen Auto-Ausführen-Modus gibt es bewusst nicht. Bei Manual- und Scheduled-Triggern erscheint ein kompaktes Panel mit Trigger und Decline. Bei Form-Triggern werden die Formularfelder direkt im Chat gerendert; Datei-Felder füllen sich dabei automatisch vor – bei Mehrfach-Feldern mit bis zu 50 der neuesten Dateien aus der Konversation seit August 2026, bei Einzelfeldern mit der zuletzt hochgeladenen. Hat ein Formular mehrere Einzel-Datei-Felder, bekommt jedes eine der neuesten Dateien in Upload-Reihenfolge. Die Vorbefüllung ist ein Vorschlag, kein Zwang: Du kannst sie vor dem Bestätigen ändern oder leeren. Danach zeigt der Chat den Lauf live an („Running …“), am Ende Status, Laufzeit und Ergebnis.

Grenzen, die man kennen sollte

• Ein Workflow pro Antwort: Eine KI-Antwort kann genau einen Workflow-Aufruf auslösen. Ketten aus mehreren Workflows gehören in den Workflow selbst, nicht in den Chat.
• Keine Workflows aus Agenten heraus, die ein Workflow selbst startet: Agent-zu-Agent-Aufrufe von Workflows sind gesperrt, damit sich nichts rekursiv selbst triggert.
• Nicht in den Mobile-Apps: Workflow-Starts laufen nur im Web.
• Namenslänge: Der Tool-Name eines Workflows ist auf 63 Zeichen begrenzt. Sehr lange Workflow-Namen werden abgeschnitten – halte sie kurz und eindeutig.
• Zugriff wird zu unterschiedlichen Zeitpunkten geprüft: Beim @-Menü muss der Zugriff im Moment des Aufrufs stehen. Bei Agent-Actions wird erst zur Ausführung geprüft – fehlt der Zugriff, sieht der Nutzer mitten in der Konversation eine Access Denied-Meldung. Wer einen Workflow an einen geteilten Agenten hängt, gibt ihn also auch für dessen Nutzer frei.

Agent Node – KI-Analyse & Content-Generierung

Der Agent Node ist das Herzstück der meisten Workflows. Hier kommt die KI ins Spiel: Texte analysieren, kategorisieren, zusammenfassen, generieren oder Entscheidungen treffen.

Zwei Optionen:

1. Bestehenden Agent verwenden: Nutzt einen Agent aus deinem Workspace mit dessen Konfiguration und Wissen.
2. Neuen Agent erstellen: Speziell für diesen Workflow konfiguriert und optimiert.

Structured Output (dringend empfohlen): Definiere das exakte Ausgabeformat als JSON-Schema. Dadurch erhältst du garantiert strukturierte Daten, die nachfolgende Nodes zuverlässig verarbeiten können.

{
  "sentiment": "negativ",
  "category": "bug",
  "priority": "hoch",
  "summary": "App stürzt beim Bild-Upload ab"
}

Max Steps: Standard: 25. Einstellbar je nach Aufgabenkomplexität (5-10 für einfache, 50-100 für komplexe Research-Aufgaben).

Extended Thinking / Reasoning-Toggle (seit Mai 2026): Extended Thinking lässt sich jetzt direkt im Agent Node per On/Off-Schalter aktivieren – eine separate Modellvariante ist nicht mehr nötig. Nur einschalten, wenn die Aufgabe wirklich Schritt-für-Schritt-Logik braucht (Mehrfach-Klassifikation mit Begründung, Routing-Entscheidungen mit mehreren Constraints). Für Standard-Extraktion und einfache Klassifikation lässt du es aus, das spart Token und macht den Run schneller.

Auto Model Mode seit Mai 2026: Im Modell-Selector des Agent Nodes gibt es jetzt einen Auto-Modus, der pro Aufruf das passende Modell anhand der Aufgaben-Komplexität wählt – einfache Klassifikation läuft auf einem kleinen, schnellen Modell, komplexe Analyse auf einem Spitzenmodell. Sinnvoll, wenn du nicht selbst Modell-Routing aufbauen willst. Für vorhersagbare Kosten und reproduzierbare Ergebnisse besser explizit ein Modell wählen.

Claude Sonnet 5 als agentisches Mittelklasse-Modell seit Juni 2026: Für Agent Nodes, die planen, Tools nutzen und mehrere Schritte autonom abarbeiten, ist Claude Sonnet 5 oft die beste Wahl: das agentischste Sonnet-Modell bisher, das laut Langdock nahe an Claude Opus 4.8 herankommt, aber deutlich günstiger läuft. EU-gehostet und in Workspaces mit früheren Sonnet-Versionen automatisch verfügbar. Faustregel: einfache Extraktion auf Haiku 4.5 oder Gemini 3.7 Flash, agentische Mehrschritt-Aufgaben auf Sonnet 5, nur die schwersten Analysen auf der Opus-Klasse.

Claude Opus 5 als neue Spitze seit Juli 2026: Claude Opus 5 ist seit dem 24.07.2026 in Langdock verfügbar und löst Opus 4.8 an der Spitze ab – stärker bei komplexem Reasoning und bei agentischen Aufgaben, die viele Schritte am Stück durchhalten müssen. EU-gehostet und in Workspaces, die schon frühere Opus-Versionen nutzen, automatisch aktiviert. Für Agent Nodes heißt das: Wo du bisher Opus 4.8 für die schwersten Fälle gesetzt hast, ist Opus 5 der neue Default. An der Faustregel ändert das nichts – Opus bleibt das teuerste Modell im Workflow und gehört nicht in einen Loop, der hundertfach läuft.

Gemini 3.7 Flash am günstigen Ende seit August 2026: Gemini 3.7 Flash ist seit dem 17.08.2026 in Langdock verfügbar und löst Gemini 3.5 Flash als aktuelles Flash-Modell ab – laut Langdock Googles bisher stärkstes Flash-Modell für Coding und agentische Aufgaben, mit Zugewinnen bei Software Engineering, Webentwicklung und Wissensarbeit. EU-gehostet und in Workspaces mit früheren Gemini-Versionen automatisch aktiviert. Für Workflows ist das die interessanteste Klasse überhaupt: Genau die Nodes, die hundertfach in Loops laufen, profitieren von einem besseren Modell zum Flash-Preis.

Verfügbare Tools:

• Web-Suche (für aktuelle Informationen)
• Code-Ausführung (Sandboxed Python)
• Integration Actions (optional mit Human Confirmation)
• Knowledge Folder (Zugriff auf Unternehmenswissen)
• Nested Agent Calls (andere Agents aufrufen)

Prompt Engineering Tipps:

• Sei explizit: „Kategorisiere als Bug, Feature Request oder Frage“ statt nur „Analysiere den Text“
• Gib Kontext: Erkläre die Rolle und den Hintergrund
• Nutze Beispiele: Zeige dem Agent, wie die gewünschte Ausgabe aussehen soll
• Beschränke die Ausgabe: „Antworte NUR mit einer der folgenden Kategorien: ...“

Condition Node – Bedingte Logik

Routet die Workflow-Ausführung basierend auf Bedingungen. Jede Bedingung hat einen eigenen Ausgangs-Pfad.

Typische Anwendungen:

• Priorität prüfen: {{agent.output.structured.priority === "high"}}
• Betrag prüfen: {{trigger.output.amount > 5000}}
• Status prüfen: {{customer.output.status != "inactive"}}

Verfügbare Operatoren (Manual Mode): Vergleich (===, !==, >, <, >=, <=), Logik (&&, ||, !), String-Methoden (.includes(), .startsWith(), .endsWith()). Mehrere Operatoren lassen sich kombinieren: {{trigger.output.score > 80 && agent.output.verified === true}}.

Modi und Toggles: Im Standard löst die erste zutreffende Bedingung aus, alle weiteren werden übersprungen. Mit Allow multiple conditions laufen alle zutreffenden Pfade parallel. Im Prompt AI-Modus formulierst du die Bedingungen natürlichsprachlich; mit Force Select Branch wird auch bei unklarer Lage immer mindestens ein Branch gewählt.

Neu (Juni 2026): In den Condition-Zeilen wird jetzt der Branch-Name zuerst angezeigt. Umbenannte Branches bleiben dadurch auch im Prompt-Modus eindeutig beschriftet – das erleichtert die Orientierung in verzweigten Workflows.

Code Node – Custom JavaScript

Für Datentransformationen, Berechnungen und benutzerdefinierte Logik, die kein KI braucht.

Perfekt für:

• Mathematische Berechnungen
• Daten umformatieren
• JSON parsen und manipulieren
• Datenvalidierung und -bereinigung
• Datum-/Zeitoperationen

const scores = agent.scores || [];
const average = scores.reduce((a, b) => a + b, 0) / scores.length;

return {
  average_score: average.toFixed(2),
  highest_score: Math.max(...scores),
  grade: average >= 90 ? "A" : average >= 80 ? "B" : "C"
};

Verfügbare Funktionen (JavaScript-Sandbox):

• ld.request() – HTTP-Requests ausführen
• ld.awsRequest() – SigV4-signierte Requests an AWS-Dienste (S3, API Gateway)
• ld.log() – Debug-Informationen ausgeben
• ld.wait() – Ausführung pausieren (0–30.000 Millisekunden)
• Datenkonvertierungen: ld.csv2parquet(), ld.parquet2csv(), ld.arrow2parquet(), ld.json2csv()
• SQL-Prüfung: ld.validateSqlQuery() (Syntax eines einzelnen Statements) und ld.ensureReadOnlySqlQuery() (erzwingt Read-only)
• ld.signWithRS256() – RSA-SHA256-Signaturen für JWT-Signing und OAuth
• Globale Helfer: atob()/btoa() (Base64), Buffer.from() (nimmt nur Array, Uint8Array oder ArrayBuffer), FormData (Multipart-Uploads)
• Standard-JavaScript (JSON, Date, Math, RegExp, Array, Object)

Dieselben ld.*-Utilities stehen auch in eigenen Integrationen zur Verfügung – in Actions, Triggern und Auth-Flows.

Limits eigener Actions: Eine Action aus einer eigenen Integration verarbeitet pro Aufruf höchstens 20 Dateien mit zusammen 100 MB – einzelne Bilder bis 20 MB, Tabellen und Videos bis 100 MB, Dokumente und Audio bis 256 bzw. 200 MB, immer gedeckelt durch die 100 MB Gesamtgröße. Die Ausführung läuft nach 2 Minuten in ein Timeout. Die Prüfung der Größe greift, bevor der Code startet: Zu große Anhänge scheitern sofort mit einer klaren Fehlermeldung, statt auf halber Strecke.

Python-Sandbox (alternativ zu JavaScript): Python läuft ohne Internet-Zugriff und ohne ld.*-Utilities, hat dafür vorinstallierte Libraries: pandas, numpy, openpyxl, pypdf. Erzeugte Dateien tauchen unter _files im Output-Objekt auf. Sinnvoll für tabellarische Auswertungen, Excel-Generierung und PDF-Parsing.

HTTP Request Node – Externe APIs

Rufe beliebige externe APIs auf: Daten abrufen, erstellen, aktualisieren oder löschen.

Methoden: GET, POST, PUT, PATCH, DELETE

Profi-Feature: Import from cURL – Paste einen cURL-Befehl aus einer API-Dokumentation, und alle Felder (URL, Headers, Parameter) werden automatisch ausgefüllt.

Konfiguration:

• URL: Unterstützt Variablen, z.B. https://api.example.com/users/{{trigger.output.user_id}}
• Headers: Key-Value-Paare für Auth, Content-Type etc.
• Query Parameters: Sauberer als in der URL hardcodiert
• Body: JSON mit Variablen (bei POST/PUT/PATCH)

Response nutzen:

{{http_node.output.status}}          → Statuscode (200, 404, etc.)
{{http_node.output.data}}             → Response Body
{{http_node.output.data.user.name}}   → Verschachteltes Feld

File Search Node – Unternehmenswissen durchsuchen

Durchsucht deine Knowledge Folder (Wissensordner) und gibt die relevantesten Ergebnisse zurück. Ideal für RAG-Patterns (Retrieval Augmented Generation).

Konfiguration:

• Knowledge Folder auswählen
• Suchanfrage definieren (Manual, Auto oder AI Prompt)
• Max. Ergebnisse festlegen (Standard: 10)

Was ein Knowledge Folder aufnimmt: Durchsuchbar sind textbasierte Formate – PDFs, Word-Dokumente, Markdown und Präsentationen. Tabellen (Excel, CSV), Bilder, Audio und Video nimmt ein Knowledge Folder nicht an. Wer solche Daten im Workflow braucht, holt sie über eine Action aus dem Quellsystem oder wertet sie im Code Node aus – die häufigste Erklärung dafür, dass eine Datei „im Ordner liegt“, aber nie als Treffer auftaucht.

Empfehlungen für Max. Ergebnisse:

• 1-3: Fokussierte, spezifische Anfragen
• 5-10: Wenn breiterer Kontext nötig ist
• 10+: Umfassende Suchen (kann Performance beeinflussen)

{{file_search.output.results}}                  → Alle Ergebnisse
{{file_search.output.results[0].text}}          → Text des relevantesten Chunks
{{file_search.output.results[0].similarity}}    → Relevanz-Score (0–1)
{{file_search.output.results[0].fileName}}      → Dateiname
{{file_search.output.results[0].fileUrl}}       → URL zur Quelldatei
{{file_search.output.results[0].mimeType}}      → Dateiformat (z.B. application/pdf)
{{file_search.output.results[0].fileId}}        → Interne File-ID
{{file_search.output.results[0].externalId}}    → ID im verbundenen Quellsystem
{{file_search.output.results[0].connectionId}}  → ID der Integration-Verbindung
{{file_search.output.results[0].fileSize}}      → Dateigröße in Bytes
{{file_search.output.results[0].pageCount}}     → Anzahl Seiten
{{file_search.output.results[0].subsource}}     → Quellsystem des Treffers (z.B. sharepoint)
{{file_search.output.results[0].subname}}       → Name der konkreten Quelle (z.B. Site oder Laufwerk)
{{file_search.output.results[0].syncParams}}    → Sync-Parameter der Quelle

Erweiterte Metadaten (seit Mai 2026): File-Search-Nodes und Folder-Tools liefern jetzt zusätzlich fileId, externalId, connectionId, fileSize und pageCount, dazu subsource, subname und syncParams. Damit lassen sich Treffer sauber deduplizieren, gegen das Quellsystem zurückverlinken und nach Größe/Seitenzahl filtern, bevor sie an einen Agent gehen. subsource und subname sind der schnellste Weg, in einem gemischten Wissensordner nur die Treffer einer bestimmten Quelle weiterzureichen. seit Juli 2026 lösen SharePoint-Seitenlinks (.aspx) in Search-Files-Ergebnissen jetzt korrekt als Anhänge auf – der eigentliche Seiteninhalt landet also im Workflow statt nur ein toter Link.

Schnellerer Sync bei großen Ordnern seit August 2026: SharePoint, OneDrive und Google Drive nutzen beim Abgleich jetzt eine dedizierte Metadata-Action, um unveränderte Dateien zu erkennen – statt sie erneut zu verarbeiten. Der Ordner-Sync läuft dadurch spürbar schneller und sparsamer. Praktisch heißt das: Ein frisch abgelegtes Dokument steht dem File Search Node früher zur Verfügung, gerade in Ordnern, in denen sich pro Tag nur eine Handvoll Dateien ändert.

Web Search Node – Internet durchsuchen

Durchsucht das Internet und liefert aktuelle Informationen. Perfekt für Fact-Checking, Marktforschung oder sich schnell ändernde Daten.

Modi:

• Automatisch: KI generiert die optimale Suchanfrage
• Manual: Du gibst die exakten Suchbegriffe vor
• Prompt: Anweisungen, aus denen die KI eine Anfrage generiert

Action Node – In verbundene Apps handeln

Führt Aktionen in verbundenen Integrationen aus: Slack-Nachrichten senden, Google Sheets aktualisieren, Jira-Tickets erstellen, E-Mails versenden.

Beispiele nach Integration:

• Slack: Nachricht senden, DM senden, Channel erstellen
• Google Sheets: Zeile hinzufügen, Zeile aktualisieren, Zelle ändern
• Gmail: E-Mail senden, Entwurf erstellen, Label hinzufügen
• Notion: Seite erstellen, Datenbank-Eintrag aktualisieren
• CRM: Kontakt/Deal erstellen, Aktivität loggen

Neue Action-Quellen seit Juli 2026: Pipedrive ist mit 46 Actions dazugekommen – Deals, Personen, Organisationen, Aktivitäten, Leads, Notizen, Pipelines und Stages. Und die Langdock API selbst hat 14 neue Actions bekommen, mit denen ein Workflow Agents, Skills, Knowledge Folder und Integrationen verwalten kann. Damit lassen sich Betriebsaufgaben automatisieren, die bisher Handarbeit im Admin-Bereich waren: einen Knowledge Folder nach einem Quartalswechsel neu befüllen, ein Skill-Update an mehrere Agents ausrollen, verwaiste Integrationen aufräumen.

Automatische Tool-Suche seit Juli 2026: Optional lassen sich Agent Nodes so konfigurieren, dass die KI passende Integration-Actions selbst findet, statt dass du sie vorab einzeln aktivierst. Das ist bewusst ein Opt-in: Es macht explorative Agents deutlich brauchbarer, weicht aber auf, welche Actions ein Workflow überhaupt anfassen kann. Für Produktiv-Workflows mit Schreibzugriff bleibt die explizite Auswahl die sicherere Variante.

MCP-Server als zusätzliche Action-Quelle

Neben den nativen Integrationen kannst du eigene MCP-Server anbinden und deren Tools im Workflow nutzen. Vier Authentifizierungsarten stehen zur Wahl: keine Auth (öffentliche Server), API Key (mit wählbarem Header-Format wie X-API-Key, Bearer oder Basic), OAuth (OAuth 2.0 mit DCR-Support) und Advanced OAuth (OAuth 2.0 ohne DCR).

• Login-Token durchreichen seit Juli 2026: Auf Dedicated Deployments mit aktiviertem User-OAuth-Login kannst du den Platzhalter {{ user_oauth_access_token }} setzen. Der MCP-Server sieht dann den Login-Token des ausführenden Nutzers und kann in dessen Namen arbeiten – die Berechtigungen bleiben also beim Menschen, statt an einem geteilten Service-Account zu hängen.
• Resource-Parameter steuern: Bei Advanced OAuth entscheidet die Option Send resource parameter, ob Langdock die MCP-Server-URL als OAuth-resource-Parameter mitschickt. Aktiviert lassen ist der Normalfall; abschalten musst du sie bei Servern, die die Resource bereits im Scope führen – etwa Entra ID.
• Ressourcen-Zugriff eingegrenzt seit Juli 2026: MCP-Ressourcen werden nur noch über ausdrücklich freigegebene URI-Actions gelesen. Ein Server kann also nicht mehr breiter in seinen Ressourcen stöbern, als du ihm erlaubt hast.
• Bestätigung ist Opt-in: Neu gespeicherte MCP-Tools und -Ressourcen laufen ohne Bestätigungsdialog. Bei allem, was schreibt oder Geld bewegt, aktivierst du die Bestätigung nach dem Speichern pro Tool von Hand.
• Bis zu 60 Tools und 50 Ressourcen seit August 2026: Pro MCP-Integration lassen sich 60 Tools und 50 Ressourcen aktivieren – zuvor lag das Limit bei 50. Die Zahl ist trotzdem kein Ziel: Jedes aktivierte Tool steht in der Auswahl und kann von einem Agent Node gegriffen werden. Je länger die Liste, desto häufiger greift das Modell daneben. Aktiviere, was der Workflow braucht, nicht was der Server hergibt.
• MCP-App-Actions klar beschriftet seit August 2026: Der Integrations-Details-Dialog zeigt bei MCP-App-Actions jetzt den App-Tag und die Resource-URI. Bei mehreren angebundenen Servern mit ähnlich benannten Tools siehst du damit auf einen Blick, welches Tool aus welcher App tatsächlich vor dir liegt – die Verwechslung fällt vor dem Ausrollen auf, nicht danach.
• OAuth-Nachforderung mitten im Betrieb seit August 2026: Server, die auf einer bereits aktiven Verbindung nachträglich eine OAuth-Freigabe verlangen – beobachtet bei Linear, Canva und Notion – durchlaufen die OAuth-Erkennung jetzt sauber, statt mit einem unklaren Fehler stehen zu bleiben.

Risikostufe im Blick seit August 2026: Im Integrations-Verzeichnis stehen öffentliche Integrationen jetzt neben den selbst gebauten – jeweils mit angezeigter Risikostufe. Bevor du eine fremde Integration in einen Produktiv-Workflow hängst, ist das der erste Blick, der sich lohnt.

Große Antworten werden gekürzt – und sagen es jetzt seit Juni 2026: Liefert eine Integration eine sehr große Antwort zurück, kürzt Langdock sie und weist im Output ausdrücklich darauf hin. Das ist mehr als Kosmetik: Wenn ein nachgelagerter Agent Node auf einer gekürzten Liste arbeitet, zieht er seine Schlüsse aus einem Teil der Daten, ohne das zu merken. Siehst du den Hinweis, arbeite mit Filtern oder Pagination in der Action – oder iteriere per Loop Node über Teilmengen, statt alles auf einmal zu holen.

Image Generation Node – Bilder erzeugen

Erzeugt Bilder aus Text-Prompts direkt im Workflow. Ideal für Marketing-Assets, Social Media Content oder dynamische Visualisierungen.

Konfiguration:

• Prompt: Text-Beschreibung des gewünschten Bildes (Manual, Auto oder AI Prompt Mode). Unterstützt Variablen, z.B. Ein {{trigger.output.style}} Bild von {{agent.output.structured.subject}}
• Bildmodell: Zwei Modelle beteiligt – ein LLM optimiert den Prompt, ein Bildmodell generiert das Bild. In Manual Mode wird nur das Bildmodell genutzt. Verfügbar sind u.a. GPT Image 2 (seit April 2026, bis 2K-Auflösung) und Stable Diffusion – die genaue Modell-Liste hängt von der Workspace-Konfiguration ab.
• GPT-Image 2.5 seit 11.09.2026: OpenAIs neue Bildgeneration steht in zwei Varianten bereit. Flare ist das Standardmodell mit Zugewinnen bei Bildqualität, Bearbeitung und Tempo; Sunburst ist die Premium-Stufe für Kontrolle und Präzision. Beide sind EU-gehostet. Workspaces, die schon GPT Image 2 aktiviert hatten, bekommen Flare automatisch; Sunburst schalten Admins in den Workspace-Einstellungen frei. Für Workflows heißt das: Flare ist der neue Default für Batch-Generierung im Loop, Sunburst lohnt nur dort, wo ein einzelnes Bild wirklich sitzen muss.
• Seitenverhältnis: Square (1:1, Social Media/Profilbilder), Landscape (16:9, Präsentationen/Banner), Portrait (9:16, Stories/Mobile)
• Stil-Presets: Auto, Photorealistisch, Digital Art, Ölgemälde, Aquarell, Sketch, Anime, 3D Render, Minimalistisch, Cinematic

Output:

Limits: Timeout 60 Sekunden, nur PNG-Format, keine Bild-zu-Bild-Funktion, URL-Gültigkeit 7 Tage.

Weiterverarbeitung: Agent Node (Bildanalyse), Action Node (in Slack/E-Mail teilen), HTTP Request (Upload auf externen Server), Loop Node (Batch-Generierung mehrerer Bilder).

Loop Node – Über Listen iterieren

Verarbeitet Arrays von Daten: Gehe eine Liste von Kunden, Bestellungen oder Dateien durch und wende auf jedes Element dieselbe Logik an.

Konfiguration:

• Input Array: Das Array, über das iteriert wird (z.B. {{trigger.output.customers}})
• Max Iterations: Sicherheitslimit (Standard: 200, Maximum: 2.000)
• Concurrency: Off (sequenziell, Standard) oder On (parallel – schneller bei unabhängigen Iterationen, Reihenfolge dann nicht garantiert)
• Collect Outputs: Aggregiert alle Iterationen in ein Output-Objekt mit iterations (Array aus Index, Item-Daten und Ausführungsdetails) und total (Anzahl). Nachfolgende Nodes greifen so gebündelt auf alle Ergebnisse zu.
• Wiederaufnahme nach Fehler seit September 2026: Reißt ein sequenzieller Loop mitten in der Liste, muss der Lauf nicht mehr von vorn starten. Du setzt ihn ab der nächsten Iteration fort, die bereits abgeschlossenen Ergebnisse bleiben erhalten. Das ist bei teuren Loops mit Agent Nodes bares Geld: 180 verarbeitete Datensätze werden nicht wegen Nummer 181 ein zweites Mal bezahlt. Bei aktivierter Concurrency greift das nicht, dort ist die Reihenfolge ohnehin nicht garantiert.

{{loop_node.output.currentItem}}        → das aktuelle Datenobjekt
{{loop_node.output.currentItem.name}}   → verschachtelter Zugriff
{{loop_node.output.currentIndex}}       → aktuelle Position (0-basiert)
{{loop_node.output.total}}              → Gesamtanzahl

Delay Node – Pause einlegen

Pausiert die Workflow-Ausführung für eine definierte Dauer (1 Sekunde bis 24 Stunden).

Typische Anwendungen:

• API-Polling (regelmäßig prüfen, ob ein Prozess fertig ist)
• Rate-Limiting (API-Throttling vermeiden)
• Retry-Logik mit Backoff

Send Notification Node – Benachrichtigungen

Sendet Alerts direkt in dein Langdock-Postfach. Unterstützt Markdown-Formatierung und Variablen.

Empfänger: Bei manuell/formular-ausgelösten Workflows der auslösende Benutzer, bei zeitgesteuerten/webhook/integration Workflows der Workflow-Ersteller. Für externe Empfänger den Action Node mit Slack, Gmail etc. verwenden.

Eingabemodi: Manual (direkte Nachricht), Auto (KI generiert basierend auf Kontext) oder Prompt AI (eigene KI-Anweisungen).

Gute Benachrichtigungen enthalten:

• Klare Überschrift mit Priorität
• Relevante Daten (Name, ID, Kategorie)
• Konkreten nächsten Schritt („Bitte innerhalb von 1 Stunde reagieren“)

Output Node – Ergebnisse speichern & anzeigen

Der Output Node ist der Endpunkt eines Workflows. Er speichert einen aufgelösten Wert als Ergebnis des Workflow-Runs – sichtbar in der Run-History, über die API und direkt im Chat.

Besonders wichtig bei Chat-Integration: Wenn ein Workflow aus dem Chat gestartet wird, erscheint der Output als formatiertes Ergebnispanel direkt in der Konversation – mit Workflow-Name, Ausführungszeit und Inhalt.

Konfiguration:

• Value Field: Template-Ausdruck mit Variablen aus vorherigen Nodes (nur Manual Mode)
• Slug: Automatisch generierter camelCase-Identifier – muss bei mehreren Output Nodes eindeutig sein
• Mehrere Outputs: Ein Workflow kann mehrere Output Nodes enthalten, die jeweils separate Schlüssel im Ergebnis-Objekt liefern
• Modellauswahl bei Auto und AI Prompt seit August 2026: Betreibst du den Output Node im Auto- oder AI-Prompt-Mode, formuliert ein Modell den Wert – und dafür gibt es jetzt eine eigene Modellauswahl direkt am Node. Lässt du sie leer, warnt der Builder. Nutze das: Für reines Zusammenfassen reicht ein günstiges Modell, und der Output Node ist einer der Nodes, an denen sich das ohne Qualitätsverlust rechnet.

Erzeugte Dateien landen direkt im Chat seit Juli 2026: Dateien, die ein Workflow unterwegs erzeugt – ein Report aus dem Code Node, ein Bild aus dem Image Generation Node, ein Export aus einer Action – erscheinen jetzt unmittelbar im Chat-Ergebnis, statt nur in der Run-Historie zu liegen. Wer den Workflow per @-Menü aus dem Chat startet, kann das Ergebnis also sofort öffnen und weiterverwenden. Du musst die Datei dafür nicht mehr über einen Umweg – Ablage in Drive, Link im Output Node – sichtbar machen.

// Einzelner Output
{{output_node.output.value}}

// Beispiel: Zusammenfassung als Output
Value: "{{agent.output.structured.summary}}"

// Beispiel: Kombinierte Daten
Value: "Report für {{trigger.output.customer_name}}: {{agent.output.structured.analysis}}"

Das Grundprinzip

Variablen sind das Nervensystem deines Workflows. Wenn ein Node fertig ist, wird sein Output als Variable verfügbar – und alle nachfolgenden Nodes können darauf zugreifen.

Syntax

{{node_name.output.field_name}}

Aufschlüsselung:

• node_name = Der eindeutige Name deines Nodes (z.B. form1, analyze_data)
• output = Das Standard-Output-Objekt jedes Nodes
• field_name = Das spezifische Datenfeld

Verschachtelte Daten

Reale Daten sind selten flach. Nutze Dot-Notation für verschachtelte Zugriffe:

{{node.output.user.profile.email}}           → Verschachteltes Objekt
{{api_response.output.data.items[0].title}}  → Array-Element
{{trigger.output.tags}}                       → Gesamtes Array
{{agent.output.structured.summary}}           → Structured Output

Optional Chaining: Zugriff auf Felder, die fehlen dürfen

Ein Fragezeichen vor dem Punkt greift sicher auf eine Eigenschaft zu, die es möglicherweise gar nicht gibt. Fehlt irgendein Glied der Kette oder ist es null, liefert der ganze Ausdruck undefined, statt den Node mit einem Fehler abzubrechen.

{{trigger.output.user?.email}}                 → Feld darf fehlen
{{agent.output.structured?.priority}}          → Structured Output ohne festes Schema
{{http_request.output.data?.items?.[0]?.name}} → Kette inkl. Array-Zugriff

Autocomplete nutzen

Wo ein Feld es unterstützt, gibt es zusätzlich den Output Selector: Statt den Pfad zu tippen, klickst du dich durch die Outputs der vorherigen Nodes und wählst das Feld aus. Das ist der sichere Weg bei tief verschachtelten Strukturen, in denen ein Tippfehler im Pfad sonst erst zur Laufzeit auffällt.

Variablen mehrfach verwenden

Ein Output kann in beliebig vielen nachfolgenden Nodes verwendet werden:

Trigger (form1) →
  ├─ Agent (analysiere {{form1.output.message}})
  ├─ HTTP Request (logge {{form1.output.email}})
  └─ Notification (benachrichtige über {{form1.output.priority}})

Variablen kombinieren

Mische Daten aus verschiedenen Nodes in einem Feld:

Neue Bestellung #{{trigger.output.order_id}} von {{customer.output.name}} über {{trigger.output.amount}} €

Nodes umbenennen

Wenn du einen Node umbenennst, werden alle Variablen-Referenzen automatisch aktualisiert – kein manuelles Nacharbeiten nötig. Gib Nodes deshalb von Anfang an sprechende Namen:

• ✔ FeedbackAnalysieren, PrioritätPrüfen, SlackBenachrichtigen
• ✘ agent1, condition2, action3

Jedes Konfigurationsfeld in einem Node kann in einem von drei Modi betrieben werden. Die richtige Wahl hat direkten Einfluss auf Qualität, Kosten und Kontrolle.

Auto Mode

Die KI bestimmt automatisch den passenden Wert basierend auf dem Kontext vorheriger Nodes.

Manual Mode

Du gibst exakte Werte ein oder referenzierst Variablen – keine KI-Verarbeitung.

Feld: "E-Mail-Betreff"
Mode: Manual
Wert: "Neue Bestellung #{{trigger.output.order_id}} von {{trigger.output.customer_name}}"
Ergebnis: "Neue Bestellung #12345 von Max Müller"

AI Prompt Mode

Natürlichsprachliche Anweisungen, aus denen die KI dynamischen Content generiert.

Feld: "E-Mail-Text"
Mode: AI Prompt
Anweisung: "Schreibe eine freundliche 2-Absatz-Antwort auf {{trigger.message}},
die auf das Problem {{agent.issue_category}} eingeht und eine Lösung anbietet."

Action-Felder starten jetzt in Manual Mode seit Juli 2026

Bei Action Nodes stehen Felder, die eine KI befüllen könnte, standardmäßig auf Manual. Schaltest du ein solches Feld bewusst auf Auto oder AI Prompt, blendet Langdock eine Sicherheitswarnung ein.

Der Hintergrund ist wichtig zu verstehen: Ein KI-befülltes Feld in einer Action ist eine Angriffsfläche. Wenn der Inhalt einer eingehenden E-Mail, eines Formulars oder einer Slack-Nachricht in den Kontext fließt, kann dieser Text Anweisungen enthalten, die die KI mitliest und befolgt (Prompt Injection). Steht dann das Empfänger-Feld einer „E-Mail senden“-Action auf Auto, entscheidet im Zweifel der Angreifer, wer die Mail bekommt.

None: Feld bewusst leer lassen

Bei Action Nodes gibt es neben den drei Modi einen vierten Zustand: None. Damit überspringst du ein optionales Feld ganz, statt es mit einem leeren String zu belegen. Der Unterschied ist praktisch relevant: Ein leerer String kann im Zielsystem ein vorhandenes Feld überschreiben, während ein übersprungenes Feld die Action gar nicht erst erreicht und der Zielwert unverändert bleibt.

Entscheidungsbaum: Welcher Mode?

Brauchst du das (optionale) Feld überhaupt?
└─ Nein → None (Feld überspringen)

Ist der Wert immer gleich?
└─ Ja → Manual Mode (statischer Text)

Kommt der Wert unverändert aus einem vorherigen Node?
└─ Ja → Manual Mode (mit Variablen)

Muss KI den Content generieren oder transformieren?
├─ Ja → AI Prompt Mode
└─ Nein → Auto Mode (nur wenn einfaches Mapping)

Der Guardrails Node validiert Inhalte mit KI-gestützten Prüfungen – bevor sie an Kunden gehen, gespeichert oder veröffentlicht werden.

Verfügbare Guardrails

PII-Erkennung (Personenbezogene Daten)

Erkennt Namen, E-Mail-Adressen, Telefonnummern, Adressen, Kreditkartennummern etc.

• Empfohlener Schwellenwert: 0,7–0,8
• Einsatz: DSGVO-Compliance, bevor Daten extern geteilt werden

Moderation

Prüft auf unangemessene, schädliche oder beleidigende Inhalte.

• Empfohlener Schwellenwert: 0,6
• Einsatz: Nutzer-generierte Inhalte, öffentliche Kommunikation

Jailbreak-Erkennung

Erkennt Versuche, KI-Sicherheitskontrollen zu umgehen.

• Empfohlener Schwellenwert: 0,7
• Einsatz: Öffentlich zugängliche KI-Interfaces, User-Prompts validieren

Halluzinations-Erkennung

Erkennt, wenn KI-generierte Inhalte falsche oder nicht verifizierbare Informationen enthalten.

• Empfohlener Schwellenwert: 0,6–0,7
• Einsatz: Faktenbasierte Content-Generierung, Kundenkommunikation

Custom Evaluation

Definiere eigene Validierungskriterien in natürlicher Sprache.

• Einsatz: Brand Voice prüfen, domänenspezifische Regeln, eigene Qualitätsstandards

Kriterien: "Prüfe, ob die Antwort unserer Brand Voice entspricht:
- Professioneller aber freundlicher Ton
- Keine Fachbegriffe oder Abkürzungen
- Kunde wird beim Namen angesprochen
- Klare nächste Schritte werden genannt"

Schwellenwerte richtig setzen

Mehrere Guardrails kombinieren

In der Praxis werden häufig mehrere Guardrails in einem Node aktiviert. Eine typische Kombination: PII-Erkennung + Moderation + Custom Evaluation für Brand Voice.

Verbindungen: Mit wessen Rechten ein Workflow handelt

Guardrails prüfen den Inhalt. Die zweite, oft übersehene Sicherheitsfrage lautet: Wessen Zugriffsrechte nutzt ein Action Node eigentlich? Eine Verbindung ist eine gespeicherte Authentifizierung zwischen Langdock und einem externen Tool – und sie gehört immer der Person, die sie angelegt hat. Jede Action läuft mit deren Rechten, nicht mit denen des Nutzers, der den Workflow auslöst.

Das ist der Grund, warum ein Workflow beim Kollegen ins Leere läuft, obwohl er bei dir funktioniert: Er sieht schlicht ein anderes Postfach, ein anderes Drive, ein anderes CRM.

Was geteilt werden kann – und was nicht

• OAuth-Verbindungen (Google, Microsoft 365, Slack, HubSpot) lassen sich nicht direkt teilen. Ein OAuth-Token bildet die Zustimmung einer konkreten Person ab; ein Weiterreichen würde die Nachvollziehbarkeit zerstören und gegen die Bedingungen der Anbieter verstoßen.
• API-Key-, Service-Account- und Verbindungen ohne Auth lassen sich dagegen an einzelne Nutzer, Gruppen, Workspace-API-Keys oder den ganzen Workspace freigeben (Admin-Weg: Integrations → Aktionsmenü der Verbindung → Share connection).
• Der Weg für alle Auth-Arten: die vorausgewählte Verbindung. Beim Konfigurieren einer Action legst du fest, dass alle Nutzer dieselbe, fest hinterlegte Verbindung verwenden. Die Kollegen führen die Action dann aus, ohne die Zugangsdaten je zu sehen – das saubere Muster für geteilte Kalender, ein zentrales CRM-Konto oder einen Team-Slack-Bot.

Welche Verbindung greift?

Hat jemand mehrere Verbindungen zum selben Dienst, wählt Langdock in dieser Reihenfolge: 1. die an der Action vorausgewählte Verbindung, 2. die als Standard markierte Verbindung des Nutzers für diese Integration, 3. Nachfrage. In einem unbeaufsichtigt laufenden Workflow ist Punkt 3 keine Option – setze dort immer eine vorausgewählte Verbindung.

Reautorisierung

Langdock fordert eine Neuanmeldung an, wenn eine OAuth-Verbindung abläuft, widerrufen wurde, benötigte Scopes fehlen oder ein Admin den zugehörigen OAuth-Client entfernt hat. Von Hand geht das über Integrations → Integration wählen → Aktionsmenü der Verbindung → Reauthorize. Bei geplanten Workflows ist das die häufigste Ursache für stille Ausfälle: Der Zeitplan feuert, die Verbindung ist tot, niemand sitzt davor.

Eigene OAuth-Clients seit August 2026

Admins können jetzt mehrere eigene OAuth-Clients pro Integration hinterlegen: einen workspace-weiten Standard plus abweichende Clients für einzelne Gruppen. Passt ein Gruppen-Client, hat er Vorrang vor der Workspace-Einstellung; eine einmal aufgebaute Verbindung bleibt an ihrem ursprünglichen Client hängen, auch wenn sich die Gruppenzugehörigkeit später ändert. Wer einen eigenen Client betreibt, kann darüber auch Scopes auf Anwendungsebene anfordern – die wirken unabhängig von den Rechten des einzelnen Nutzers und gehören deshalb nur dorthin, wo sie wirklich gebraucht werden.

Security Controls: zwei Node-Typen, die ein Admin abschalten kann

Unter Settings → Workflows gibt es zwei workspace-weite Schalter, die nicht einzelne Felder regeln, sondern ganze Node-Typen. Beide sind standardmäßig an:

Aktions-Scopes: warum eine freigeschaltete Action trotzdem scheitert

Jede Integration-Action hängt an einem oder mehreren OAuth-Scopes des Anbieters – eine Outlook-Kalender-Action braucht etwa Calendars.ReadWrite. Admins steuern das unter Integrations-Einstellungen → Integration → Scopes and Action Access, wahlweise in der Scope view (welche Scope-Gruppen angefragt werden) oder der Action view (Action für Action, mit den jeweils nötigen Scopes).

• Langdock-Client (Standard): Die angefragten Scopes bleiben automatisch im Gleichlauf mit den aktivierten und geteilten Actions. Schaltest du eine Action mit fehlendem Scope ein, wird der Scope nach einer Bestätigung mit aufgenommen; wird sie abgeschaltet, fällt der Scope weg, sofern ihn keine andere Action mehr braucht.
• Eigener OAuth-Client mit Sync scopes with enabled actions: verhält sich wie der Langdock-Client.
• Eigener OAuth-Client mit festen Scopes: Die Liste pflegst du selbst. Eine Action mit dem Badge Missing scope lässt sich zwar einschalten, läuft aber nicht, solange der Scope nicht im Client hinterlegt ist. Im UI sieht sie aktiv aus und scheitert trotzdem im Workflow – ein Fehlerbild, das ohne diesen Hintergrund kaum zu deuten ist.
• New actions enabled by default: Steht der Schalter auf On, werden neu hinzugekommene Actions automatisch aktiv, sofern ihre Scopes bereits angefragt sind. Auf Off bleiben sie deaktiviert, bis jemand sie bewusst freigibt. Ein neuer Scope erweitert nie stillschweigend, was Langdock beim Anbieter anfragt.
• Actions nach Wirkung gruppiert seit September 2026: Die Action-Liste einer Integration ist jetzt nach Typ sortiert: View (liest nur), Change (schreibt oder ändert) und Delete (löscht). Beim Freischalten siehst du damit auf einen Blick, was du gerade erlaubst, ohne jede Action einzeln zu lesen. Für die Freigabe-Diskussion mit IT und Betriebsrat ist das die nützlichste Sortierung, die es gibt: View ist meist unstrittig, die Debatte dreht sich um Change und Delete.

Abgelaufene Verbindungen melden sich jetzt selbst seit September 2026: Bisher fiel eine abgelaufene oder entzogene Verbindung erst auf, wenn jemand die Ergebnisse vermisste. Jetzt benachrichtigt Langdock die Editoren eines Workflows, wenn ein abgeschlossener Lauf auf eine nicht verfügbare oder abgelaufene Verbindung gestoßen ist. Der Lauf gilt formal als beendet, das Ergebnis ist aber unvollständig, und genau diese Kombination blieb vorher unsichtbar.

Für sensible Aktionen kannst du einen manuellen Genehmigungsschritt einbauen. Der Workflow pausiert und wartet auf die Freigabe durch Benutzer mit Editor-Zugriff.

Ablauf

1. Workflow erreicht den Approval-Schritt
2. Benutzer mit Editor-Zugriff erhalten eine Benachrichtigung
3. Ein Reviewer prüft die Details und genehmigt (oder lehnt ab)
4. Workflow läuft weiter

Wann sinnvoll?

• ✔ Finanzielle Transaktionen über einem Schwellenwert
• ✔ Irreversible Aktionen (Datenlöschung, Vertragsversand)
• ✔ Kundenkommunikation, die Qualitätsprüfung braucht
• ✔ Produktionsänderungen mit Risikopotenzial

Wann NICHT sinnvoll?

• ✘ Routine-Aktionen mit niedrigem Risiko
• ✘ Schritte, die sofort ausgeführt werden müssen
• ✘ Hochfrequente Aktionen (werden sonst zum Bottleneck)

Bestätigungsdialoge bei Write-Actions

Neben dem expliziten Approval-Schritt gibt es eine zweite, feingranulare Stufe: Schreibende Actions (E-Mail senden, Google-Docs schreiben, HubSpot-Datensatz anlegen, Jira-Ticket erstellen) fragen vor der Ausführung nach einer Bestätigung und zeigen dabei, was genau geschrieben wird.

• Optionale Felder im Dialog seit Juli 2026: Im Bestätigungsdialog kannst du optionale Felder jetzt direkt ergänzen oder entfernen, statt abzubrechen und den Node neu zu konfigurieren. Wer freigibt, kann den Datensatz also im selben Schritt noch nachschärfen.
• Markdown im Dialog seit August 2026: Bestätigungsfelder mit Textinhalt rendern jetzt Markdown-Formatierung, statt die Rohzeichen anzuzeigen. Wer freigibt, liest die Tabelle als Tabelle und die Liste als Liste – und übersieht seltener, was in einem Wust aus Sternchen und Pipes eigentlich drinsteht.
• Werte direkt im JSON-Vorschlag korrigieren seit September 2026: Wartet ein Lauf auf die Freigabe einer Action, kannst du im angezeigten JSON-Vorschlag auf einen Wert klicken und ihn an Ort und Stelle ändern, bevor du bestätigst. Die Action läuft dann mit deiner Korrektur. Der typische Fall: Der Agent hat die richtige E-Mail-Adresse gefunden, aber den Betreff unbrauchbar formuliert. Früher hieß das ablehnen, Node anpassen, Lauf wiederholen; jetzt sind es zwei Klicks.
• Steuerbar per API seit Juli 2026: Die Integrations-API legt das Flag requiresConfirmation offen. Wer eigene Integrationen baut, entscheidet damit pro Action selbst, ob sie einen Bestätigungsdialog auslöst – relevant, wenn ihr eigene Systeme anbindet und dort zwischen harmlosen Lese- und heiklen Schreib-Aktionen trennen wollt.

Faustregel zur Abgrenzung: Der Bestätigungsdialog sichert die einzelne Aktion ab, der Approval-Schritt sichert die Entscheidung dahinter. Bei zeitgesteuerten Workflows, die ohne Publikum laufen, ist der Approval-Schritt das richtige Mittel – auf einen Dialog klickt nachts niemand.

Smart Approval mit Conditions

Kombiniere Conditions mit Human in the Loop, um Genehmigung nur bei Bedarf einzufordern:

Agent: Rechnungsbetrag berechnen

Condition: Betrag > 5.000 €?
├─ Ja → Approval: Zahlung prüfen → Zahlung ausführen
└─ Nein → Zahlung direkt ausführen

So hast du Automatisierung für Routine-Fälle und Kontrolle für Ausnahmen.

Draft Version (v0)

Deine Sandbox zum Experimentieren. Änderungen hier haben keinen Einfluss auf die Produktion. Teste ausgiebig, bevor du veröffentlichst.

Auto-Save & Change Summaries seit April 2026: Drafts werden automatisch gespeichert – kein „Speichern“-Klick mehr nötig. Beim Veröffentlichen schlägt Langdock eine Change Summary vor (welche Nodes/Felder sich seit der letzten Version geändert haben). Die Summary landet im Versionsverlauf und macht Rollback-Entscheidungen später leichter nachvollziehbar. seit Juni 2026 Auch das bloße Umbenennen eines Nodes wird jetzt korrekt als Änderung erkannt – das Deploy-Panel zeigt den Diff sauber an und lässt sich veröffentlichen.

Ungültige Verbindungen werden automatisch bereinigt seit Juli 2026: Vor jedem Speichern, Deployen oder Wiederherstellen räumt Langdock Verbindungen weg, die ins Leere laufen – etwa weil ein Node gelöscht wurde und die Kante zu ihm hängen blieb. Früher konnten solche Kanten ein Deployment blockieren oder eine wiederhergestellte Version in einen kaputten Zustand bringen.

Veröffentlichte Versionen

Wenn du zufrieden bist, erstellst du eine neue Version (v1.0.0, v1.1.0 etc.). Veröffentlichte Versionen sind:

• Unveränderlich: Können nicht mehr bearbeitet werden
• Aktiv für Trigger: Nur aktive Versionen reagieren auf echte Events
• Dokumentiert: Jede Version hat eine Beschreibung der Änderungen
• Rollback-fähig: Du kannst jederzeit eine ältere Version reaktivieren

Versionsnummern (Semantic Versioning)

Workflow-Status

Workflow Monitor: der Betriebsblick

Monitor-Tab für alle seit September 2026: Ein veröffentlichter Workflow braucht eine Stelle, an der jemand sieht, ob er noch tut, was er soll. Diese Stelle ist der Monitor-Tab auf der Workflows-Startseite, und er steht seit September 2026 allen Nutzern offen, nicht mehr nur Admins.

Was der Monitor zeigt

• Health-KPIs und Fehlerquellen: Eine Gesundheitsübersicht oben, dazu Badges für die Fehlerquelle. Interne Plattformfehler sind als Platform issue markiert, damit niemand einen Abend lang im eigenen Workflow nach einem Fehler sucht, der nicht dort liegt.
• Top Failing Nodes: Eine Tabelle der Nodes, an denen am häufigsten etwas reißt. Der schnellste Weg von »irgendwas klemmt« zu einer konkreten Stelle.
• 30-Tage-Erfolgsquote je Workflow: Jede Workflow-Zeile trägt ihre Erfolgsquote der letzten 30 Tage. Ein Workflow, der von 94 % auf 71 % rutscht, fällt damit auf, bevor sich jemand beschwert.
• Filter pro Bereich: Jeder Abschnitt lässt sich nach Workflow und Zeitraum einschränken, auch das Diagramm Runs by day.
• Run-Tags: Läufe lassen sich in der Run-Historie nach Tags filtern. Damit findest du in tausenden Einträgen die, um die es gerade geht.
• Action required: Wartende Freigaben und Agent-Eingaben liegen hier gesammelt und lassen sich direkt annehmen oder ablehnen. Ein Approval-Schritt ist damit nicht mehr auf den Zufall angewiesen, dass jemand die Benachrichtigung sieht.
• Kaputte Verbindungen vor dem Lauf: Der Monitor zeigt ungültige Verbindungen, bevor ein Lauf daran scheitert, und lässt sie an Ort und Stelle neu verbinden. Das abgelaufene OAuth-Token fällt so beim Hinsehen auf, nicht erst am nächsten Morgen in der Fehlermail.
• Erfolgreiche Wiederholungen: Ein fehlgeschlagener Lauf, der später durch eine Wiederholung geheilt wurde, trägt den Hinweis Successful retry mit Link auf den Lauf, der es gerichtet hat. Wiederholungsketten verweisen umgekehrt auf den ursprünglich gescheiterten Lauf.
• CSV-Export der Run-Historie: Die Laufhistorie lässt sich als CSV herausziehen. Für tiefere Auswertungen (Fehlerquote pro Node, Laufzeiten, Muster über Monate) bleibt die Workflow Run Export API das genauere Werkzeug, siehe Kapitel 13.

Benachrichtigungen

Fehlgeschlagene Läufe veröffentlichter Workflows und erreichte Spend-Limits erreichen ausgewählte Empfänger jetzt auch über die Langdock-Inbox, nicht nur per E-Mail. Folgefehler werden dabei gebündelt: höchstens eine Meldung pro Stunde. Ein ruhiger Posteingang ist deshalb kein Beweis dafür, dass wieder alles läuft. Die verlässliche Quelle bleibt der Monitor.

Workspace-Sicht für Admins

Die Workflow-Verwaltung im Workspace ist eine sortierbare Tabelle mit Name, Owner, Status, Anzahl Läufe, Kosten, letztem Lauf und Änderungsdatum. Praktisch für zwei wiederkehrende Fragen: Welcher Workflow frisst das Budget, und welcher läuft seit Wochen niemandem mehr auf, weil sein Owner das Haus verlassen hat.

Wo entstehen Kosten?

• Agent Nodes: Verbrauchen AI Credits basierend auf Modell und Token-Menge
• Auto Mode Fields: Nutzen KI im Hintergrund → AI Credits
• AI Prompt Mode Fields: Nutzen KI für Content-Generierung → AI Credits
• Web Search: Kosten pro Suche
• Loops: Multiplizieren die Kosten pro Element

Kosten-Treiber Nr. 1: Loops mit Agent Nodes

Die häufigste Kostenfalle: Ein Loop über 100 Elemente mit einem Agent-Call pro Element.

Rechnung: 100 Elemente × 0,10 € Agent-Cost = 10 € pro Workflow-Run

Bei täglicher Ausführung: 300 € pro Monat – nur für diesen einen Workflow.

Strategien zur Kostensenkung:

1. Batching: Statt 100 einzelne Agent-Calls → Elemente in Gruppen von 10 zusammenfassen
2. Günstigere Modelle: Nicht jede Aufgabe braucht ein Spitzenmodell wie GPT-5.6 Sol oder Claude Opus 5 (seit Juli 2026 das stärkste Opus-Modell in Langdock) – für einfache Kategorisierung reicht oft Haiku 4.5, GPT-5.6 Luna (die kosteneffiziente Variante der GPT-5.6-Familie, seit Juli 2026 EU-gehostet und in Workspaces mit aktivem GPT-5.5 automatisch verfügbar) oder Gemini 3.7 Flash (seit August 2026 das aktuelle Flash-Modell, optionaler Thinking-Toggle für komplexere Fälle). Für agentische Mehrschritt-Aufgaben ist Claude Sonnet 5 (seit Juni 2026) der Sweet Spot: nahe an der Opus-Klasse, aber spürbar günstiger – Opus 5 nur noch für die schwersten Analysen reservieren
3. Manual statt Auto Mode: Feste Werte und einfache Variablen-Referenzen kosten nichts
4. Conditions vor Agent Nodes: Filtere irrelevante Daten, bevor sie den teuren Agent erreichen

Kosten monitoren

• Prüfe den Usage-Tab nach jedem Test-Run
• Setze Spending Limits in den Workflow-Einstellungen
• Berechne die erwarteten monatlichen Kosten vor dem Go-Live: Kosten pro Run × erwartete Runs pro Tag × 30
• Fehler-E-Mails sind gedrosselt: Bei veröffentlichten Workflows verschickt Langdock höchstens eine Fehler-Mail pro Stunde. Danach kommt die nächste erst wieder, wenn zwischendurch ein Lauf erfolgreich war. Ein stiller Posteingang heißt also nicht, dass wieder alles läuft – bei einem dauerhaft kaputten Workflow bleibt die Run-Historie die verlässliche Quelle.
• CSV-Export der API-Kosten seit April 2026: Admin-Usage lässt sich jetzt als CSV exportieren – ideal für interne Cost-Reports, Verrechnung nach Team/Kostenstelle oder Abgleich mit dem Workspace-Budget.

Limits

Workspace-Admin-Kontrolle (Settings → Workflows):

• Workspace Spend Limit: Organisationsweite Monats-Obergrenze für alle Workflow-AI-Kosten. Standard 500 €, maximal 100.000 €. Admins bekommen In-App-Hinweis und E-Mail bei 50 %, 90 % und 100 %; ist die Obergrenze erreicht, stoppen alle Ausführungen, die ein KI-Modell brauchen. In Trial-Workspaces zählt der Wert kumuliert über die gesamte Laufzeit, sonst pro Kalendermonat
• Default Monthly Limit per Workflow: Standard für neue Workflows (1–10.000 USD, Default 25 USD)
• Maximum Monthly Limit per Workflow: Obergrenze (1–10.000 USD), die individuelle Workflow-Einstellungen nicht überschreiten dürfen. Senkst du sie nachträglich, werden bestehende Workflow-Limits, die darüber liegen, automatisch mit heruntergezogen – ein zuvor großzügig gesetzter Workflow läuft danach also gegen die neue, engere Grenze
• Code Node Toggle: Admins können das Ausführen von Custom JavaScript workspaceweit deaktivieren
• HTTP Node Toggle: Admins können externe API-Calls workspaceweit deaktivieren

Was nicht auf das Workflow-Budget zählt

• Workflow-Läufe zählen nicht in die Chat- und Agenten-Budgets: Die Ausgabenlimits unter Settings → Usage (Workspace, Plan, Gruppe, persönliches Extra-Budget) erfassen Chat- und Agenten-Nutzung sowie persönliche API-Keys. Workflow-Läufe, das Backbone-Modell und Workspace-API-Keys bleiben draußen – Workflows haben ihr eigenes Budget unter Settings → Workflows. Wer nur den Usage-Bereich im Blick hat, sieht die Workflow-Kosten schlicht nicht.
• Der Workflow-Builder-Chat kostet dich persönlich: Nachrichten im Builder-Chat laufen gegen dein persönliches Nutzungslimit (Fair Use), nicht gegen das Spend Limit des Workflows. Herumprobieren im Chat belastet also nicht das Budget, das der produktive Workflow braucht.
• Analyse-Zahlen und Limit-Zähler sind zwei Dinge: Die Kostenwerte in der Workflow-Analyse beziehen sich auf den dort gewählten Zeitraum. Das Spend Limit zählt in Trial-Workspaces kumuliert über die gesamte Laufzeit, sonst pro Kalendermonat – während die in den Einstellungen angezeigten Billing month-Daten dem Abrechnungszyklus folgen können. Die drei Zahlen dürfen auseinanderlaufen, ohne dass etwas kaputt ist.

Die 10 wichtigsten Best Practices

1. Nodes klar benennen. „Feedback analysieren“ statt „Agent 1“. Dein zukünftiges Ich wird es dir danken – und Variablen werden selbsterklärend.
2. Ein Workflow = ein Zweck. Halte Workflows fokussiert. Lieber zwei kleine Workflows als einen Monster-Workflow, der alles macht.
3. Teste jeden Node einzeln. Nutze den Play-Button auf jedem Node, bevor du weiterbaust. Fehler früh finden spart Zeit.
4. Structured Output immer aktivieren. Bei Agent Nodes in Workflows gibt es keinen Grund, darauf zu verzichten. Garantiertes Format verhindert Parsing-Fehler in nachfolgenden Nodes.
5. Manual Mode als Standard. Nutze Auto und AI Prompt Mode nur, wenn nötig. Jeder AI-Mode-Aufruf kostet Credits.
6. Fehlerbehandlung einplanen. Besonders bei Scheduled Workflows: Füge Notifications hinzu, damit du mitbekommst, wenn etwas schiefgeht.
7. Kosten vor Go-Live berechnen. Insbesondere bei Loops und häufigen Triggern kann es schnell teuer werden. Rechne vorher.
8. Filter früh, verarbeite spät. Conditions vor teuren Nodes (Agent, HTTP Request) reduzieren unnötige Kosten.
9. Draft-Version zum Testen. Veröffentliche erst, wenn alles funktioniert. Die Draft-Version (v0) ist dein Spielplatz.
10. Dokumentiere komplexe Logik. Füge Beschreibungen zu Nodes hinzu, besonders bei Code-Nodes und verschachtelter Condition-Logik.

Häufige Stolperfallen

Stolperfalle 1: Auto Mode überall

Auto Mode ist bequem, aber verbraucht bei jedem Run AI Credits. Bei einem Workflow, der 100x am Tag läuft, summiert sich das schnell. Nutze Manual Mode für alles, was statisch ist oder direkt aus Variablen kommt.

Stolperfalle 2: Loop ohne Limit

Ein Loop ohne Max-Iterations-Limit über ein unbekannt großes Array kann zu Kostenexplosion und Timeouts führen. Setze immer ein realistisches Limit.

Stolperfalle 3: Keine Error-Pfade

Wenn ein HTTP Request fehlschlägt und du keinen Error-Pfad definiert hast, stoppt der gesamte Workflow ohne Benachrichtigung. Du merkst es erst, wenn jemand fragt, warum nichts passiert ist.

Stolperfalle 4: Webhook ohne Secret

Ein öffentlich zugänglicher Webhook kann von jedem aufgerufen werden – auch von Bots. In Produktion immer den X-Webhook-Secret-Header nutzen, nicht Query-Parameter (Tokens in URLs landen in Logs und Browser-History).

Stolperfalle 5: Agent-Instruktionen zu vage

„Analysiere diesen Text“ liefert unvorhersagbare Ergebnisse. Sei spezifisch: Was genau soll analysiert werden? Welche Kategorien gibt es? Wie soll das Ergebnis aussehen?

Stolperfalle 6: Scheduled Workflows ohne Monitoring

Ein Workflow, der jeden Morgen um 6:00 Uhr läuft, kann wochenlang fehlschlagen, ohne dass es jemand merkt. Füge immer eine Failure-Notification hinzu.

Stolperfalle 7: Zu große Inputs für Agents

Agents arbeiten am besten mit fokussierten Inputs. Schicke nicht ein 50-seitiges Dokument komplett durch, sondern extrahiere vorher die relevanten Abschnitte (z.B. mit File Search oder Code Node).

Variable nicht verfügbar

Problem: Die gewünschte Variable erscheint nicht im Autocomplete.

Ursache: Der Node ist nicht verbunden, kommt nach dem aktuellen Node, oder wurde noch nicht getestet.

Lösung: Stelle sicher, dass der Node, der die Variable produziert, vor dem nutzenden Node im Workflow-Graphen kommt. Führe einen Test-Run durch.

Variable ist undefined oder null

Problem: Variable existiert, liefert aber undefined oder null.

Ursache: Der Quell-Node hat fehlgeschlagen, das Feld gibt es nicht, oder optionale Daten wurden nicht bereitgestellt.

Lösung im Code Node:

const email = trigger.output.email || "unbekannt@example.com";
const amount = trigger.output.amount || 0;

Agent liefert unerwartete Ergebnisse

Problem: Structured Output hat unerwartete Werte.

Lösung: Prüfe den Output-Tab des Agent Nodes nach dem Test-Run. Schärfe die Instruktionen, füge Beispiele hinzu, und beschränke die möglichen Werte explizit.

Workflow läuft nicht nach Zeitplan

Checkliste:

• Ist der Workflow deployed (nicht Draft)?
• Ist der Workflow aktiv (nicht pausiert)?
• Stimmt die Zeitzone?
• Stimmt der Cron-Ausdruck?

Integration-Trigger oder -Action reagiert nicht mehr

Problem: Ein Integration Trigger feuert nicht mehr oder eine Integration Action schlägt mit Auth-Fehler fehl.

Ursache: Das Zugriffs-Token der verbundenen App ist abgelaufen oder wurde widerrufen.

Lösung (Juni 2026): Du kannst bestehende Integrationen jetzt direkt in den Verbindungs-Einstellungen neu authentifizieren – ohne die Verbindung zu entfernen und neu anzulegen. Die Node-Konfiguration im Workflow bleibt dabei erhalten.

Workflow taucht im Chat nicht auf oder lässt sich nicht starten

Problem: Der Workflow erscheint nicht im @-Menü, oder ein Agent meldet mitten in der Konversation Access Denied.

Ursachen der Reihe nach prüfen:

• Trigger-Typ: Nur Manual-, Form- und Scheduled-Trigger sind aus dem Chat ansprechbar. Webhook- und Integration-Trigger erscheinen dort gar nicht erst.
• Veröffentlichung: Ein Workflow, der nur als Draft (v0) existiert, ist im Chat nicht aufrufbar.
• Zugriff: Beim @-Menü brauchst du selbst Zugriff auf den Workflow. Hängt er als Action an einem geteilten Agenten, wird der Zugriff erst zur Ausführung geprüft – daher die Fehlermeldung mitten im Gespräch. Lösung: den Workflow für die Nutzer des Agenten freigeben.
• Plattform: In den Mobile-Apps lassen sich Workflows nicht starten.

HTTP Request schlägt fehl

Checkliste:

• Stimmt die URL? (inkl. https://)
• Stimmt die HTTP-Methode?
• Sind Authentication-Headers korrekt?
• Ist das Body-Format valides JSON?
• Tipp: Nutze „Import from cURL“ aus der API-Dokumentation

KI-Analyse bei Fehlern seit Juli 2026: Schlägt ein HTTP Request Node fehl, kannst du die Untersuchung direkt an den Workflow-Chat übergeben. Der Assistent bekommt Request, Response und Statuscode und schlägt eine konkrete Korrektur vor – das erspart das Durchsuchen roher Fehler-Payloads.

Fehlermeldungen lesen

Dateinamen statt IDs seit Juli 2026: Fehlermeldungen rund um Dateien nennen jetzt den Dateinamen statt einer internen ID. Wenn ein Workflow mit mehreren Anhängen scheitert, siehst du sofort, welche Datei das Problem auslöst, statt IDs gegen die Run-Historie abgleichen zu müssen.

Mehrere fehlgeschlagene Läufe auf einmal neu starten

Wenn eine einzige Ursache reihenweise Läufe gerissen hat – abgelaufenes Token, kurzzeitig nicht erreichbare API – musst du nicht jeden Lauf einzeln anfassen. Über Past runs am unteren Rand der Canvas setzt du den Status auf Failed, wählst bis zu 20 Läufe aus und startest sie mit Re-run gesammelt neu.

In beiden Fällen gilt: Unveröffentlichte Änderungen auf der Canvas werden nicht verwendet. Wer den Fehler gerade erst im Draft repariert hat, muss also erst deployen und dann neu starten – sonst läuft die Wiederholung in genau denselben Fehler.

Jede Wiederholung ist rückverfolgbar seit September 2026: In der Run-Historie trägt ein neu gestarteter Lauf den klickbaren Verweis Re-run of Run #N. Damit findest du zu jeder Wiederholung den ursprünglichen Lauf mit seinen Trigger-Daten, statt in einer Liste gleich aussehender Einträge zu raten, welcher das Original war.

Sporadische Fehler finden: Run-Historie exportieren seit August 2026

Problem: Ein Workflow scheitert nicht immer, sondern manchmal. Im Editor lässt sich das nicht rekonstruieren, weil die Ursache zwischen hunderten Läufen liegt.

Lösung: Die Workflow Run Export API gibt Läufe und einzelne Node-Ausführungen als JSON heraus – eine Zeile pro Node-Ausführung, mit Run-Status, Trigger-Modus, Workflow-Version, Node-Typ, Fehlercode sowie Input, Output und Logs. Damit zählst du Fehlerquoten pro Node, vergleichst Laufzeiten und findest Muster, die im einzelnen Run unsichtbar bleiben.

curl "https://api.langdock.com/workflows/<workflowId>/runs?from=2026-08-01&to=2026-08-31" \
  -H "Authorization: Bearer <WORKSPACE_API_KEY>"

• Schlüssel: Workspace-API-Key mit dem Scope WORKFLOW_API (Workspace-Einstellungen → Products → API). Persönliche API-Keys decken nur die Completion-APIs ab und funktionieren hier nicht.
• Zugriff: Der Key muss Owner oder Editor des Workflows sein; Workspace-Admins kommen auch ohne Freigabe heran. Die Rolle User reicht nicht – auch nicht für Admins.
• Zeitraum: from und to sind Pflicht (ISO 8601). Reine Datumsangaben laufen von 00:00:00.000 bis 23:59:59.999 UTC; ein Timestamp ohne Zeitzone wird in der Server-Zeitzone gelesen – also Z oder Offset mitgeben.
• Grenzen: maximal 10.000 Läufe und 8.000.000 Bytes Payload pro Anfrage, sonst 400 mit WORKFLOW_RUN_EXPORT_LIMIT_EXCEEDED bzw. WORKFLOW_RUN_EXPORT_TOO_LARGE. Es gibt keine Pagination – die Lösung ist immer ein kleinerer Zeitraum. Rate-Limit: 500 Anfragen pro Minute je Workspace und Key.
• Aufbewahrung: input und output sind nach 30 Tagen null. Wer länger auswerten will, exportiert regelmäßig statt rückwirkend. Einzelwerte über 16.000 Bytes kommen gekürzt, erkennbar am _truncated-Objekt.
• Leere Payloads: Steht data_redacted auf true, fehlt dir der Zugriff auf einen beteiligten Node – oft ein Action- oder Agent-Node. Dann ist nicht der Lauf kaputt, sondern die Freigabe.

Auf Dedicated Deployments tritt https://<deine-domain>/api/public an die Stelle von api.langdock.com. Requests aus dem Browser blockt Langdock bewusst – der Export gehört in ein Backend oder ein Skript, nicht in eine Web-App.