Der visuelle Editor

Eine betool-Pipeline ist ein Graph aus Knoten, den Sie im visuellen Editor zusammenstellen. Jeder Knotentyp deklariert serverseitig seine Konfiguration und die Schlüssel, die er produziert; der Editor validiert Graph und Konfiguration, bevor er die Veröffentlichung zulässt.

Anatomie einer Pipeline

[Start]──▶[agent]──▶[router]──┬──▶[agent]
                              └──▶[webhook_action]

• Der Start-Knoten wird automatisch mit dem Modell erstellt; er trägt die Empfänger (Eingangskanäle), die die Pipeline auslösen. Derselbe Start kann mehrere davon deklarieren.
• Jeder nachgelagerte Knoten liest die von den vorgelagerten Knoten produzierten Schlüssel im Ausführungskontext.
• Ein Router oder Filter erzeugen Verzweigungen; jede Ausführung hinterlässt eine einsehbare Spur.

Kernkonzepte

Flussschlüssel

Ein Schlüssel ist ein benanntes Datenstück, das zwischen Knoten fließt. Beispiel: Ein Agent-Knoten kann seine Ausgabe unter exchange.intent schreiben, und ein nachgelagerter Knoten (Filter, Router) prüft diesen Schlüssel.

Was ein Knoten produziert, wird durch seinen Vertrag deklariert, in zwei Formen:

• Fester Schlüssel (fixed_key) — immer derselbe, vom Knotentyp festgelegt (z. B. input.entry_kind für den Start).
• Konfigurierbarer Schlüssel (configurable_key) — in der Konfiguration des Knotens gewählt (z. B. der Ausgabeschlüssel eines Agenten).

Was ein Knoten liest, wird in seiner Konfiguration eingestellt (das von einem Filter geprüfte Feld, die Eingaben eines Agenten …).

Vertrag

Jeder Knotentyp stellt einen serverseitig deklarierten Vertrag bereit: seine Konfigurationsfelder (Typ, erlaubte Werte, Pflichtfelder, Standardwerte) und die Schlüssel, die er produziert. Der Editor stützt sich auf diesen Vertrag, um das Konfigurationspanel aufzubauen und Ihre Eingaben zu validieren.

Konfiguration

Ein Knoten hat außerdem statische Parameter (seine Konfiguration) — für einen Agent-Knoten zum Beispiel: seine Rolle, seine Mission, seine Tools und sein LLM-Modell.

Secrets

Felder, die der Vertrag eines Knotens oder eines Empfängers als geheim deklariert (HMAC-Secret eines eingehenden Webhooks, Token oder Passwort eines HTTP-Aufrufs, Zugriffstoken einer Seite, Secret einer Sub-Pipeline …), werden nach dem Speichern nie im Klartext zurückgegeben: weder an den Editor noch über die API, weder an die MCP-Tools und Agenten, die eine Pipeline lesen, noch in Vorschlägen.

Im Inspektor zeigt ein solches Feld „•••••• gespeichert — zum Ersetzen eingeben“:

• leer gelassen, behält es das gespeicherte Secret;
• eine Eingabe ersetzt es;
• die Schaltfläche Entfernen löscht es (bei einem HMAC-Secret wird die Signaturprüfung dann deaktiviert).

Eine Pipeline erstellen

1. Modelle → Neu — in betool trägt ein Modell Ihre Pipeline.
2. Die Arbeitsfläche öffnet sich mit einem Start-Knoten. Konfigurieren Sie ihn, um den oder die Eingangskanäle zu wählen.
3. Fügen Sie Knoten über die Schaltfläche Knoten hinzufügen beim Überfahren einer Verbindung hinzu oder per Rechtsklick auf einen Knoten (Knoten davor hinzufügen / Knoten danach hinzufügen) und wählen Sie dann ihren Typ im Modulkatalog (Suche nach Namen).
4. Verbinden Sie die Knoten miteinander. Die Pipeline ist ein Baum: Jeder Knoten hat genau einen Elternknoten.
5. Klicken Sie auf einen Knoten, um seine Konfiguration im Inspektor zu öffnen.
6. Test starten — führen Sie die veröffentlichte Version mit einer frei eingegebenen Nutzlast aus, real oder im Simulationsmodus (Knoten mit externer Wirkung werden übersprungen).
7. Veröffentlichen — eine Commit-Nachricht ist Pflicht; die Pipeline wird validiert, dann wird die neue Version zu der von der Laufzeit ausgeführten.

Versionierung

Jede Veröffentlichung erstellt eine Version. Unter Versionen können Sie:

• Eine Version mit dem aktuellen Stand vergleichen (hinzugefügte, entfernte, geänderte Knoten und Verbindungen).
• Eine Version in den Editor neu laden (der Entwurf wird überschrieben, ohne zu veröffentlichen).
• Eine frühere Version erneut veröffentlichen (Rollback).

Aus dem Verlauf heraus kann eine vergangene Ausführung, die von einem Empfänger stammt, außerdem auf der veröffentlichten Version erneut abgespielt werden, mit einer gegebenenfalls geänderten Nutzlast und bei Bedarf im Simulationsmodus.

Validierung

Bei der Veröffentlichung prüft ein Validator den Graphen:

• Blockierend — Zyklus im Graphen; Knoten mit mehreren Elternknoten; nicht verdrahteter Pflichtausgang (der Rumpf einer foreach-Schleife, die Kinder eines parallel, jede deklarierte Route eines router); falsche Anzahl von Start-Knoten; knotentypspezifische Fehler (z. B. nicht existierende Rolle oder Mission eines Agenten).
• Warnung (nicht blockierend) — vom Start aus nicht erreichbarer Knoten; Abweichung einer bestehenden Konfiguration vom Vertrag ihres Knotens.

Beim Schreiben einer Konfiguration (Editor, Vorschläge, API) werden ein Wert außerhalb der erlaubten Werte oder ein fehlendes Pflichtfeld abgelehnt, mit der erwarteten Korrektur.

Folge: Eine veröffentlichte Pipeline hat diese strukturellen Prüfungen bestanden. Verbleibende Fehler betreffen die Ausführung (ein fehlgeschlagener Drittanbieter-API-Aufruf, ein unerwartetes Parsing).