Ein Chatfenster beantwortet eine Frage. Ein echter Prozess braucht mehr: Jeden Morgen kommen zwanzig Mails rein, jede verlangt eine andere Behandlung, und drei davon dürfen nicht ohne Freigabe hinaus. Oder jede Woche entsteht aus dem Brain eine aktuelle Entwickler-Dokumentation als Word-Datei, die der Lead vor der Veröffentlichung prüft. Solche Abläufe brauchen feste Schrittfolgen, Wiederholungen, Systemzugriffe und Stellen, an denen ein Mensch entscheidet. Dafür hat veilSense den Workflow Assistant gebaut. Er verkettet Schritte zu einem gerichteten, azyklischen Graphen (DAG), der auf einem Canvas entsteht.

Zwei Arten, Arbeit zu organisieren

veilSense trennt zwei Bausteine, die unterschiedlich arbeiten:

• Workflows führen feste Prozessschritte deterministisch aus. Dieselbe Eingabe erzeugt denselben Ablauf in derselben Reihenfolge. Die meisten Schritte brauchen kein Modell: Bedingungen, Schleifen, Berechnungen, Brain-Zugriffe, HTTP-Aufrufe oder E-Mail. KI kommt nur dort zum Einsatz, wo ein Schritt Urteilsvermögen verlangt.
• Das Virtual Team arbeitet Aufgaben mit Ermessen ab. Ein Lead zerlegt eine Aufgabe, Agenten bearbeiten die Teilschritte und schreiben ihren Abschnitt in ein Arbeitsdokument, und am Ende prüft ein Mensch das Ergebnis.

Die Faustregel lautet: Steht der Ablauf fest, ist ein Workflow die richtige Wahl. Ist Abwägung nötig, arbeitet ein Agent im Team.

Der eigentliche Gewinn liegt in der Integration

Ein einzelner Schritt ist selten das Interessante. Spannend wird es, wenn Workflows die Bausteine von veilSense verbinden:

• Brain: Einträge lesen, auflisten, anlegen, ergänzen, verschieben und löschen. Ergebnisse fließen zurück ins Wissen.
• Team: Der Schritt Create Task legt Aufgaben auf dem Board an. Agenten übernehmen die Abarbeitung, und das Review-Gate hält den Menschen informiert und final verantwortlich.
• Dokumente: Über den Schritt Assistant Call läuft der Word-Generator. Ein File-Download-Schritt macht Text zu .docx oder PDF.
• Kanäle: Check Email und Check Calendar lösen Abläufe aus, Email Send und Calendar Event führen Ergebnisse nach außen.
• Systeme: HTTP Call holt Daten aus externen APIs oder schreibt sie dorthin. MCP-Werkzeuge werden über einen Tool-Assistant angebunden, der als Assistant Call im Workflow steht.
• Entwicklung: Ein Agent, der in der IDE läuft, arbeitet über MCP Aufgaben vom Board ab.

Die Brain-Einträge sind Eingang und Ausgang zugleich. Was ein Workflow erzeugt, liest der nächste Workflow wieder als Wissen. So entsteht ein Kreislauf statt einer Kette von Einzelwerkzeugen.

Die Bausteine im Überblick

Die Schritte lassen sich nach ihrem Zweck gruppieren. Die wichtigste Spalte ist der Modellbedarf:

Gruppe	Schritte	Modellbedarf
Start und Ende	START (manuell, Cron oder Prompt, dazu Start-Aktion), END (mit Brain-Eintrag oder Datei-Download)	Keiner
Logik	Condition, Decision Table, Calculate, Script (JavaScript, sandboxed)	Keiner
Listen	Loop, Aggregate, Table Analyze	Keiner
Brain	List Brain Entries, Read Brain Entry, Update Brain, Rename/Move, Delete Brain Entry	Keiner
Verbindungen	HTTP Call, Email Send, Create Task, Calendar Event, Find Slot	Keiner
Dokumente	File Download	Keiner
KI	Assistant Call (Tool-Assistant für MCP, Image Generator, Workflows), Prompt Call, Classify	Modell frei wählbar
Mensch	Human in the Loop	Keiner, aber eine Person ist nötig für die Folgenabschätzung
Struktur	Subflow	Keiner

Der größte Teil eines Workflows arbeitet also deterministisch. Das Modell ist ein Spezialwerkzeug, und bei den KI-Schritten entscheidet die Modellwahl über Kosten und Qualität.

Ein Canvas statt einer langen Prompt-Kette

Die Schritte werden auf dem Canvas verbunden. Ein Schritt läuft, sobald alle Schritte, die in ihn hineinführen, abgeschlossen sind. Bedingungen haben zwei Ausgänge, True und False, und die gewählte Verbindung bestimmt den Weg. Änderungen gehen erst mit Save auf den Server.

Ein Workflow lohnt sich, sobald eine Aufgabe mehr als einen Prompt braucht und Ergebnisse in gleichen Schritten ablaufen sollen.

Bsp: Ein einzelner Prompt sortiert nicht zuverlässig vier Mails einzeln, behandelt jede je nach Kategorie anders und legt zwei davon zur Freigabe vor. Ein Workflow leistet das.

Start: manuell, zeitgesteuert, aus einem Prompt heraus oder durch ein Ereignis

Der START-Schritt bestimmt, wie ein Lauf beginnt:

• Manuell: per Knopfdruck oder per API.
• Zeitgesteuert: per Cron-Ausdruck, etwa montags um 7 Uhr.
• Aus einem Prompt heraus: Ein gespeicherter Prompt startet den gebundenen Workflow. Dieser Weg wird im nächsten Abschnitt beschrieben.

Zusätzlich kann der START eine Start-Aktion ausführen, bevor der Ablauf beginnt:

• Load from Brain: Lädt einen Eintrag per Titel, ohne Modell.
• Check Email: Prüft ein Postfach und liefert neue Nachrichten als Liste, mit Absender, Betreff, Text und Empfangszeit. Eine Nachricht wird nur einmal verarbeitet.
• Check Calendar: Liefert Termine, die gerade beginnen (Upcoming) oder gerade geendet haben (Ended). Ein Zeitfenster und ein Titelfilter, etwa „Meeting:“, begrenzen die Auswahl. Ein geplanter Lauf merkt sich, welche Termine er bereits behandelt hat.

Aus einem Prompt heraus: Eingaben im Chat

Viele Workflows brauchen Eingaben, die sich nicht aus einem Zeitplan oder einem Postfach ergeben. Ein Workflow zum Anlegen eines Transportauftrags braucht etwa einen SAP-Paketnamen, ein Zielsystem und eine Beschreibung. Dafür gibt es die Bindung zwischen Prompt und Workflow.

Der Prompt fragt die benötigten Werte im Chat ab, und der Nutzer gibt sie ein. Der gebundene Workflow startet danach mit genau diesen Werten als Eingangsvariablen. Die Werte müssen also nicht über Test Data oder eine Start-Aktion beschafft werden. Das Prompt-Fenster übernimmt die Eingabe, der Workflow übernimmt die Ausführung.

Der Weg ist vor allem dann richtig, wenn ein Workflow mehrere Eingabevariablen braucht, die ein Mensch bei jedem Lauf neu festlegt.

Classify: typisiert entscheiden statt frei formulieren

Hier kommt ein Decision Modell gezielt zum Einsatz. Classify lässt das Entscheidungsmodell des Workspace genau ein Label aus einer festen Liste wählen, etwa BESCHWERDE, FRAGE oder BESTELLUNG. Jedes Label braucht eine Beschreibung, denn sie ist die einzige Anleitung für das Modell.

Zwei Sicherungen greifen. Ein Mindest-Vertrauenswert (Standard 0,6) legt fest, ab wann die Antwort gilt. Darunter greift das Fallback-Label, etwa PRÜFEN. Ohne Fallback schlägt der Schritt im Fehlerfall fehl, statt zu raten. Classify verzweigt selbst nicht, danach folgt eine Condition.

Das Modell ist ein schneller Klassifikator, kein Orakel. Die Dokumentation nennt öffentliche Benchmarks im Bereich von 70 Prozent. Unsichere Ergebnisse gehen deshalb an einen Menschen.

Logik: Bedingungen, Tabellen, Berechnung

Ein Condition-Schritt prüft eine oder mehrere Regeln, die mit UND verknüpft sind. Die Operatoren sind =, ≠, >, ≥, <, ≤, contains, starts with, is empty und is not empty. Leere Listen gelten dabei korrekt als leer.

Bei mehr als zwei Fällen ist eine Decision Table übersichtlicher. Sie besteht aus priorisierten Zeilen, und standardmäßig gewinnt die erste passende Zeile. Das eignet sich für Staffeln, etwa Versandkosten, aber auch für komplexere Regeln im Bereich Tarifierung bei Versicherungen.

Calculate rechnet und formt Text. Script führt eigenen JavaScript-Code aus, wenn die Logik für Zuweisungen zu verschachtelt ist. Der Code läuft isoliert, ohne Zugriff auf Dateien, Netzwerk oder Prozesse, und hat ein Zeitlimit von zehn Sekunden. Workspace Administratoren sind verantwortlich, Skripte performant zu entwerfen und vorab zu testen, bevor sie im Workspace für die Benutzer mit CREATOR Rolle verwendet werden sollten.

Listen: Schleifen, Aggregation, Brain-Einträge

Ein Loop führt für jeden Eintrag einer Liste einen eigenen Unterprozess aus. Der aktuelle Eintrag steht dort unter einem frei gewählten Namen, etwa mail. Die Ergebnisse jeder Runde werden in Eingabereihenfolge gesammelt. Schleifen dürfen verschachtelt werden, und bis zu 16 Blöcke können parallel laufen, ohne dass die Reihenfolge verloren geht. Das erhöht die Durchlaufzeit deutlich.

Ein Aggregate-Schritt verdichtet die gesammelte Liste zu MAX, MIN, SUM, AVG oder COUNT, optional gruppiert. Table Analyze rechnet Tabellen ohne Modell aus, etwa einen Monatsreport aus Daten, die ein HTTP Call geholt hat.

Für Brain-Ordner gibt es List Brain Entries, das die Einträge eines Ordners als Liste liefert, und Read Brain Entry, das den Volltext eines Eintrags liefert. Zusammen mit einem Loop wird so jeder Eintrag eines Ordners der Reihe nach verarbeitet.

Subflow: große Abläufe übersichtlich halten

Ein Subflow fasst eine zusammenhängende Gruppe von Schritten zu einem einklappbaren Block auf dem Hauptcanvas zusammen. Er läuft genau einmal und hat keine eigenen Variablen. Er arbeitet direkt im Kontext des Hauptworkflows, sodass seine Ergebnisse sofort für den Rest des Ablaufs verfügbar sind.

Der Subflow wiederholt sich nicht, er ordnet nur. Für Wiederholungen über eine Liste ist der Loop zuständig.

Eine Grenze gilt: Ein Human-in-the-Loop-Schritt im Subflow bricht den Lauf mit einer Fehlermeldung ab, statt zu pausieren. Freigaben gehören deshalb in den Hauptablauf oder in einen Loop.

Assistant Call: Assistenten, Tools, Prompts und Workflows

Der Schritt Assistant Call ruft einen Assistenten des Workspace auf. Drei Ziele sind besonders wichtig:

• Tool-Assistant für MCP: MCP-Werkzeuge werden im Workflow immer über einen Tool-Assistant angebunden, der als Assistant Call im Workflow steht.
• Image Generator: Erzeugt ein Bild, das ein späterer Schritt in einen Brain-Eintrag oder eine E-Mail übernehmen kann.
• Anderer Workflow: Der aufgerufene Workflow bekommt einen eigenen Eintrag in der Ausführungshistorie.

Der Schritt Prompt Call ruft einen gespeicherten Prompt auf.

Eine Grenze gilt auch hier: Erreicht der aufgerufene Workflow einen Freigabeschritt, bricht der Aufruf mit einer Fehlermeldung ab. Ein Workflow mit Freigabe wird deshalb direkt gestartet, nicht aus einem anderen Ablauf heraus.

Das richtige Modell für jeden Schritt

Jeder KI-Schritt bekommt seine eigene Modellkonfiguration. Assistant Call, Prompt Call und Classify können jeweils ein anderes Modell verwenden als der Rest des Workflows, und das spart Kosten.

Die Wahl folgt der Aufgabe. Ein kleineres Modell ist schneller und deutlich günstiger. Es erledigt klar umrissene Aufgaben mit festem Format zuverlässig, etwa einen Text zusammenfassen, Felder extrahieren oder ein Label aus einer Liste wählen. Ein leistungsstärkeres Modell lohnt sich dort, wo Nuancen zählen: bei einem Antwortentwurf an einen verärgerten Kunden oder bei einer Analyse mit vielen Abhängigkeiten.

Der Effekt wird bei Schleifen besonders deutlich. Ein Loop über zwanzig Mails führt die KI-Schritte im Körper zwanzigmal aus. Ein unnötig großes Modell im Körper multipliziert die Kosten also zwanzigfach, während ein kleineres Modell für Classify die Kosten des gesamten Laufs senkt.

Zwei Regeln gelten unabhängig von der Modellwahl. Einträge mit der Klasse AI-Excluded gehen an kein Modell. Confidential-Einträge gehen nur an das lokale Modell. Die Modellwahl darf diese Grenzen nicht aufweichen.

Human in the Loop: der Mensch entscheidet

Ein HITL-Schritt hält den Lauf an und wartet auf eine Person. Der Status lautet dann „awaiting review“, eine Benachrichtigung erscheint, und die Prüfung landet auf dem Dashboard.

Der Admin legt fest, welche Variablen die Person sieht. Jede Variable ist entweder bearbeitbar oder nur lesbar. Lesbare Werte lassen sich nicht überschreiben, die Änderung wird serverseitig verworfen. Die Person hat drei Optionen:

• Approve & Continue: Der Lauf geht weiter, optional mit geänderten Werten.
• Reject: Der Lauf springt zu einem frei gewählten früheren Schritt zurück und führt ab dort neu aus, inklusive Seiteneffekten. Die Begründung steht den neu laufenden Schritten als ${hitlRejectReason} zur Verfügung, damit ein Prompt darauf reagieren kann. Reject steht nur zur Verfügung, wenn ein Rücksprungziel konfiguriert ist.
• Abort: Der Lauf endet dauerhaft.

Im Loop arbeitet HITL pro Runde. Der Lauf hält bei der Mail an, die eine Prüfung braucht, merkt sich den Stand und setzt nach der Freigabe genau dort fort. Die Grenzen im Überblick: HITL funktioniert nicht zusammen mit parallelen Runden, nicht im Subflow und nicht über einen Assistant-Aufruf hinweg.

Ende: Brain-Eintrag oder Datei

Ein Workflow kann mehrere ENDs haben, etwa eines pro Zweig einer Bedingung. Ein END legt einen Brain-Eintrag an oder bietet eine Datei zum Download an, .docx oder PDF, erst auf Klick.

Zwei Richtungen: Workflow und Team greifen ineinander

Richtung A: Task → Agent → Workflow. Eine Aufgabe landet auf dem Board. Der Lead zerlegt sie, und der Scheduler weist eine Teilaufgabe einem Agenten zu, der die Capability „run a workflow“ besitzt. Der Workflow läuft deterministisch ab, am Ende prüft ein Mensch am Review-Gate.

Richtung B: zeitgesteuerter Workflow → Task → Agent. Ein Create-Task-Schritt in einem Workflow legt eine Aufgabe auf dem Board an (bspw. Support Ticket bearbeiten). Optional wird gleich eine Aufgabenvorlage angewendet, sonst bietet der Lead im Team-Chat eine Zerlegung an. Danach läuft der normale Team-Ablauf.

Bei Richtung A entscheidet das Team, welcher Ablauf nötig ist. Bei Richtung B entscheidet der Zeitplan, und das Team übernimmt, was dabei anfällt.

Nachvollziehbarkeit: jeder Lauf ist protokolliert

Jeder Lauf wird in der Ausführungshistorie festgehalten. Pro Schritt sind Kontext vor und nach dem Schritt sichtbar. Wirkt ein Ergebnis merkwürdig, lässt sich genau nachvollziehen, was jeder Schritt bekommen und erzeugt hat.

Zudem lässt sich ein Workflow auch mit synthetischen Daten (von KI generiert) vorab testen (Eingabewerte werden hierbei vorbelegt), bevor ein Workflow final freigegeben wird (Setzen des Workflows Auf AKTIV).

Beispiel 1: Mail-Triage mit Freigabe

1. START mit Start-Aktion Check Email: Neue Nachrichten kommen als Liste.
2. Loop über die Nachrichten: Jede Nachricht durchläuft denselben Körper.
3. Classify (kleineres Modell): BESCHWERDE, FRAGE, BESTELLUNG oder PRÜFEN, Mindest-Vertrauen 0,6, Fallback PRÜFEN.
4. Condition: Bestellungen gehen in einen Brain-Eintrag, alles andere zum Antwortentwurf.
5. Subflow „Kunde identifizieren“: Ruft Kundendaten über einen HTTP Call ab, ohne Modell.
6. Assistant Call (leistungsstärkeres Modell): Schreibt den Antwortentwurf mit Fakten aus dem Brain, weil Tonalität zählt.
7. Human in the Loop: Der Prüfer sieht Absender, Betreff und Entwurf. Der Entwurf ist bearbeitbar, der Absender nicht. Reject mit Begründung läuft den Assistenten mit dieser Begründung neu. Der HITL-Schritt liegt im Loop, nicht im Subflow.
8. Email Send: Erst nach der Freigabe geht die Antwort hinaus.

Ein Aggregate-Schritt zählt am Ende die Beschwerden des Tages.

Beispiel 2: Entwickler-Dokumentation aus dem Brain

Dieses Beispiel zeigt den Integrationsgedanken. Einmal pro Woche oder nach einem Release entsteht eine aktuelle Entwickler-Dokumentation. Die Quellen sind Brain-Einträge, der Aufbau folgt einem Ablaufplan aus dem Brain, und das Ergebnis ist ein Word-Dokument.

1. START (Cron, montags 7 Uhr): Startet den Lauf, oder ein Mensch startet ihn manuell nach einem Release.
2. List Brain Entries: Listet alle Einträge in den Ordnern „Architektur“ und „API“, inklusive Unterordner.
3. Loop über die Einträge: Jeder Eintrag durchläuft denselben Körper.
   • Read Brain Entry: Liest den Volltext. AI-Excluded-Einträge gehen nie an ein Modell, Confidential-Einträge nur an das lokale Modell.
   • Condition: Notizen und Entwürfe ohne Dokumentationswert werden übersprungen.
   • Classify (kleineres Modell): Bestimmt den Abschnittstyp, etwa ARCHITEKTUR, SCHNITTSTELLE, BETRIEB oder ENTSCHEIDUNG, Fallback PRÜFEN.
   • Assistant Call (kleineres Modell): Verdichtet den Eintrag zu einem Abschnitt im Entwickler-Ton. Das passiert im Loop und läuft daher für jeden Eintrag.
   • Update Brain (Modus Append): Hängt den Abschnitt an einen Arbeitseintrag an.
4. Read Brain Entry (Ablaufplan): Liest die Dokumentvorlage mit festen Kapiteln und Reihenfolge.
5. Assistant Call (Word-Generator, kleineres Modell): Ordnet die Abschnitte den Kapiteln zu und erzeugt die .docx-Datei. Die Aufgabe ist klar umrissen und folgt einem festen Format.
6. Human in the Loop: Der Dev-Lead prüft das Dokument. Bei einem Reject mit Begründung, etwa „Schnittstelle v2 fehlt“, startet die Erstellung ab dem Rücksprungziel neu.
7. Update Brain und Email Send: Die freigegebene Fassung wird als Eintrag abgelegt und mit Anhang an den Entwicklerkanal geschickt.

Das Team lässt sich ebenfalls einbinden. Ein Create-Task-Schritt legt dann die Aufgabe „Dev-Doku KW 46“ an, und das Team übernimmt. Ein Agent in der IDE prüft den Code gegen die Dokumentation. Diese Teilaufgabe läuft über MCP, und das Review-Gate bleibt am Ende des Tasks.

Der eigentliche Wert liegt im Kreislauf: Die Dokumentation ist selbst ein Brain-Eintrag, und der nächste Lauf liest sie als Ausgangspunkt.

Fazit

Ein Workflow macht aus einzelnen Antworten einen Ablauf. Der größte Teil läuft deterministisch. Das Modell kommt gezielt dort zum Einsatz, wo Urteilsvermögen nötig ist, und jeder KI-Schritt bekommt das Modell, das zu seiner Aufgabe passt. Schleifen verarbeiten jede Einzelheit, Subflows halten große Abläufe lesbar, und der Mensch entscheidet an den Stellen, an denen ein Fehler teuer wäre.

Das Zusammenspiel macht den Unterschied: Brain, Team, Dokumente, Kanäle und Systeme sind Bausteine, die ein Workflow verbindet. Ein Prompt kann die nötigen Eingaben im Chat sammeln und den Workflow starten. Wo Abwägung nötig ist, übernimmt das Team, und am Ende steht immer ein Mensch am Review-Gate.

Darin liegt auch die Stärke des Ansatzes gegenüber Lösungen, bei denen viele Einzelwerkzeuge über System- und Verantwortlichkeitsgrenzen hinweg zusammengesetzt werden. veilSense bündelt die Komponenten unter einer Oberfläche. Das soll Abläufe für die Nutzer einfacher und durchgängiger machen.

Im nächsten Teil geht es um Boards und Initiativen, also darum, wie Aufgaben dorthin gelangen und nachverfolgt werden.

---

Disclaimer: Text und Bilder dieses Beitrags wurden mit Hilfe von KI (veilSense) erzeugt und redaktionell geprüft.