Operating protocols

Ein Operating Protocol ist ein Graph aus Phasen, der steuert, wie ein Agent einen Prozess durchläuft. Statt sich auf eine einzelne Freitext-Aufgabenbeschreibung zu stützen, zerlegt das Protokoll das Verhalten des Agents in explizite Schritte — jeweils mit eigener Anweisung und optional einem auszuführenden Tool —, die über Übergänge verbunden sind. Protokolle werden auf der Node-Graph-Arbeitsfläche des Agent-Editors bearbeitet.

Felder einer Phase

Jeder Phasen-Node hat:

• Phase key — ein eindeutiger Name, der die Phase innerhalb des Protokolls identifiziert.
• Instruction — was der Agent in dieser Phase tun soll.
• Attached tool — optional ein Tool, das der Agent in dieser Phase ausführt.
• Start phase — eine Markierung, die den Beginn des Protokolls festlegt; genau eine Phase trägt sie.
• Conditional transitions — Regeln, die abhängig vom Ergebnis zur nächsten Phase führen, zum Beispiel tool_result.success → eine Zielphase.

Tool-Phasen und Verzweigungsphasen

Der Editor kennzeichnet Phasen nach ihrer Rolle:

• Eine Tool-Phase hat ein Tool angehängt — der Agent führt das Tool aus, und sein Ergebnis bestimmt die ausgehenden Übergänge.
• Eine Verzweigungsphase hat mehrere ausgehende bedingte Übergänge — der Agent wertet die Bedingungen aus und folgt dem passenden Pfad.

Die Kombination aus beidem bildet reale Prozesse ab: ein Tool ausführen und dann für Erfolg und Fehlschlag unterschiedliche Wege einschlagen.

Validierungsregeln

Der Editor validiert den Protokollgraphen, bevor er verwendet werden kann:

• Genau eine Phase ist als Startphase markiert.
• Phasennamen sind eindeutig.
• Jeder Übergang verweist auf eine existierende Zielphase.
• Alle Phasen sind bis zum Output verbunden — keine Sackgassen oder unerreichbaren Phasen.

Beheben Sie gemeldete Verstöße, bevor Sie den Agent speichern.

Hinweise zum Erstellen

• Halten Sie jede Phase auf eine Aktion oder Entscheidung fokussiert: eine Anweisung, höchstens ein Tool.
• Benennen Sie Phase keys nach ihrer Funktion (collect_details, create_ticket), damit Übergänge sich natürlich lesen.
• Decken Sie den Fehlerpfad ab: Wenn eine Phase ein Tool hat, ergänzen Sie einen Übergang für das erfolglose Ergebnis, nicht nur für tool_result.success.
• Formulieren Sie Anweisungen als Handlungsanweisungen an den Agent („Fragen Sie den Benutzer nach …”, „Fassen Sie das Ergebnis zusammen und …”), nicht als Dokumentation.
• Für einen ersten Entwurf beschreiben Sie den Prozess dem Ask-Me Assistant und verfeinern die vorgeschlagenen Phasen auf der Arbeitsfläche.

Beispiel: Ticket-Triage

Ein einfaches Triage-Protokoll für einen Support-Chat-Agent:

1. greet_and_collect (Startphase) — Instruction: „Fragen Sie den Benutzer nach der Problembeschreibung, dem betroffenen System und der Dringlichkeit. Fahren Sie erst fort, wenn alle drei Angaben vorliegen.” Übergang: Angaben vollständig → search_knowledge.

2. search_knowledge — Tool-Phase mit einem Memory-Such-Tool. Instruction: „Durchsuchen Sie die Wissensdatenbank nach einer bekannten Lösung für das beschriebene Problem.” Übergänge: tool_result.success → propose_solution; andernfalls → create_ticket.

3. propose_solution — Instruction: „Präsentieren Sie die gefundene Lösung Schritt für Schritt und fragen Sie, ob das Problem behoben ist.” Übergänge: behoben → Output; nicht behoben → create_ticket.

4. create_ticket — Tool-Phase mit einem Tool zur Ticketerstellung. Instruction: „Erstellen Sie ein Ticket mit den gesammelten Angaben und einer passenden Priorität.” Übergang: tool_result.success → confirm.

5. confirm — Instruction: „Nennen Sie dem Benutzer die Ticketnummer und die nächsten Schritte.” Verbindet zum Output.

Dieser Graph besteht die Validierung: eine Startphase, eindeutige Keys, jeder Übergang verweist auf ein Ziel, und jede Phase erreicht den Output entweder über den Lösungs- oder den Ticketpfad.