Dieser Erfahrungsbericht ist anonymisiert. Er beschreibt eine kleine Lösung des Alltags: Wie man mit einem KI-Agenten an einem Arbeitsplatz beginnt und die laufende Unterhaltung auf dem Mobilgerät — und wieder zurück — fortsetzt, ohne den Faden zu verlieren.

Die Ausgangslage kennt jeder, der mit einem Agenten arbeitet: Man startet die Sitzung am festen Platz, muss aber das Haus verlassen. Entweder man bricht ab und verliert den aufgebauten Kontext — oder man versucht, „irgendwie" weiterzumachen. Beides ist unbefriedigend.

Der Denkfehler: Die Sitzung „im Browser"

Die naheliegende Annahme lautet: Die Unterhaltung gehört zum Browser-Fenster. Wer sie auf einem anderen Gerät braucht, müsste sie kopieren, exportieren, importieren. Genau das ist der Denkfehler.

Bei einem Agenten mit Server-Architektur lebt die Sitzung serverseitig — im Server-Prozess und dessen Datenablage. Der Browser ist nur ein Client, der dieselbe Sitzung anzeigt. Es gibt nichts zu übertragen: Man muss lediglich denselben Server ansprechen und dieselbe Sitzung adressieren.

Lektion 1: „Handover" heißt hier nicht Daten umziehen, sondern den Client wechseln. Ein Server, viele Anzeigen.

Der Link ist die Brücke

Eine Weboberfläche adressiert eine Sitzung über ihren Pfad. Entscheidend ist, dass dieser Link stabil konstruierbar ist, statt aus einer Zwischenablage zu stammen. Bei einer Single-Page-Anwendung besteht er typischerweise aus zwei Teilen:

<server-basis>/<verzeichnis-schluessel>/session/<sitzungs-id>

verzeichnis-schluessel = URL-sichere Base64-Kodierung des Arbeitsverzeichnisses
sitzungs-id            = die eindeutige ID der Unterhaltung

Wer diese zwei Werte kennt, kann den Link berechnen — statt ihn zu suchen. Ein kleines Skript genügt: Es fragt den Server nach der jüngsten (oder einer benannten) Sitzung, bildet die URL und legt sie in mehreren Formen ab.

Handover-<Zeitstempel>.url   → Desktop-Verknüpfung (Linux/Windows)
Handover-<Zeitstempel>.txt   → reine URL als Rückfall (Notizen, Terminal)
Handover-<Zeitstempel>.png   → QR-Code zum Scannen auf dem Mobilgerät

Der QR-Code ist der eigentliche Trick für die Übergabe an das Telefon: kein Tippen, kein Copy-Paste, nur scannen. Zeitstempel im Dateinamen machen aus einer flüchtigen URL ein nachvollziehbares, versioniertes Artefakt — dieselbe Haltung wie überall sonst in diesem Projekt.

Öffnen auf dem Smartphone: Die erzeugte PNG-Datei des Handovers lässt sich direkt auf dem Telefon antippen und mit Google Fotos öffnen. Der in der Grafik enthaltene QR-Code wird erkannt und die generierte Adresse kann anschließend im Browser direkt aufgerufen werden — ganz ohne Abtippen des Links.

Lektion 2: Ein Link, der aus dem Server abgeleitet statt aus der Zwischenablage kopiert wird, ist reproduzierbar — und ein QR-Code macht ihn zum mobilen Übergabe-Werkzeug.

Die eigentliche Regel: eine Instanz, viele Clients

Der scheinbar bequeme Weg — auf jedem Gerät einen eigenen Agenten-Server starten — ist der gefährliche. Werden die Laufzeitdaten geteilt (eine gemeinsame Datenbank), dürfen niemals zwei Instanzen gleichzeitig schreiben. Zwei Schreiber auf dieselbe Datenbank riskieren deren Beschädigung; ein Datei-Locking über Netzwerkfreigaben schützt dabei nicht zuverlässig.

Die korrekte Konfiguration ist daher unspektakulär: genau ein laufender Server, und so viele Browser-Clients, wie man möchte. Handover wird so zu einer reinen Anzeige-Frage — und das Risiko verschwindet, weil es gar keinen zweiten Schreiber gibt.

Lektion 3: „Session-Handover" ist ein Client-Problem, kein Server-Problem. Eine zweite Instanz „für das andere Gerät" ist keine Lösung, sondern das Risiko.

Was das für die Praxis bedeutet

• Erst verstehen, wo der Zustand liegt. Browser lokal, Server zentral. Wer das verwechselt, baut Export/Import, wo ein Link genügt.
• Kleine Werkzeuge statt großer Mechanik. Ein Skript von wenigen Dutzend Zeilen löst ein wiederkehrendes Alltagsproblem vollständig.
• Übergabe für den Menschen denken. QR-Code und Datei-Endungen (.url/.txt) sind keine Technikdetails — sie entscheiden, ob die Übergabe in der Praxis wirklich gelingt.

Dieser Bericht ist anonymisiert. Er ist Teil der Reihe Erfahrungen & Lessons Learned.