Routing und Sessions

Wenn ein Nutzer eine Nachricht sendet, muss der Orchestrator entscheiden, welcher Agent sie bearbeitet. Die Routing-Regeln in agent.yaml steuern dieses Verhalten. Sessions halten den laufenden Gesprächszustand zwischen Nutzer und Agent fest.

Routing-Modi

Selu unterstützt zwei Routing-Modi:

Inline-Modus (Standard)

Im Inline-Modus prüft der Orchestrator jede eingehende Nachricht gegen alle installierten Agenten und wählt die beste Übereinstimmung aus. Das ist der Standard, wenn ein Nutzer mehrere Agenten installiert hat.

routing:
  mode: inline
  triggers:
    - intent: weather_query
    - mention: "@weather"
  priority: 10

Der Orchestrator bewertet jeden Agenten anhand passender Trigger und Priorität. Der Agent mit der höchsten Punktzahl übernimmt die Nachricht.

Dedicated-Modus

Im Dedicated-Modus gehört dem Agenten ein kompletter Kanal oder Gesprächs-Thread. Alle Nachrichten in diesem Kontext gehen direkt an ihn, ohne weitere Routing-Auswertung.

routing:
  mode: dedicated

Das ist nützlich für Bots mit nur einem Zweck oder wenn der Nutzer ausdrücklich eine Session mit einem bestimmten Agenten startet.

Trigger

Trigger helfen dem Orchestrator im Inline-Modus, Nachrichten den richtigen Agenten zuzuordnen.

Trigger	Beschreibung	Beispiel
mention	Passt, wenn die Nachricht eine bestimmte @-Erwähnung enthält	@weather
intent	Passt, wenn der leichte Klassifikator des Orchestrators eine semantische Absicht erkennt	weather_query
keyword	Passt, wenn bestimmte Schlüsselwörter in der Nachricht auftauchen	forecast, temperature
regex	Prüft einen regulären Ausdruck gegen den Nachrichtentext	\bweather\b

Trigger werden der Reihe nach ausgewertet. Der erste Treffer gewinnt für diesen Agenten, und dessen Priorität wird dann für das Ranking verwendet.

Hinweis

Intents werden von einem kleinen, schnellen Modell vor dem eigentlichen LLM-Aufruf klassifiziert. Das erhöht die Latenz kaum, ermöglicht aber semantisches Matching über einfache Schlüsselwörter hinaus.

Priorität

Wenn mehrere Agenten passen, entscheidet priority. Höhere Werte gewinnen. Standard ist 0.

routing:
  priority: 10   # higher = more likely to be selected

Sessions

Eine Session ist ein zustandsbehaftetes Gespräch zwischen einem Nutzer und einem Agenten. Sessions verfolgen:

• Nachrichtenverlauf: Das rollierende Fenster von Nachrichten, die an das LLM gesendet werden
• Erinnerungskontext: Langzeitfakten, die über Sessions hinweg gespeichert werden, wenn aktiviert
• Aktiven Capability-Zustand: Wenn eine Capability mehrstufige Abläufe nutzt, hält die Session den Zwischenzustand

Session-Konfiguration

memory:
  session_ttl: 3600       # seconds before an idle session expires
  max_history: 50         # max messages retained in the context window
  long_term: true         # persist facts to vector-backed long-term memory

Kurzlebige Sessions

Für zustandslose Utility-Agenten wie einen Einheitenumrechner verwende einen niedrigen session_ttl-Wert und deaktiviere long_term:

memory:
  session_ttl: 300
  max_history: 10
  long_term: false

Dauerhafte Sessions

Für persönliche Assistenten, die sich Nutzer über längere Zeit merken sollen:

memory:
  session_ttl: 86400
  max_history: 100
  long_term: true

Session-Handoff

Wenn ein Agent per delegate_to_agent an einen anderen Agenten delegiert, kann der Orchestrator entweder eine neue Session für den Zielagenten erzeugen oder die bestehende weiterführen. Gesteuert wird das über den Parameter new_session des Tools delegate_to_agent.

Nächste Schritte

Jetzt, wo du Routing verstanden hast, kannst du mit Baue deinen ersten Agenten alles zusammensetzen.