Connect · Settings · Session · Route · Identity

Fünf Backend-Dienste, eine einzige Tür nach außen.

Die Dienste sprechen untereinander über HTTP mit gegenseitig authentifiziertem TLS. Von außen ist genau einer von ihnen erreichbar. Das ist keine Konfiguration, die man vergessen kann — es ist die Topologie.

01Empfang, Arbeitsbereich, Gedächtnis

Die drei Dienste, um die es wirklich geht, lassen sich ohne ein einziges Fachwort erklären.

Connect: Der Empfang. Dort kommen Nachrichten an — aus der App, aus dem Browser, aus Telegram, aus dem Postfach.
Route: Der Arbeitsbereich. Dort denkt der Assistent nach, benutzt Werkzeuge und erledigt Aufgaben.
Session: Das Gedächtnis. Dort liegen Chatverlauf, Antworten, Arbeitsprotokolle, Nutzungsdaten, Nutzungslimits und wichtige Ereignisse.
Settings: Die Konfiguration. Dort liegen die Einstellungen und Instruktionen der Agenten, die Einbindung der Modelle und Anbieter, die Skills, die Jobs sowie Email-Konfigurationen.
Identity: Die Benutzerverwaltung. Dort werden die Berechtingungen aller Agenten und Benutzer sowie die Geräteverknüpfungen, Authorisierung und Passwortzurücksetzungen behandelt.

02Das ganze Bild

Eine Anfrage nimmt immer denselben Weg. Nur Connect steht dabei mit einem Fuß draußen.

Abb. 01Der Weg einer Anfrage durch das System.

Diagramm als Text

Die Benutzer App spricht mit dem Backend.
Das Admin Portal konfiguriert das Backend.
Telegram und E-Mail liefern Nachrichten an das Backend.
Im Backend nimmt Connect alles entgegen — es ist der einzige Dienst, der von außen erreichbar ist.
Route fragt das gewählte Sprachmodell und führt Werkzeuge aus.
Das Modell antwortet an Route zurück.
Session speichert Verlauf, Lauf, Schritte und Kosten.
Das Ergebnis geht über Connect zurück an die App.

Route, Session, Settings und Identity liegen ausschließlich im internen Netz. Zwei Verbindungen überqueren die Grenze: Traefik zu Connect hinein, und Route zum Sprachmodell hinaus.

03Was ein Lauf ist

Nicht „der Assistent hat geantwortet“, sondern eine Kette einzeln protokollierter Schritte.

ModelRequest
ModelResponse
ToolCallRequested
ToolCallCompleted
FinalResponseStored
OutboundDeliveryRequested
OutboundDeliveryCompleted

Die Werkzeug-Schritte wiederholen sich, solange der Agent arbeitet, bis zur eingestellten Obergrenze an Werkzeug-Durchläufen. Jeder Schritt trägt einen Zeitstempel, und bei Modellschritten auch Anbieter, Modell und Token-Zahlen.

Die Schrittansicht eines Laufs in der Konsole: elf Schritte mit Typ, Zeitstempel und Token-Zahlen. — Abb. 02Derselbe Ablauf in der Konsole. Elf Schritte, keiner davon zusammengefasst.

04Skill, Job, Session

Diese drei werden am häufigsten verwechselt, und der Unterschied ist ganz klein.

Skill: Beschreibt, wie eine Aufgabe gelöst werden soll.
Job: Bestimmt, wann eine Aufgabe automatisch gestartet wird.
Session: Ist der aktuelle Gesprächskontext mit einem Benutzer in einem Kanal.

Daraus folgt alles Praktische: Sie bauen einen Skill einmal und verwenden ihn beliebig oft. Sie lassen denselben Skill manuell oder über einen Job laufen. Und Sie können eine Session mit /new neu starten, ohne den Skill oder den Job zu verlieren.

05Was drin ist und was nicht

PostgreSQL: Eine Datenbank pro Dienst, ein Server.
Internes mTLS: Gegenseitig authentifiziertes TLS zwischen allen Diensten, mit Service-Tokens von Identity.
Zugangsdaten: Anbieter-Schlüssel liegen verschlüsselt und werden erst beim Start eines Laufs aufgelöst. Der Worker hält sie nicht, das Modell sieht sie nie.
Limits: Route prüft das Nutzungslimit des Benutzers, bevor Arbeit überhaupt angenommen wird.
Kein RAG: Keine Vektordatenbank, keine Einbettungen. Gesucht wird wörtlich in Dateien (erweiterbar, wenn sie es benötigen).
Keine Telemetrie: Die Installation meldet nichts nach außen.