Temporal UX: Warum Wartezeit bei KI-Agenten ein Designproblem ist

Am Flughafen gibt es ein bekanntes Beispiel für gestaltete Zeit. Wird der Fußweg zum Gepäckband bewusst verlängert, empfinden Reisende die Wartezeit als kürzer, obwohl sie gleich lang oder länger ist. Die Wartezeit wurde nicht verkürzt, sondern gefüllt.

Genau dieses Prinzip fehlt in der Arbeit mit KI-Agenten fast vollständig. Unter dem Namen Temporal UX kursiert es in der Service-Design-Welt seit einiger Zeit, im KI-Kontext ist es kaum durchdacht.

Der Ausgangsfall

Der Anlass ist eine eigene Erfahrung. Bei gemeinsamem Vibe Coding wurde eine Aufgabe an einen Agenten übergeben, umgesetzt mit Craft Agents auf Basis eines Opus-Modells. Die übrigen Beteiligten bekamen währenddessen nur sporadische Zwischenstände aus zweiter Hand.

Das Ergebnis war eine Sechs-Punkte-Liste, die abgearbeitet wurde. In der Wirkung ähnelt das einem Installationsbalken, der bei 98 Prozent steht: Es gibt Fortschritt zu sehen, und trotzdem weiß niemand, wie lange es noch dauert.

Die Analogien in der Folge sind alle älter als KI und beschreiben dasselbe Problem: Diskettenwechsel, Ladebildschirme mit versteckten Scherzen in alten Videospielen, Pong-Minispiele auf Flash-Webseiten. Lauter frühe Lösungen dafür, Wartezeit erträglich zu machen, ohne über ihre Dauer zu lügen.

Warum Modelle ihren Denkprozess zeigen

Ein zentraler Strang betrifft Vertrauen. Reasoning-Modelle blenden ihren Gedankengang ein, und die naheliegende Erklärung lautet Transparenz.

Die zweite Erklärung ist mindestens so wichtig: Sichtbarer Fortschritt hält Menschen bei der Sache. Wer sieht, dass etwas passiert, wartet länger und misstraut dem Ergebnis weniger. Das ist keine Manipulation, solange die angezeigten Schritte tatsächlich stattfinden. Es ist aber eine Gestaltungsentscheidung, keine technische Notwendigkeit.

Beachten Sie die Kehrseite. Ein sichtbarer Denkprozess bindet Aufmerksamkeit. Wer beim Zuschauen bleibt, gewinnt keine Zeit. Der eigentliche Nutzen entsteht erst, wenn man den Agenten arbeiten lassen und etwas anderes tun kann, und dafür braucht es eine verlässliche Benachrichtigung statt eines fesselnden Bildschirms.

Das Problem mit mehreren Agenten

Ab einer bestimmten Zahl paralleler Agenten kippt der Nutzen. In der Folge liegt die Grenze bei fünf bis sechs: Danach steigt die Fehlerquote deutlich, weil der Überblick verloren geht, wer gerade woran arbeitet und wo ein Prompt oder ein Prüfschritt fehlt.

Das ist keine Frage der Rechenleistung, sondern der menschlichen Verwaltungslast. Jeder laufende Agent belegt einen Platz im Arbeitsgedächtnis, und dieser Platz ist begrenzt.

Als Wunschbild bringt die Folge eine alte Palm-Pilot-Anwendung namens Agendus ein: Aufgaben, die mit einem mitwandern, bis sie erledigt sind, dazu ein einfaches Abschlussprotokoll und die Fähigkeit, Kontexte aus verschiedenen Unterhaltungen zusammenzuführen. Das ist keine Nostalgie, sondern eine präzise Anforderungsbeschreibung, die heutige Agenten-Werkzeuge nicht erfüllen.

Modelle haben kein Zeitgefühl

Der praktisch folgenreichste Befund ist zugleich der am leichtesten zu übersehende. Aktuelle Modelle haben kein Gefühl für verstrichene Zeit. Wer nicht ausdrücklich Datum und Uhrzeit im Prompt mitgibt, bekommt Aussagen wie „ich habe zwei Stunden recherchiert“, während real zwei Minuten vergangen sind.

Für Berichte, Protokolle und alles, was Zeitangaben enthält, heißt das: Geben Sie Zeitstempel explizit mit und lassen Sie Dauern nicht vom Modell schätzen.

Wie konkret das wird, zeigt eine Anekdote aus der Folge: Ein Timeout im Frontend hat die fertige Antwort eines n8n-Workflows verschluckt. Die Arbeit war getan, das Ergebnis war da, und es kam nie an. Das ist kein Modellproblem und kein Automatisierungsproblem, sondern ein Zeitgestaltungsproblem.

Fazit

Zeitgestaltung darf nicht dem Zufall überlassen bleiben. Sie gehört auf zwei Ebenen bewusst mitgedacht: in der Oberfläche und in der Organisation, also in Workflows, Benachrichtigungen und Übergabepunkten.

Für die eigene Umgebung ergeben sich drei praktische Schritte. Geben Sie Modellen Datum und Uhrzeit mit, statt Zeitangaben zu glauben. Begrenzen Sie die Zahl gleichzeitig laufender Agenten auf das, was Sie überblicken können, eher vier als acht. Und sorgen Sie dafür, dass ein fertiges Ergebnis Sie erreicht, auch wenn Sie zwischenzeitlich etwas anderes getan haben.

Andernfalls entsteht der paradoxe Zustand, den die Folge beschreibt: Die Maschine arbeitet schneller, und die Gesamtleistung sinkt, weil die Verwaltung der Wartezeit mehr kostet als die eingesparte Arbeit.

Zum Schluss passt ein Satz von Benjamin Franklin, mit dem die Folge endet: Lost time is never found again.