PROJEKTEINBLICK ·
Eine Nachricht an meinen Assistenten
Mein Assistent hatte inzwischen eine Weboberfläche, Widgets und einen Signal Desk. Der nächste Zugang musste nicht noch mehr auf dem Bildschirm zeigen. Mit Telegram konnte eine Nachricht vom Telefon aus denselben Assistenten erreichen. Damit kam aber auch eine neue Frage dazu: Wer durfte ihm auf diesem Weg überhaupt Aufträge geben?
Bis dahin hatte ich viel Arbeit in die unmittelbare Bedienung gesteckt. Ich konnte mit meinem Assistenten sprechen, seine Antworten sehen und Informationen in den Widgets verfolgen. Mit Telegram kam eine andere Form der Eingabe dazu: eine Textnachricht über einen externen Dienst.
Die eigentliche Anwendung sollte dafür weiterhin auf meinem Rechner laufen. Ich wollte einen zusätzlichen Zugang zu den vorhandenen Fähigkeiten schaffen. Ein zweiter Assistent mit einer eigenen Umsetzung sämtlicher Befehle hätte das Projekt unnötig auseinandergezogen.
Der Eingang änderte sich, der Kern blieb
Der Telegram-Bot nahm Nachrichten entgegen und gab den enthaltenen Auftrag an den bestehenden Orchestrator weiter. Von dort ging es durch die vorhandene Verarbeitung. Die Antwort wurde anschließend an den Chat zurückgesendet.
Ein weiterer Zugang sollte die vorhandenen Fähigkeiten nutzen, statt sie ein zweites Mal zu erfinden.
Die Ausgabe brauchte allerdings eine Anpassung an den Kanal. Eine Telegram-Nachricht sollte ihre Antwort im Chat bekommen. Der Aufruf an den Orchestrator verwendete dafür den stillen Modus, sodass dieser Auftrag keine lokale Sprachausgabe auslöste.
| Schritt | Aufgabe |
|---|---|
| Nachricht empfangen | Telegram liefert die Eingabe an den Bot |
| Absender prüfen | Die Anwendung prüft die zugelassene Identität und gegebenenfalls den Chat |
| Auftrag weitergeben | Der vorhandene Orchestrator verarbeitet den Text |
| Antwort zurücksenden | Das Ergebnis erscheint als Nachricht im Chat |
Der Bot war damit eine Verbindung zu meinem laufenden System. Wenn der Rechner oder die Anwendung nicht lief, stand dieser Zugang auch nicht zur Verfügung.
Der Absender gehörte jetzt zum Auftrag
Eine Nachricht über einen Bot durfte nicht einfach deshalb verarbeitet werden, weil sie angekommen war. Bevor der Text den Assistenten erreichte, musste klar sein, ob er von der vorgesehenen Person kam.
Die Konfiguration enthielt dafür eine zugelassene Benutzer-ID. Ohne diese Angabe wurde die Verarbeitung der Fernbefehle nicht aktiviert. Zusätzlich konnte der Zugriff auf einen bestimmten Chat begrenzt werden.
Das war eine neue Prüfung vor der eigentlichen Intent-Pipeline. Zuerst musste die Nachricht diesen Eingang passieren. Erst danach stellte sich die Frage, was der Auftrag bedeutete und welcher Ausführungspfad dazu passte.
Auch die Häufigkeit von Befehlen brauchte eine Grenze. Der Bot bekam deshalb eine Begrenzung für eingehende Kommandos. Zu viele Anfragen sollten nicht ungebremst in der gemeinsamen Verarbeitung landen.
Bekannt heißt nicht automatisch erlaubt
Die zugelassene Identität beantwortete eine wichtige Frage. Sie bedeutete aber nicht, dass jeder Auftrag unabhängig von seiner Wirkung ausgeführt werden sollte.
Eine Statusfrage und eine Aktion mit Folgen für Anwendungen oder Dateien blieben unterschiedliche Dinge. Die Regeln, die ich für die Fähigkeiten vorgesehen hatte, mussten auch bei diesem Zugang relevant bleiben.
Ich wollte dafür keinen Nebenweg schaffen, der an der bestehenden Verarbeitung vorbeiging. Die Nachricht wurde deshalb in den gemeinsamen Orchestrator eingespeist. Welche Aktion daraus entstand und ob sie eine Freigabe brauchte, gehörte weiterhin in die dafür zuständige Anwendungsschicht.
Damit wurde die Unterscheidung aus dem Wetter- und Signal-Desk-Teil noch einmal konkreter. Mein Assistent konnte lokal arbeiten und trotzdem einen bewusst eingerichteten Weg nach außen besitzen.
Erreichbar sein war eine eigene Fähigkeit
Der zusätzliche Kanal machte nicht plötzlich neue Skills nötig. Er veränderte, von wo aus vorhandene Fähigkeiten angesprochen werden konnten. Das war für die Architektur ein interessanter Unterschied.
Der Bot konnte optional bleiben. Fehlende Konfiguration sollte nicht dazu führen, dass die übrige Anwendung ihre Arbeit verlor. Der lokale Assistent und seine Weboberfläche hatten weiterhin ihren eigenen Nutzen.
So wuchs das Projekt um einen weiteren Eingang, ohne dass ich sein Innenleben dafür verdoppeln musste. Gleichzeitig kamen Prüfungen hinzu, die an genau diesen Eingang gehörten: Identität, Chat, Konfiguration und die Anzahl eingehender Aufträge.
Während solche Erweiterungen neue Möglichkeiten eröffneten, blieb die direkte Unterhaltung eine eigene Baustelle. Gerade im Browser konnte ich sehr genau spüren, ob zwischen meinem Klick, meiner Eingabe und der ersten hörbaren Antwort zu viel Zeit verging.
