KI-Concierge: ein Sprach­as­sis­tent aus der Freizeit

Ein Bildschirm im Hochformat, ein Mikrofon, eine Frage. „Wo finde ich den Vortrag über Telefonie?“, „Wann fährt die nächste S-Bahn?“, „Können Sie mich mit jemandem verbinden?“ Der KI-Concierge beantwortet so etwas mit Stimme, in fünf Sprachen, aus einer eigenen Wissensbasis, und wenn er nicht weiterweiß, ruft er einen Menschen an.

Gebaut habe ich ihn zwischen Ende Oktober 2025 und April 2026, ausschließlich abends und an Wochenenden. Im Einsatz war er zuerst auf einer großen Hausmesse und danach auf der DMEA in Berlin. Dieser Bericht erzählt, was im Code steckt, wo überall ein Sprachmodell arbeitet, was im Lärm einer Halle anders ist als am Schreibtisch, und wie sich das Bauen selbst mit jedem neuen Modell verändert hat.

Die Zahlen stammen aus dem Repository, gezählt am 03.10.2026. Wo eine Angabe nur aus der Projektdoku stammt, steht das dabei.

Steckbrief

Die Codezeilen sind grob mit wc -l über die versionierten Dateien gezählt, ohne Abhängigkeiten. Sie zeigen die Größenordnung. Über die Qualität sagen sie nichts.

Die Bausteine, ohne Adressen: ein Kiosk-Frontend im Browser, eine Admin-Oberfläche in Vue, ein Backend in Python mit FastAPI, eine Vektordatenbank (ChromaDB), ein Telefonie-Gateway auf Basis von FreeSWITCH, der Realtime-Dienst von OpenAI für das Gespräch und ein Tunnel für den Zugang von außen. Auf Wunsch spricht ein Video-Avatar von Beyond Presence die Antworten lippensynchron mit, angebunden über einen LiveKit-Raum.

Drei Arten, ein Gespräch zu führen

Ein Sprachassistent lässt sich auf drei Arten bauen, und sie unterscheiden sich vor allem darin, wie lange man auf die Antwort wartet und ob man dazwischenreden kann. Die Grundlagen stehen im Kapitel Was Conversational AI ist.

Regelbasiert. Der Assistent erkennt eine Absicht und spielt die passende Antwort ab. Das ist vorhersagbar und billig, aber jede Frage, die niemand vorhergesehen hat, endet im Ausweichsatz. Im Concierge gibt es diese Art nur als Hilfsbaustein: lokale Befehle wie /help, die gar nicht erst an ein Modell gehen, die Moderation und die Wör­ter­buch­kor­rektur.

Als Kette. Spracherkennung macht aus dem Ton Text, ein Sprachmodell antwortet als Text, eine Sprachsynthese liest vor. Jede Stufe ist austauschbar, jede lässt sich einzeln prüfen. So hat der Concierge angefangen: Die erste Fassung Ende Oktober lief mit einer lokalen Whisper-Variante, einem lokal betriebenen Sprachmodell und der Sprachausgabe des Browsers. Das Problem stand schon in den ersten Sprintberichten. Ein lokales Modell, das seine Antwort als Datenstrom liefert, ließ sich mitten im Strom nicht sauber anhalten. Genau das war aber das Ziel: dem Assistenten ins Wort fallen zu können.

Von Ton zu Ton. Ein Realtime-Modell nimmt den Ton direkt entgegen und antwortet als Ton, ohne Text dazwischen. Die Sprach­ak­ti­vi­täts­er­ken­nung des Anbieters meldet, wann jemand anfängt oder aufhört zu sprechen, und das Modell kann mitten in der Antwort Werkzeuge aufrufen. Am 15.11.2025 flog die lokale Kette raus, der Commit sagt „100% OpenAI Realtime API“. Seitdem führt nur noch diese Art das Gespräch. Wie das technisch läuft, erklärt das Kapitel Wenn das Gespräch nicht in Runden läuft.

seitlich verschiebbar

eigene Darstellung, Stand 03.10.2026

Warum Ton zu Ton? Eine Entscheidung mit Abwägung steht nirgends im Repository, die Gründe lassen sich nur aus der Doku zusammensetzen: Antworten in unter einer Sekunde, Unterbrechbarkeit von Anfang an, und eine Stimme, die spricht wie ein Mensch. Die Projektdoku nennt beim Wechsel auf das neue Modell eine kürzere Zeit bis zum ersten Ton. Eine Quelle gibt sie dafür nicht an, und eine eigene Messung gibt es nicht.

Der Weg dorthin in vier Schritten:

Die Ton-zu-Ton-Bauart kostet Kontrolle. In einer Kette sieht man den Text, bevor er gesprochen wird. Hier sieht man ihn erst, wenn er schon unterwegs ist. Das bestimmt den nächsten Abschnitt.

Ins Wort fallen, und warum es aus blieb

Eine Antwort zu unterbrechen klingt einfach. Im Kiosk mit Avatar sind es sechs Schritte, und die meisten davon sind Schutz gegen Fehlalarme. Der Kiosk ohne Avatar bricht die Antwort nur ab, sobald jemand spricht, während die KI antwortet. Der Begriff dafür ist Barge-in.

1. Erkennen. Das Mikrofon läuft fortlaufend zum Anbieter. Dessen Sprach­ak­ti­vi­täts­er­ken­nung meldet: Hier beginnt jemand zu sprechen.
2. Prüfen. Ausgelöst wird nur, wenn drei Dinge zugleich stimmen: Die Funktion ist eingeschaltet, die KI erzeugt oder spielt gerade eine Antwort, und das Mikrofon nimmt tatsächlich auf. Eine Meldung ohne aktive Aufnahme gilt als Echo.
3. Abbrechen. Die laufende Antwort wird beim Anbieter gestoppt, die Wiedergabe kurz ausgeblendet und geleert.
4. Kürzen. Der Gesprächsverlauf beim Anbieter wird auf das gekürzt, was tatsächlich zu hören war. Sonst „glaubt“ das Modell, es habe einen Satz zu Ende gesagt, den niemand gehört hat.
5. Nachzügler verwerfen. Jede Antwort bekommt eine Kennung, jede Abschrift eine Generationsnummer. Ereignisse zu einer abgebrochenen Antwort werden verworfen. Im Zweifel wird geblockt.
6. Avatar stoppen. Läuft der Video-Avatar, wird sein Segment sofort beendet, ohne auf die Bestätigung des Anbieters zu warten.

Und dann, am 01.02.2026, der Commit, der das alles standardmäßig abschaltet. Die Begründung steht im Commit selbst: In lauter Umgebung löst die Sprecherkennung fälschlich aus. Eine Messehalle ist laut. Nebengespräche, Durchsagen, das eigene Echo aus dem Lautsprecher: Jedes davon kann für das Modell „jemand spricht“ sein, und dann bricht der Assistent mitten im Satz ab, obwohl niemand etwas wollte.

Bei ausgeschaltetem Barge-in wird das Mikrofon während der Antwort hart stummgeschaltet und geht erst nach einer kurzen Abklingzeit wieder auf. Das ist weniger elegant, aber vorhersagbar. Im März kam eine Abbrechen-Schaltfläche dazu, mit der man eine Antwort per Fingertipp beendet. Vor dem zweiten Einsatz habe ich außerdem mit Push-to-Talk experimentiert, also Sprechen nur bei gedrückter Taste. In der kurzen Zeit bis zur Messe ließ sich das nicht ausreifen. Die Funktion steht im Code und ist im Standard aus.

Die Lehre daraus: Laute Umgebung schlägt elegante Technik. Was am Schreibtisch mit Kopfhörer tadellos funktioniert, ist am Stand ein Risiko.

Die Abschrift als Steuersignal

Neben dem Gespräch läuft ein zweiter Kanal: Ein eigenes Tran­skrip­ti­ons­mo­dell schreibt mit, was der Mensch sagt. Angezeigt wird der Text auch, aber das ist Nebensache. Wichtiger ist, was das System mit ihm tut.

Die Abschrift ist dabei nicht das, worauf das Modell antwortet. OpenAI schreibt das in der Schnitt­stel­len­re­fe­renz (externe Seite, developers.openai.com) selbst: Die Abschrift gehört nicht zum Modell, weil das Modell den Ton direkt verarbeitet. Das Modell hört den Ton, die Abschrift ist eine zweite, unabhängige Erkennung desselben Tons.

Genutzt wird sie trotzdem, an drei Stellen:

• Moderation. Die Schutzregeln prüfen die Abschrift. Bei einem Verstoß wird die Antwort abgebrochen und ein Hinweis angezeigt.
• Korrektur. Eigennamen und Fachbegriffe, die falsch erkannt wurden, werden über ein Wörterbuch ersetzt (mehr dazu weiter unten).
• Halluzinationen der Erkennung. Bei Husten, Murmeln oder Stille gibt die Transkription manchmal ihre eigene Stichwortliste als „erkannten Text“ zurück. Das System erkennt das an der Ähnlichkeit zur Liste, bricht die entstehende Antwort ab und leert den Eingabepuffer. Im Kiosk mit Avatar löscht es den Eintrag außerdem aus dem Verlauf.

Der dritte Punkt hat eine Kehrseite: Das Modell kann den Ton richtig verstanden haben, während nur der Nebenkanal halluziniert. Dann bricht die Anwendung eine womöglich richtige Antwort ab. Gemessen habe ich das nicht. Ob der Abbruch greift, ist deshalb in der Admin-Oberfläche einstellbar. Mehr zum Phänomen im Kapitel Halluzinationen erkennen und im Diktier-Bericht, wo derselbe Effekt beim eigenen Wächter auftauchte.

Fünf Sprachen, eine Wissensbasis

Der Concierge spricht Deutsch, Englisch, Französisch, Spanisch und Italienisch. Deutsch ist voreingestellt. Die Admin-Oberfläche schaltet die übrigen Sprachen frei, und mindestens eine bleibt immer aktiv.

Eine automatische Spracherkennung gibt es nicht. Die Sprache wählt man über eine Taste, die durch die freigegebenen Sprachen schaltet, und die gewählte Sprache wird der Transkription vorgegeben. In einer Halle, in der fünf Gespräche gleichzeitig laufen, ist eine falsch erkannte Sprache teurer als ein Tastendruck.

Unterschätzt hatte ich:

• Die Wissensbasis bleibt deutsch. Eine Frage auf Französisch wird vor der Suche von einem kleinen, schnellen Modell ins Deutsche übersetzt, mit Zwischenspeicher. Dauert das zu lange, sucht das System mit der Originalfrage.
• Die Antwortsprache muss man nach jedem Werkzeugaufruf neu sagen. Mit der Anweisung „antworte in der aktuellen Sitzungssprache“ kam nach einer Wissensabfrage gelegentlich Englisch zurück. Erst die ausdrücklich genannte Sprache hielt.
• Deutsch braucht ein Sprach-Pinning. Bei englischen Eigennamen kippte die Betonung ins Englische oder in ein Denglisch, das niemand bestellt hatte.

Eine eigene Stimme pro Sprache gibt es nicht, eine Stimme gilt für alle. Was eine Stimme heute noch über ihren Sprecher beweist, steht im Kapitel Was die Stimme noch beweist.

Ein Gesicht zur Stimme: der Video-Avatar

Seit Mitte Februar 2026 kann der Concierge auch ein Gesicht zeigen. Auf einer eigenen Kiosk-Seite spricht ein fotorealistischer Avatar die Antworten lippensynchron mit. Der Proof of Concept entstand in der Nacht zum 14.02.2026, in den Tagen danach kamen Kontaktkarten, Telefon, Vorschlagskarten, Mehrsprachigkeit und eine eigene Auswertung der Video-Sitzungen dazu.

Drei Anbieter, eine Schnittstelle

Gebaut ist der Avatar hinter einer eigenen Abstraktion: Jeder Anbieter bekommt eine Klasse mit demselben Lebenslauf (vorbereiten, starten, stoppen, abbauen), welcher gerade läuft, entscheidet eine Einstellung. Angelegt sind drei:

Im Einsatz ist Beyond Presence, und dazu passt die Bauart: Der Avatar braucht nur den Ton der Antwort, er bringt kein eigenes Sprachmodell und keine eigene Stimme mit. Das Gespräch führt weiter das Realtime-Modell, der Avatar leiht ihm nur das Gesicht. Die Angaben der Hersteller zu Latenz und Qualität habe ich nicht nachgemessen.

LiveKit: der Raum, in dem sich alle treffen

Zwischen Backend, Avatar und Browser liegt LiveKit. LiveKit ist ein quelloffener Medienserver für WebRTC, genauer eine Selective Forwarding Unit: Jeder Teilnehmer schickt seine Spuren einmal an den Server, und der verteilt sie an alle, die sie abonniert haben. Genutzt habe ich die gehostete Fassung, LiveKit Cloud. Beyond Presence setzt selbst darauf, ihr Avatar tritt als Teilnehmer in einem LiveKit-Raum auf.

Vier Begriffe aus LiveKit reichen, um den Avatar zu verstehen:

Dazu kommt ein Baustein, den man erst bemerkt, wenn er fehlt: der TURN-Server. WebRTC versucht zuerst, Daten direkt per UDP zu schicken. In Firmennetzen, Messehallen und hinter manchen Routern ist UDP gesperrt, und dann kommt keine Verbindung zustande. Ein TURN-Server leitet den Medienstrom stattdessen weiter, notfalls verschlüsselt über TCP auf dem Port, den auch jede Webseite benutzt. Einen eigenen TURN-Server betreibe ich dafür nicht, LiveKit Cloud bringt ihn mit. Das Relay im Backend ist fest auf diesen Weg eingestellt, es versucht UDP gar nicht erst. Der Browser nimmt den direkten Weg, wenn er offen ist, und fällt sonst auf TURN zurück.

Der Weg des Tons: Abgriff und Relay

Die eigentliche Frage beim Bau war: Wie kommt der Antwortton des Modells zum Avatar, und zwar so früh, dass Lippen und Stimme zusammenpassen? Die Lösung hat zwei Teile, einen Abgriff im Backend und ein Relay im LiveKit-Raum.

1. Mikrofon zum Modell. Der Browser schickt den Ton über das eigene Backend an das Realtime-Modell. Auf der Avatar-Seite läuft das Gespräch deshalb über eine WebSocket-Verbindung durch das Backend. Nur so sieht das Backend die Antwort.
2. Die Antwort kommt als Datenstrom. Das Modell liefert seine Antwort in kleinen Tonstücken, jedes ein eigenes Ereignis.
3. Abgriff (Audio-Tap). Das Backend greift jedes Tonstück ab und gibt es zweimal weiter: unverändert an den Browser und zugleich an das Relay.
4. Relay. Das Relay ist ein eigener Teilnehmer im LiveKit-Raum, gestartet vom Backend. Es schreibt den Ton als rohe PCM-Daten (16 Bit, 24 kHz, mono) in einen Datenstrom, einen Strom je Äußerung. Ist die Äußerung zu Ende, schließt es den Strom, und genau das ist für den Avatar das Signal „jetzt sprechen“.
5. Avatar. Der Avatar von Beyond Presence sitzt als dritter Teilnehmer im selben Raum, betrieben in deren Cloud. Er liest den Datenstrom, erzeugt daraus Video mit passenden Lippenbewegungen und sendet Bild und Ton zurück in den Raum.
6. Browser. Der Browser empfängt nur. Er abonniert Bild und Ton des Avatars und spielt beides ab. Ist die Äußerung durch, meldet der Avatar das per Fernaufruf an das Relay, das Backend gibt es an den Browser weiter, und erst dann geht das Mikrofon wieder auf.

seitlich verschiebbar

eigene Darstellung nach dem Quelltext, Stand 21.04.2026

Im Raum sind damit drei Teilnehmer mit klar getrennten Rollen: der Browser, der nur empfängt, das Relay, das nur Ton als Datenstrom sendet, und der Avatar, der Datenstrom liest und Video sendet.

Der Browser kennt dabei keinen Schlüssel. Er bekommt vom Backend nur ein kurzlebiges Zutrittstoken für den Raum. Der Zugang des Relays und die Schlüssel der Anbieter bleiben im Backend, die Antwort an den Browser und die Angaben für das Relay laufen getrennt.

Warum sitzt der Abgriff im Backend? Die erste Fassung schickte den Ton vom Browser zurück ans Backend und von dort zum Avatar. Das war ein Umweg über die Leitung des Kiosks, der für jede Antwort Zeit kostete. Seit dem Abgriff geht der Ton auf dem kürzesten Weg vom Modell zum Avatar, der Browser ist aus der Schleife.

Zwei Arten, den Ton abzuspielen

Mit Avatar gibt es zwei Wiedergabearten. Direkt: Der Browser spielt den Ton des Modells selbst ab, das Video läuft daneben. Synchron: Der Ton kommt aus dem Raum, also vom Avatar, und ist damit genau so verzögert wie seine Lippen. Der lokale Ton schweigt dann. Synchron bedeutet auch, dass „fertig gesprochen“ der Avatar meldet. Davon hängt ab, wann das Mikrofon wieder aufgeht und wann eine aufgeschobene Aktion wie ein Sprachwechsel ausgeführt wird.

Was dabei schiefging

• Nur die erste Antwort bewegte die Lippen. Die Datenströme hießen anfangs fortlaufend „AUDIO_1“, „AUDIO_2“. Der Avatar ignoriert einen Namen, den er schon kennt, also bekam jeder Strom eine zufällige Kennung. Und ohne einen Empfänger für die Fertigmeldung des Avatars nahm er nach dem ersten Abschnitt gar nichts mehr an. Beides stand in keiner Doku, gefunden habe ich es im Quelltext des LiveKit-SDK, an dem Baustein, den der Hersteller selbst benutzt.
• Fünfzehn Sekunden Stille ohne Fehlermeldung. Aus dem Container kam das Relay nicht in den Raum. Die Signalisierung lief, der Medienweg nicht. Die native Bibliothek von LiveKit prüft Zertifikate gegen den Zer­ti­fi­kats­spei­cher des Systems, und dem schlanken Python-Image fehlte genau die Wurzel, auf die der Medienweg des Anbieters zurückgeht. Seitdem kopiert der Build die Zertifikate aus Python in den Systemspeicher. Gefunden hat die Ursache erst eine Analyse der nativen Bibliothek.
• Die Sekunde Puffer. Der Avatar sammelt rund eine Sekunde Ton, bevor er Video erzeugt. Das liegt in seiner Bauart. Im synchronen Modus kommt die Stimme deshalb mit derselben Verzögerung, und genau dafür gibt es diesen Modus: Lippen und Ton bleiben beieinander.
• Abbrechen ohne Bremse. Der Avatar hat keine Funktion, seinen Puffer zu leeren. Wer eine Antwort abbrach, sah ihn noch Sekunden lang stumm die Lippen bewegen, und bei der nächsten Antwort kam der alte Ton zurück. Die Lösung im Browser ist eine harte Trennung: Das letzte Bild bleibt als Standbild stehen, Bild und Ton werden abgehängt, der Ton sogar abbestellt. Bei der nächsten Antwort wird alles frisch abonniert, und der Ton geht erst mit dem ersten neuen Tonstück wieder an. Beim Modell wird der Verlauf auf das gekürzt, was zu hören war, wie beim Ins-Wort-Fallen.

Das Ergebnis

Am Ende tat der Avatar genau, was er sollte. Er spricht lippensynchron, Stimme und Mund passen zusammen, und die zusätzliche Verzögerung bleibt so gering, dass das Gespräch flüssig wirkt. Er läuft auf der Stele ebenso wie auf dem Smartphone, über Firmennetze hinweg, und ein Abbruch hinterlässt keine Geisterbilder mehr.

Der Weg dorthin war aufwendig: zwei Live-Verbindungen statt einer, ein weiterer Anbieter im Spiel und viel Zustandslogik für Abbrüche. Der Avatar gehört zu den aufwendigsten Bausteinen des Projekts. Ob ein Gesicht ein Gespräch besser macht oder nur auffälliger, habe ich nicht gemessen. Was eine Stimme heute noch über ihren Sprecher beweist und wann eine nachgebildete offengelegt werden muss, behandelt das Kapitel Was die Stimme noch beweist.

Wo überall ein Sprachmodell arbeitet

Wer „KI-Assistent“ hört, denkt an ein Modell. Im Concierge sind es zehn Einsatzstellen, alle beim selben Anbieter. Welches Modell wo läuft, regeln vier Stufen, die in der Admin-Oberfläche einstellbar sind: Realtime, Transkription, eine schnelle Stufe („Fast“) und eine gründliche („Smart“). Dazu kommt das Embedding als eigene Einstellung.

seitlich verschiebbar

eigene Darstellung nach dem Quelltext, Stand 21.04.2026

Die letzte Zeile ist die lehrreichste. Die Korrektur der Abschrift per Sprachmodell gab es, sie ist im Standard aus. Die Begründung im Code ist ein einziger Satz: „LLM was reverting valid fuzzy corrections“. Das Wörterbuch hatte einen Fachbegriff richtig gesetzt, und das Sprachmodell hat ihn wieder „verbessert“. Jedes zusätzliche Modell muss sich seinen Platz erst verdienen.

Genauso aufschlussreich ist, wo kein Sprachmodell arbeitet. Die Moderation ist regelbasiert. Ein Re-Ranking der Suchtreffer gibt es nicht. Gesprächs­zu­sam­men­fas­sungen gibt es nicht. Und die Vorschlagskarten, die man antippen kann, statt zu sprechen, hat einmal beim Bauen eine Sitzung mit Claude Code aus dem Inhalt der Wissensbasis befüllt. Gespeichert sind sie als feste Einträge, die sich im Admin ändern lassen. Zur Laufzeit übersetzt ein Sprachmodell sie nur. Was auf einer Karte steht, liegt also fest, bevor der erste Besucher kommt.

Ein Claude-Modell läuft im Betrieb übrigens nirgends. „Claude“ steht im Laufzeitcode als Stichwort in der Erkennung von Jailbreak-Versuchen. An einer zweiten Stelle wird der Hinweis „Generated with Claude Code“ aus angezeigten Dokumenten entfernt.

Wissen: Chunking, BM25 und drei Stufen der Suche

Die Wissensbasis besteht aus gut 70 Markdown-Dokumenten mit Metadaten im Kopf, versioniert im Repository. Wie eine Frage zur passenden Stelle findet, erklären die Kapitel RAG, die Suche vor der Antwort und Embedding. Im Concierge sieht das so aus:

Zerlegen entlang der Struktur. Geschnitten wird an den Überschriften der zweiten Ebene. Die Überschrift bleibt beim Text, sehr kurze Abschnitte werden zusammengelegt, sehr lange geteilt. Für Text ohne Gliederung gibt es ein festes Fenster mit großzügiger Überlappung, geschnitten bevorzugt an Satzgrenzen. Vor dem Einbetten werden die Metadaten des Dokuments an jeden Chunk gehängt.

Zwei Suchen statt einer. Seit dem 20.12.2025 läuft eine hybride Suche: BM25 für exakte Wörter zusammen mit der Vektorsuche für Bedeutung. Die Gewichtung hängt von der Anfrage ab. Namen, Nummern und Ein-Wort-Anfragen bekommen mehr Gewicht auf BM25, denn ein Nachname hat keine „Bedeutung“, die ein Embedding treffen könnte. Die Gewichte lassen sich im Admin ohne Neustart ändern.

Drei Stufen der Erweiterung. Findet eine kurze Anfrage nichts, wird sie erweitert, in dieser Reihenfolge: Schlüsselwörter aus den Metadaten, dann eine feste Synonymliste, und erst zuletzt ein Sprachmodell, und auch das nur für unbekannte Einzelwörter. Der teure Schritt kommt zuletzt und nur, wenn die billigen nichts gefunden haben.

Boost ohne Schummeln. Bestimmte Kategorien, etwa Ansprechpartner, werden in der Rangfolge nach oben geschoben. Ob ein Treffer aber überhaupt relevant genug ist, wird gegen den Wert ohne Boost geprüft. Sonst würde ein schwacher Treffer nur deshalb genannt, weil er in der richtigen Schublade liegt.

Die Werk­zeug­be­schrei­bung schreibt sich selbst. Bei jedem Neuaufbau des Index wird die Beschreibung, mit der das Realtime-Modell das Suchwerkzeug kennt, neu erzeugt: mit den Themen und Schlagworten, die gerade in der Wissensbasis stehen, und einem Abschnitt gegen Halluzinationen. Das Modell weiß damit, wann sich eine Suche lohnt.

Werkzeuge und Telefon

Fünf Werkzeuge kann das Modell selbst aufrufen, per Function Calling. Es entscheidet allein, wann. Die Grundlagen dazu im Kapitel Tools anbinden.

MCP kommt im Betrieb nicht vor. Fünf feste Werkzeuge in einer eigenen Anwendung brauchen keinen Standard für austauschbare Werkzeuge. In der Entwicklung war einmal ein MCP-Server für Brow­ser­au­to­ma­ti­sie­rung eingebunden, vom 17.11. bis zum 26.12.2025, dann flog er wieder raus.

Die Uhrzeit wirkt wie das langweiligste Werkzeug. Sie hat den schönsten Fehler produziert: Im Einsatz passten die Bahnzeiten nicht zur angesagten Uhrzeit, weil die Uhr der virtuellen Maschine unter den Containern abwich. Seitdem wird die Zeit ausdrücklich übergeben und überwacht.

Telefon. Zwei Richtungen, zwei Bauarten (Kapitel Über das Telefon):

• Eingehend ruft jemand eine Nummer an und spricht mit der KI. Der Anruf kommt beim Telefonieanbieter an und geht über ein eigenes Gateway weiter zum Realtime-Dienst, der seit August 2025 (externe Seite, openai.com) Anrufe über SIP (externe Seite, developers.openai.com) annimmt. Laut Projektdoku stellt der Anschluss beim Telefonieanbieter Anrufe nur an ein angemeldetes Gerät zu. Eine fremde SIP-Adresse kann er nicht direkt ansteuern. Der Realtime-Dienst wartet darauf, dass ihm ein Anbieter die Anrufe zuschickt. Das Gateway meldet sich deshalb wie ein Telefon beim Anbieter an und reicht jeden Anruf an den Realtime-Dienst weiter. Mit einem SIP-Trunk, der auf den Endpunkt von OpenAI zeigt, entfiele es. Diesen Weg beschreibt der Leitfaden von OpenAI (externe Seite, developers.openai.com).
• Ausgehend telefoniert der Kiosk-Browser über ein WebRTC-Softphone direkt mit dem Telefonieanbieter. Das Modell löst den Anruf per Sprachbefehl aus, während des Gesprächs pausiert die KI. Eingehende Anrufe klingeln an allen freigegebenen Kiosken, wer zuerst abnimmt, hat das Gespräch.

Die Telefonie war mit Abstand der aufwendigste Baustein. Bis der Ton in beide Richtungen durch die Adressumsetzung (NAT) kam, vergingen drei Tage und viele Builds.

Schutzregeln, Wörterbuch, Aussprache

Guardrails. Seit dem 27.12.2025 gibt es ein eigenes Regelwerk, das sich in der Admin-Oberfläche pflegen lässt (Kapitel Guardrails). Es ist bewusst regelbasiert: Wortlisten auf Deutsch und Englisch, Themensperren in fünf Bereichen, eine Positivliste für Fachbegriffe, damit Fachsprache nicht versehentlich gesperrt wird, und Muster gegen Jailbreaks in fünf Gruppen. Dazu eine Nutzungsgrenze pro Sitzung. Im System-Prompt steht zusätzlich, was nie erfunden werden darf, etwa Kontaktdaten und Ortsangaben, mit einer festen Ausweichantwort. Fremde Themen lenkt der Assistent höflich zurück.

Ein Regelwerk ist grob, und genau deshalb passt es hier: Es ist schnell, es kostet nichts pro Anfrage, und man kann nachlesen, warum etwas gesperrt wurde. Die Grenze ist ebenso klar. Wer umschreibt, kommt an einer Wortliste vorbei. Die Moderations-Schnittstelle des Anbieters steht in der Projektdoku als offener Punkt auf der Liste der Erweiterungen.

Wörterbuch. Fachbegriffe und Eigennamen sind die Schwachstelle jeder Spracherkennung. Der Concierge geht sie von zwei Seiten an:

• Vorher: Die wichtigsten Begriffe gehen der Transkription als Vokabularhinweis mit. Das Hinweisfenster des Anbieters ist auf 1024 Zeichen begrenzt, das zeigte am 23.03.2026 ein Hotfix. Seit dem 15.04.2026 steht eine Prioritätenliste am Anfang, damit die wichtigsten Namen immer hineinpassen.
• Nachher: Die Abschrift wird in drei Stufen korrigiert, exakt, dann unscharf über die Editierdistanz, dann phonetisch. Das Kor­rek­tur­wör­ter­buch entsteht automatisch aus den Begriffen der Wissensbasis. Eine Schutzliste mit rund 5.100 gängigen deutschen Wörtern verhindert, dass ein normales Wort zu einem Fachbegriff „korrigiert“ wird.

Aussprache. SSML verwendet der Concierge nicht. Stattdessen steht eine Liste mit einigen Dutzend Ausspracheregeln im System-Prompt, ergänzt um eigene Einträge aus dem Admin. Das klingt improvisiert und funktioniert erstaunlich gut, solange die Liste kurz bleibt.

Akustik: was die Halle anders macht

Alle Werte lasse ich hier bewusst weg. Die Prinzipien:

• Zwei Arten, das Satzende zu erkennen. Über Stille, oder „semantisch“: Dann schätzt ein eigenes Erkennungsmodell des Anbieters an den Wörtern, ob ein Satz zu Ende ist. Wählbar im Admin, mit getrennten Parametern für Kiosk und Telefon.
• Rausch­un­ter­drü­ckung beim Anbieter für Nahfeld oder Fernfeld, im Admin dazu „automatisch“ oder aus. Ein falsch platzierter Parameter ließ dabei einmal das ganze Sitzungsupdate scheitern. Damit fehlte der System-Prompt, und die Antworten wurden plötzlich lang und geschwätzig. Ein Fehler in der Konfiguration einer Sprachsitzung zeigt sich als veränderter Klang.
• Im Browser Echo- und Rausch­un­ter­drü­ckung, ein Rauschtor, das in Ruhe nur Signale oberhalb einer Schwelle durchlässt, und eine kurze Einschwingzeit nach dem Einschalten des Mikrofons. Ohne die lösten Ein­schalt­ge­räu­sche Halluzinationen aus.
• Ungeübte Sprecher machen Pausen mitten im Satz, und die stillebasierte Erkennung schneidet sie dort ab. Push-to-Talk wäre die Antwort darauf gewesen. Sie steht seit April im Code und ist im Standard aus.

Der Assistent wird für jeden Raum neu eingestellt, und diese Arbeit taucht in keinem Prototyp am Schreibtisch auf.

Stelen, Smartphones, Tablets: Geräte, Benutzer, Sitzungen

Das Hauptgerät war eine schlanke Stele: ein großer Touchmonitor im Hochformat, dahinter ein Notebook als Rechner, dazu Kamera und eine eigene Audiolösung aus Mikrofon und Lautsprechern, alles im Gehäuse verbaut. Auf diese Form ist die Oberfläche zugeschnitten, bedienbar im Stehen, mit großen Flächen für die Vorschlagskarten.

Mehrere Stelen laufen parallel. Jede hat ihre eigene Sitzung, ihr eigenes Gespräch und ihren eigenen Zustand, das Backend ist für alle dasselbe. Ein eingehender Anruf klingelt an allen freigegebenen Stelen, wer zuerst abnimmt, hat das Gespräch.

Smartphones und Tablets sind ausdrücklich vorgesehen, im Hoch- wie im Querformat, auch mehrere gleichzeitig. Die Oberfläche hat eigene Darstellungen für Kiosk und Smartphone, jeweils hoch und quer. Tablets laufen in der Kiosk-Darstellung. Dazu lässt sich der Concierge als App auf dem Startbildschirm installieren. Der Video-Avatar läuft auf allen Geräten, inklusive der Eigenheiten von Safari auf dem iPhone, die allein mehrere Pull Requests gekostet haben.

Dahinter steht ein Modell in drei Ebenen:

Die Ebenen greifen ineinander. Wird ein Benutzer gesperrt oder seine PIN geändert, enden alle seine Sitzungen auf allen Geräten. Die Geräteklasse entscheidet über Darstellung und Verhalten, etwa wie das Mikrofon startet. Und jede Sitzung erscheint im Admin mit Gerät und Benutzer, in der Gesprächsanalyse genauso wie in der Auswertung der Video-Sitzungen. Mehrere Organisationen in einer Installation kann der Concierge dagegen nicht; jede Umgebung ist eine Installation.

Entwicklung und Produktion

Gebaut wurde mit Claude Code direkt im Repository auf dem Mac mini, der auch die Container betreibt. Daneben laufen zwei vollständige Umgebungen, jede in einem eigenen Docker-Netz, mit eigenen Daten und einer eigenen Adresse über den Tunnel:

Eine Änderung nahm immer denselben Weg: in Claude Code entwickelt, als Pull Request durch die CI, gemergt, per Build-Skript nach DEV ausgeliefert, dort auf der Stele und am Smartphone ausprobiert. Erst danach ging sie nach PROD, und zwar nur auf ausdrückliche Anweisung. Das Build-Skript fragt dafür nach, und ein Hook in Claude Code verhindert, dass die KI selbst nach PROD ausliefert. Jeder Build bekommt automatisch eine Nummer, die sich am Kiosk abfragen lässt; so war auf jedem Gerät klar, welcher Stand gerade läuft.

Der Nutzen zeigte sich vor allem kurz vor den Einsätzen. In DEV durfte etwas kaputtgehen, während die Stelen auf PROD stabil liefen. Mehr zu den Grundlagen im Kapitel Wo Modelle betrieben werden.

Betrieb, Admin, Sicherheit

Admin-Oberfläche. Zwanzig Ansichten in Vue. Die wichtigsten: ein Editor für den System-Prompt mit Versionen, Verlauf und Vergleich; die Pflege der Wissensbasis mit Testabfrage, die zeigt, wie ein Treffer zu seiner Bewertung kam; die Gesprächsanalyse als Sprechblasen-Zeitleiste für Kiosk und Telefon; Schutzregeln, Werkzeuge, Modelle, Audio, Sprachen, Vorschlagskarten, Kiosk-Benutzer mit eigener PIN, verschlüsselte Geheimnisse. Die Konfiguration wuchs von 24 Schlüsseln in Version 0.5 auf rund 150. Jede Einstellung, die im Admin landet, ist eine, die man am Stand ändern kann, ohne neu zu bauen.

Logging. Ein zentrales Ereignisprotokoll in Tagesdateien, mit begrenzter, einstellbarer Aufbewahrung. Systemereignisse gehen auf Wunsch als Karte in einen Team-Kanal, über einen einzigen Haken im zentralen Logging statt über Änderungen an vielen Stellen. Ein Debug-Overlay zeigt Verbindung, Audio und Token-Verbrauch live. Was nach einem Gespräch übrig bleiben sollte und was nicht, behandelt das Kapitel Was nach dem Gespräch übrig bleibt.

Tests. Rund 1.860 Testfälle im Frontend, 910 im Backend, dazu Browser-Tests. Fünf CI-Abläufe, einer davon ein automatisches KI-Review nach jedem Merge. Ein Grundsatz steht als Regel im Repository: Tests werden nie angepasst, damit ein Build grün wird, und Schwellen werden nie gesenkt.

Sicherheit, nur als Liste dessen, was bedacht wurde: Geheimnisse liegen verschlüsselt im Backend, das Frontend kennt keine Schlüssel. Verbindungen sind geschützt und an Herkunft und Sitzung gebunden. Content Security Policy, Prüfsummen für eingebundene Skripte, sichere Cookies. Eingaben werden geprüft und in der Größe begrenzt, Webhooks sind signiert. Container laufen ohne Admi­nis­tra­tor­rechte.

Vor dem ersten Einsatz stand ein Audit, und die Methode ist erzählenswert: Drei KI-Agenten haben parallel und unabhängig voneinander nach Schwachstellen gesucht, jeder mit eigenem Blickwinkel. Das Ergebnis waren 21 Befunde in vier Schweregraden, alle behoben, danach bestand ein automatisierter Angriffstest in der Ent­wick­lungs­um­ge­bung alle 24 Prüfungen. Einen professionellen Penetrationstest ersetzt das nicht. Es ist aber eine Prüfung, die ein einzelner Entwickler am Wochenende überhaupt durchführen kann, und sie hat Dinge gefunden.

Gebaut mit Claude Code

Bis hierhin ging es um das, was gebaut wurde. Jetzt um das Wie, und das war für mich der eigentliche Grund für das Projekt: herausfinden, wie weit man in der Freizeit mit einem Coding-Agenten kommt, an einem Vorhaben, das sonst ein Team aus mehreren Fachleuten bräuchte. Angefangen hat es als Vibe Coding. Ab Dezember lief es über Pull Requests, CI und Reviews, also als Agentic Engineering: Fehlbare Agenten werden geführt, und jemand steht für das Ergebnis gerade.

Fast jede Zeile im Repository ist mit Claude Code entstanden. Schon im ersten Commit stehen eine CLAUDE.md und der Hinweis „Co-Authored-By: Claude“. Das Werkzeug war zu dem Zeitpunkt gut einen Monat in der Fassung 2.0 auf dem Markt, veröffentlicht am 29.09.2025 (externe Seite, anthropic.com) mit Checkpoints und Sonnet 4.5 als Standardmodell. Subagenten und Hooks gab es seit dem Sommer 2025.

Wer mitgeschrieben hat

Claude Code schreibt in jeden Commit, welches Modell beteiligt war. Bis Mitte Januar steht dort nur „Claude“ ohne Fassung, danach der genaue Name. Gezählt über den Hauptzweig:

Ein Commit kann mehrere Einträge haben, deshalb gehen die Zeilen nicht genau auf. Dazu kommt ein einzelner Commit mit Haiku 4.5 vom 01.03.2026. Was hinter „Claude“ ohne Fassung steckte, sagt das Repository nicht; laut Projektdoku vor allem Sonnet 4.5 und Opus 4.5.

seitlich verschiebbar

eigene Auswertung der Git-Historie, gezählt am 03.10.2026

Die Modellwechsel liegen dicht an den Ver­öf­fent­li­chungen: Opus 4.5 (externe Seite, anthropic.com) erschien am 24.11.2025 und taucht ab Mitte Januar im Repository auf. Opus 4.6 (externe Seite, anthropic.com) erschien am 05.02.2026 und ist am selben Tag im ersten Commit. Die Fassung mit einer Million Token Kontext steht ab dem 14.03.2026 in den Commits, Opus 4.7 (externe Seite, anthropic.com) ab dem 17.04.2026, einen Tag nach der Veröffentlichung. Welche Modelle es sonst gab und wie man deren Karten liest, steht in den Modellkarten und im Kapitel Die Systemkarte lesen.

Wie es sich angefühlt hat

Einen einzelnen Moment, an dem alles anders war, gab es nicht. Es war eher ein Grundrauschen: Mit jedem neuen Modell und jeder neuen Fassung von Claude Code ging etwas, das ein paar Wochen vorher noch Nacharbeit gekostet hatte. Die Projektdoku hält zwei Schritte fest: Mit Opus 4.5 gelangen verlässliche Umbauten großer Teile des Codes. Mit Opus 4.6 passte durch das Fenster von einer Million Token der ganze Concierge in eine Sitzung, samt Frontend, Backend, Tests und Doku. Man konnte die Geschwindigkeit der Entwicklung beim Arbeiten spüren. Das Kapitel Geschwindigkeit der Entwicklung ordnet das größer ein.

Das ist eine Beobachtung, gemessen habe ich es nicht. Ein Projekt, das wächst, wird mit der Zeit schwieriger, und ich wurde mit der Zeit besser. Was davon das Modell war, lässt sich nachträglich nicht trennen.

Commits pro Woche

Der Rhythmus der Commits erzählt die Projektgeschichte:

• Weihnachtswoche 2025: 136 Commits, der Spitzenwert. In einer Woche kamen Logging, Update-System, Schutzregeln, Design-Tokens, Bahnabfahrten und die Installation als App dazu. Das ist die Woche, in der Freizeit am meisten Freizeit war.
• Mitte Januar: 5 Commits. Pause.
• Ende Januar: 99 Commits, mit der Telefonie und einer großen Aufräumrunde.
• März: zweiter Anstieg, die Stabilisierung vor dem Ersteinsatz auf der Hausmesse.
• Anfang April: eine Woche ohne einen Commit, die Pause nach dem ersten Einsatz.
• Mitte April: Vorbereitung auf die DMEA. Für den zweiten Einsatz habe ich den Kontext getauscht: Wissensbasis und Vorschlagskarten neu aufgebaut und ein paar Verbesserungen am Code vorgenommen.

Am deutlichsten zeigt den Wechsel das Verhältnis von Fehlerbehebungen zu neuen Funktionen, gezählt an den Präfixen der Commit-Betreffe:

Im März kamen auf jede neue Funktion fast sieben Fehlerbehebungen. So sieht eine Phase aus, in der nichts Neues mehr dazukommen durfte. Die Regel dazu stand ab dem 15.03. im Repository: Stabilität schlägt Features.

Die Arbeitsweise wird strenger

Der vielleicht wichtigste Befund des ganzen Projekts steht in .claude/: Die Regeln für die KI hat sich das Projekt selbst geschrieben, eine Panne nach der anderen. Die Kapitel Der Init, Hooks und Skills und Der Harness erklären die Bausteine.

Die CLAUDE.md wuchs also zweimal auf und wurde zweimal zusam­men­ge­stri­chen. Und die Arbeitsweise wurde Schritt für Schritt strenger: direkte Commits, dann Pull Requests, dann ein gesperrter Hauptzweig, dann ein Pflicht-Review, dann ein Review, das die Maschine erzwingt. Die Projektdoku teilt den eigenen Verlauf in drei Phasen: „Vibe Coding“, „Strukturierung“ und „Agentic Engineering“.

Codex lief zeitweise daneben, über OpenClaw auf dem Ent­wick­lungs­server; Spuren davon gibt es in einer AGENTS.md und in einem Wächter, der hängengebliebene Codex-Prozesse aufräumt. ChatGPT und Gemini nennt die README als weitere Assistenten. Der Code selbst ist Claude Code.

Die Pannen, aus denen Regeln wurden

Die schwersten Fehler lagen im Timing zwischen Browser, Backend und Modellanbieter, selten in einer einzelnen Funktion. Drei Beispiele:

• Build 161 (16.03.2026): Ein Puffer wurde zum falschen Zeitpunkt geleert, danach scheiterte jede Spracheingabe. Der Review-Agent hatte den Fehler nicht bemerkt, weil er Code las. Der Fehler lag in der Abfolge von Ereignissen. Build 162 nahm es zurück, und seitdem gehört ein Timing-Diagramm zu jedem Review an diesen Stellen.
• Geisterantworten (14.03.2026): Ein kurzes Einschalten des Mikrofons während der Ausgabe löste neue Antworten aus. Die Sprecherkennung des Anbieters ist nicht deterministisch, und das muss man einplanen, statt es zu hoffen.
• Builds 183 bis 193 (17.03.2026): Aufgeschobene Aktionen liefen parallel, es entstanden Wettläufe. Die Lehre: als Gesamtsystem planen statt Fix an Fix zu hängen. Am Ende stand eine einzige Zustandsmaschine als Wahrheitsquelle.

Aus jeder dieser Pannen wurde eine Regel, ein Hook oder ein Eintrag im Erfahrungsbuch des Projekts. Mehr zu diesem Muster in Erst der rote Test und ADR und Spezifikation.

Was ich mitnehme

Ein Mensch kann das in seiner Freizeit bauen. Backend, Frontend, Admin-Oberfläche, Telefonie, Tests, Doku, Betrieb: Für so etwas bräuchte man klassisch mehrere Leute. Hier waren es Abende und Wochenenden über fünfeinhalb Monate. Für jedes Projekt gilt das nicht. Es zeigt aber, wie weit sich die Grenze verschoben hat.

Die Halle ist der eigentliche Test. Barge-in, Satzende, Rauschen, Echo, Uhrzeit: Was im Einsatz zählt, fällt am Schreibtisch nicht auf.

Jedes Modell braucht einen Grund. Die abgeschaltete LLM-Korrektur und die Vorschlagskarten, die einmal beim Bauen entstanden und im Betrieb feststehen, sind bewusste Entscheidungen gegen ein weiteres Modell an der falschen Stelle.

Was wichtig ist, muss die Maschine erzwingen. Eine Regel im Prompt ist eine Bitte. Ein Hook, ein gesperrter Zweig, ein CI-Lauf, der bei übersprungenen Tests abbricht, sind Sperren. Das ist für mich die übertragbare Lehre, und sie gilt für jedes Projekt mit KI-Werkzeugen.

Und ein Tagebuch von Anfang an. Es begann hier erst nach einigen Wochen, und die frühen Erfahrungen fehlen jetzt in diesem Bericht.