Temporal UX: why waiting time with AI agents is a design problem

Airports offer a well-known example of designed time. If the walk to the baggage belt is deliberately lengthened, travellers experience the waiting time as shorter, although it is the same length or longer. The waiting time was not shortened but filled.

Precisely this principle is almost entirely missing in work with AI agents. Under the name temporal UX it has been circulating in the service design world for some time; in the AI context it is barely thought through.

The starting case

The occasion is an experience of their own. During joint vibe coding, a task was handed to an agent, implemented with Craft Agents on the basis of an Opus model. The other participants received only sporadic second-hand updates in the meantime.

The result was a six-point list being worked through. In effect that resembles an installation bar stuck at 98 per cent: there is progress to see, and nobody knows how much longer it will take.

The analogies in the episode are all older than AI and describe the same problem: swapping floppy disks, loading screens with hidden jokes in old video games, Pong mini-games on Flash websites. All early solutions for making waiting time bearable without lying about its length.

Why models show their thinking process

One central strand concerns trust. Reasoning models display their train of thought, and the obvious explanation is transparency.

The second explanation is at least as important: visible progress keeps people engaged. Anyone who sees that something is happening waits longer and mistrusts the result less. That is not manipulation, as long as the steps displayed actually take place. It is, however, a design decision, not a technical necessity.

Note the flip side. A visible thinking process binds attention. Anyone who stays and watches gains no time. The actual benefit only arises when you can let the agent work and do something else, and for that it takes a reliable notification instead of a captivating screen.

The problem with several agents

Beyond a certain number of parallel agents, the benefit tips over. In the episode the limit sits at five to six: after that the error rate rises noticeably, because you lose track of who is working on what and where a prompt or a checking step is missing.

That is not a question of compute but of human management load. Every running agent occupies a slot in working memory, and that slot is limited.

As a picture of what is wanted, the episode brings in an old Palm Pilot application called Agendus: tasks that travel with you until they are done, plus a simple wrap-up and the ability to merge contexts from different conversations. That is not nostalgia but a precise requirements description that today's agent tools do not meet.

Models have no sense of time

The finding with the greatest practical consequences is also the easiest to overlook. Current models have no sense of elapsed time. Anyone not explicitly supplying the date and time in the prompt gets statements such as “I researched for two hours” while two minutes have actually passed.

For reports, minutes and anything containing time references that means: supply timestamps explicitly and do not have the model estimate durations.

How concrete that gets is shown by an anecdote from the episode: a timeout in the frontend swallowed the finished answer of an n8n workflow. The work was done, the result was there, and it never arrived. That is not a model problem and not an automation problem but a time design problem.

Conclusion

Time design must not be left to chance. It belongs deliberately considered on two levels: in the interface and in the organisation, that is in workflows, notifications and handover points.

Three practical steps follow for your own environment. Supply models with the date and time instead of believing time statements. Limit the number of agents running simultaneously to what you can keep track of, four rather than eight. And make sure a finished result reaches you even if you have done something else in the meantime.

Otherwise the paradoxical state the episode describes arises: the machine works faster, and overall performance falls, because managing the waiting time costs more than the work saved.

A sentence from Benjamin Franklin fits at the end, with which the episode closes: lost time is never found again.