Editorial Note: As AI systems move from instant responses to longer-running autonomous tasks, the challenge is no longer only about what AI can do, but how humans interact with AI while work is happening. This article explores how AI interface design may need to evolve around attention, trust, and asynchronous collaboration.
You’re Not Bad at Waiting: AI Tools Need to Be Redesigned Around Human Attention
You ask an AI to draft a competitive analysis. It should take about three minutes. You unlock your phone — just a quick glance. When you look up, eight minutes have passed. You’ve scrolled through a dozen TikToks. The report finished generating in minute two, sitting quietly in a tab you minimized and forgot about.
Different scene. You hand off a legacy code refactor to a coding agent. You grab coffee. Fifteen minutes later, it’s been busy the entire time: fixing function A triggered a type error, fixing the type error required changing interface B, changing interface B broke caller C. Every step was locally reasonable. But you can tell at a glance that the very first assumption was wrong — it treated an architectural problem as a syntax problem. Like an intern working desperately hard with no one to course-correct. More effort, more drift.
These look like two different failures. One is about human attention; the other is about AI reliability. But they share a single structural cause: every AI interaction model today assumes the human should be synchronously present while the AI works. You send a prompt. You stare at a screen. You wait for output. This metaphor comes from the search era — request to response in 200 milliseconds. Of course you can wait for that. But when an agent task takes three minutes, thirty minutes, or three hours, the synchronous-waiting mental model breaks down completely.
What happens when it breaks? Humans don’t know how to occupy themselves. AI doesn’t know how to manage human attention or trust. Both sides are applying an old paradigm to a new reality, producing the attention slip in scene one and the silent derailment in scene two.
This article decomposes that “don’t know how to occupy” into five concrete dimensions. For each, I’ll examine why it’s hard, what design responses exist, and where the reasoning gets tricky. There are no standard answers here — this field is too new for that. But the derivation matters more than the destination.
Dimension 1: The Cognitive Trap Zone — Why AI Wait Time Is Unlike Any Other Wait
Let’s define the problem precisely.
Daily life is full of waiting: elevators, coffee, compiles, deployments. These waits share three properties. They’re transparent (you can see progress). They’re predictable (you know roughly how long). They require no decisions (nothing is asked of you while you wait).
AI task waiting violates all three.
Opaque. You don’t know what the AI is “thinking.” An LLM generating text and an agent executing a multi-step plan may look identical on screen: a spinning icon. You can’t distinguish efficient progress from silent looping, critical decision-making from meaningless repetition. Waiting becomes blind.
Unpredictable. “About three minutes” is a guess, not a commitment. Agent runtime depends on inference speed, tool-call count, retry loops, context window compression. The same task might take two minutes once and eight minutes the next time. You can’t plan “I’ll do something else while it runs” because you don’t know how much time “something else” has.
Decision-laden. This is the crucial difference. Waiting for an elevator requires zero judgment. Waiting for AI requires continuous background monitoring: Is it doing the right thing? Has it drifted? Should I interrupt? Do I need to add constraints? Cognitive science provides useful concepts for describing this state: reduced active engagement combined with continued monitoring demands. Your brain can’t fully relax (you might need to intervene at any moment), but it also can’t deeply engage in another task (you need to maintain peripheral awareness of the AI’s state).
This is the exact definition of the cognitive trap zone: the 30-second-to-5-minute window of AI wait time that is too long to sustain focused waiting (your attention naturally diffuses), too short to start a new deep task (you may need to return at any moment), and simultaneously demands a low-quality background monitoring posture. In this window, cognition is suspended between rest and work — neither truly resting nor truly working.
Why does it suspend? When you delegate a cognitively demanding task to an external system, your brain shifts from prefrontal-driven active execution mode to passive monitoring mode. Active mode has high cognitive load but focused, directed attention. Passive mode has low cognitive load but diffuse, undirected attention. The switch is instantaneous, but re-focusing attention takes time. The moment a task goes from “I’m doing it” to “AI is doing it,” your attention loses its anchor. When attention loses a clear task anchor, people often shift toward easily available sources of stimulation. Your phone — unlocked, offering high-feedback, low-friction short video — is the path of least resistance.
There’s an amplifying factor: psychological permission. “AI is working for me” generates a subconscious signal that resting now is justified. This isn’t laziness; it’s normal cognitive resource management. The system judges that no active investment is currently required and lowers arousal to conserve energy. But “lowering arousal” and “scrolling TikTok for eight minutes” are fundamentally different activities. The former is recovery; the latter may leave people feeling less recovered than intentional rest. In that unanchored moment, the distinction blurs.
One counterintuitive observation: the smarter the agent, the wider the trap zone. Traditional search is synchronous — 200ms response, no waiting problem. Early AI chat was also synchronous, seconds to low tens of seconds. But when AI evolves from “answering questions” to “executing tasks” — writing code, conducting research, running multi-step workflows — task duration jumps from seconds to minutes or hours. Intelligence doesn’t eliminate fragmented time. It manufactures a new, more insidious form of it: you think you’re “waiting for AI to work,” but you’re actually being hijacked by AI-generated idle time.
In programming terms: traditional search is a synchronous call, request → response, blocking but negligible. Agents are asynchronous tasks — the caller should submit and release itself to do other work. But current UI design still presents async tasks with a sync-era mental model: a spinner, a “thinking…” label, as if the user should stand by. This is a paradigm mismatch.
Since the trap zone is structural and can’t be solved by “reminding users to stop scrolling” (that’s fighting neurology, and neurology wins), the redesign has to happen at the interface and interaction level.
Dimension 2: What the Waiting Screen Should Show — From “Pretending to Work” to “Allowing You to Be Absent”
This problem is harder than it looks.
The intuitive solution: show the user what the AI is doing. Expose the reasoning trace, tool-call logs, intermediate steps. Many products do this. But there’s a fundamental issue: it makes the cognitive burden of passive monitoring explicit. Users see scrolling logs and feel they should watch, understand, catch errors. Attention that was already unanchored is now pinned to an information stream it can’t actually process. The result isn’t reassurance — it’s deeper anxiety.
What about showing nothing? Pure black screen, static icon? Also no. Total information vacuum triggers a different anxiety: “Is it stuck? Crashed? Should I refresh?” Humans often prefer bad news to uncertainty. An interface that says “still running, estimated two more minutes” is more calming than one that says nothing — even if “two minutes” is a guess.
So the question isn’t “how much information to show.” It’s what kind of information to show.
After working through this, I believe the answer has three layers, each solving a different problem.
Layer 1: Default state — resolving “is it still running?” anxiety.
This layer’s goal isn’t to convey information. It’s to convey presence. Slow, non-repetitive, low-saturation motion — not a spinner (which implies “almost done,” creating false expectations), not a progress bar (which implies quantifiable tracking, but AI task progress is inherently unquantifiable). Instead: a breathing rhythm, a visual pulse that points to no specific milestone. It communicates: the system is running, everything is fine, you don’t need to do anything.
A subtle design judgment here: this visual shouldn’t attract attention, but should be perceivable in peripheral vision. Too quiet (completely static) and users suspect a crash. Too active (rapid flicker) and users get pulled into staring. The ideal: you don’t need to look at it, but if you glance, you know it’s alive. Emerging experiments with ambient agent interfaces explore a similar direction by mapping runtime states to low-attention visual signals. It encodes “system is running” into a visual signal that requires zero cognitive processing. No text to read; a peripheral glance suffices. This direction is right.
Layer 2: Optional thinking anchors — resolving “where does attention go?”
Alongside the quiet default state, provide an unobtrusive entry point (a small icon, faint text) that expands into a micro-reflection prompt related to the current task.
The key judgment: prompts must be open-ended, require no external lookup, and relate directly to the current task. “Who are you most trying to persuade with this analysis?” “What edge case are you most worried the AI might miss?” These questions don’t require opening another tab or intensive thought, but they gently anchor the brain in the work context.
By contrast, “Want to see related industry reports?” or “Three articles you might like” look helpful but are information-feed traps in disguise — they push users from “low-intensity but directed waiting” into “high-intensity but undirected browsing.” The test is simple: good anchors keep users inside the task’s semantic field; bad anchors push them out of it.
One more detail: the anchor must be ignorable without penalty. If users don’t want to engage, it shouldn’t pressure them — no pop-ups, no flashing, no “you haven’t viewed this yet” indicators. Its presence should be “here when you need it,” not “here so you should look.”
Layer 3: Timeout and anomaly handling — resolving “did something go wrong?” fear.
If a task takes significantly longer than expected, don’t flash a red alert. Escalate presence gradually: first, subtly shift Layer 1’s motion (slower rhythm, slightly warmer tone). Then, a small text line: “Taking a bit longer than expected; still processing.” Only when user decision is genuinely needed do you offer “continue waiting” or “cancel.”
The logic behind gradual escalation: most “timeouts” aren’t true anomalies — they’re just slower than expected. If every minor delay triggers a strong alert, users develop conditioned anxiety and start compulsively checking whenever AI is running. Gradual escalation protects the default expectation that “most of the time, you don’t need to worry,” reserving strong signals for genuine intervention points.
Dimension 3: From “Waiting” to “Walking Away” — The Async Workflow Paradigm Shift
Every design discussed above shares an implicit premise: the user is still in front of the screen. But the deeper question is: why should they be?
Return to the prototype of human collaboration. You hand a report brief to a colleague. You don’t stand at their desk watching them type. You go do your own work; they deliver when ready, via email or message. Collaboration is asynchronous. Trust is built through deliverable quality, not process visibility.
AI collaboration may need to move closer to this asynchronous pattern, while adapting for the limitations of current systems. But nearly all current products are synchronous: input prompt → wait for output → read output → decide next step. Strictly serial, requiring continuous human presence.
Breaking this serial structure requires changes at multiple levels.
Change 1: Batch processing. Don’t handle tasks one at a time. Encourage users to submit batches. AI processes in parallel; results arrive in a unified inbox. This shifts the interaction model from “conversation” to “delegation.” Conversation requires both parties online simultaneously; delegation only requires deliverables. Programming analogy: from single-threaded blocking calls to a task queue with async callbacks.
Design challenge: batch processing requires sufficient upfront context, since there’s no mid-task interaction. In synchronous dialogue, you can say “no, that’s not what I meant” and the AI corrects course. In async delegation, unclear initial instructions mean the AI proceeds on its own interpretation, and you discover the drift only upon delivery. So batch processing requires better task-description interfaces — not bigger text boxes, but structured input flows that guide users to articulate key constraints upfront.
Change 2: AI-initiated orchestration. Going further, AI doesn’t just passively receive and parallelize tasks — it actively plans execution order. “You have three reports, two code reviews, and one proposal. Reports are independent; I’ll parallelize those. Code reviews have dependencies; I’ll start with the first. Your current attention state suits deep review — spend forty minutes on code first, and I’ll have the reports ready before you finish.” In a more mature future model, AI shifts from executor to scheduler, from tool to coordinator.
Prerequisite: AI needs to know the user’s current state and available time. This means sensing “is the user busy right now,” “does the user have meetings in the next hour,” “what’s the user’s typical attention cycle length.” Most current AI products have limited access to this dimension, especially around real-time attention context. But true async collaboration requires closing this gap.
Change 3: Delegate-and-report mode. The ultimate form: spend twenty minutes each morning briefing tasks, spend the day on work requiring genuine human judgment and creativity, receive a structured end-of-day report — what completed, what hit blockers needing decisions, what was deferred and why. Humans shift from operators to decision-makers, from watching AI work to reviewing AI’s output.
Honest caveat: this ultimate form isn’t achievable yet. Not because of technical limits, but because of trust. Would you delegate eight hours of work to a system you can’t monitor in real time? That depends on two conditions: transparency (can you retrospectively audit what it did and why) and fault tolerance (if it errs, is the damage contained and reversible)? Current agents aren’t mature enough on either dimension. But the direction is settled; the question is “when,” not “whether.”
And “walking away” itself has an overlooked prerequisite: you must believe things are progressing normally in your absence. If AI pauses when the window loses focus (some browsers and OSes throttle background processes), or silently stalls at some step awaiting input, then “walking away” becomes another form of waiting — just polling instead of staring. That’s not true asynchrony; it’s anxiety-driven polling.
Which leads to the next dimension.
Dimension 4: Silent Agent Failure — Why “Looks Like It’s Working” Is More Dangerous Than “Clearly Broken”
Back to opening scene two. Fifteen minutes of agent work, every step locally reasonable, overall direction wrong. This deserves careful unpacking because it reveals a deep cognitive asymmetry.
For the AI, every step is “the optimal next step.” It reasons within local scope: this type error needs fixing, the fix requires changing the interface, the interface change requires updating callers. Each step is individually valid. But a sequence of local optima doesn’t equal a globally correct path. This reflects a current limitation in how many agent systems are designed: agents often excel at advancing within a given frame but struggle to question the frame itself.
For experienced humans, the problem is visible at step one. “This isn’t a syntax problem; it’s an architecture problem” — this judgment requires whole-system understanding, not analysis of the current step. A five-second human insight may take the AI fifteen minutes to vaguely sense (or never sense at all).
This asymmetry means: users need mechanisms to course-correct while the agent still “looks like it’s working normally,” rather than discovering misdirection after twenty minutes of wasted compute.
But “intervention” is easy to say and hard to design. Why?
Detection is hard. How do you judge whether an agent is “making meaningful progress”? In code: if N consecutive steps modify the same file without tests turning green, it’s likely spinning. In writing: if semantic similarity across consecutive generations keeps rising (rephrasing the same idea), it’s likely treading water. But these heuristics have false-positive risk — sometimes repeated file edits are legitimate iteration; sometimes high semantic similarity is polishing.
Harder still: directional errors that no rule can detect. The agent isn’t spinning. Every step advances. Tests pass. But it’s solving the wrong problem. Only humans can catch this, and catching it requires seeing the agent’s reasoning early.
Core design principle: don’t wait until task completion to expose results. Surface reasoning early in execution.
Concretely:
Direction confirmation checkpoints. Long tasks shouldn’t run to completion uninterrupted. At 10–20% of execution, the agent should pause and confirm: “I understand you want X. I plan to use approach Y, starting with Z. Correct?” This isn’t requesting permission; it’s exposing assumptions. User glances, two seconds: “Yes” or “No, try W instead.” Two seconds of confirmation may save fifteen minutes of wasted work.
Loop detection and honest uncertainty signaling. If the agent detects repeating operation sequences (same file, same test, same error), it should stop and report: “I’ve cycled between A and B three times; a different approach may be needed.” Similarly, if internal confidence degrades (increasing “maybe,” “possibly,” “uncertain” in recent reasoning steps), that uncertainty should be surfaced, not masked by fluent output prose. An agent that says “I’m 70% confident in this approach” is more trustworthy than one that delivers correct and incorrect answers with identical confidence.
Fine-grained interruptibility. Users should be able to inject corrections at any execution step, not just cancel-and-restart. Cancel-restart costs are too high (all prior work lost), causing users to “let it finish” even after spotting drift, wasting more time. Ideal interruption: pause, user says “this is wrong, approach from angle X,” agent adjusts and continues from current state. Like telling an intern “wait, you’ve misunderstood this part” — not firing and rehiring them.
The industry is addressing part of this. Claude Code recently fixed terminal flickering, thinking-state freezes, and connection instability. Cursor handles context overflow in long tasks. But these improvements target engineering stability — keeping AI from stopping, crashing, or dropping connections. They haven’t risen to the cognitive assistance level — helping users judge whether AI is heading in the right direction. The former is “keeping the machine from breaking”; the latter is “keeping the human from getting lost.” Both matter, but only the former is being taken seriously today.
To close this dimension in programming terms: while(true) in code is a bug — compilers warn, runtime manifests as maxed CPU, visible. But an agent’s while(true) throws no errors, spikes no CPU. It looks like normal work — quietly, fluently, step by step, heading in the wrong direction. Code infinite loops are explicit; agent infinite loops are implicit. The latter are harder to detect and therefore more dangerous.
Dimension 5: Notification Calibration — When to Interrupt a Human (and When Not To)
Assume the above mechanisms are in place: the agent detected an anomaly, or the task completed. Next question: how do you tell the user?
This problem’s difficulty is underestimated. Notifications are, by nature, attention interruptions, and interruptions have costs. Gloria Mark’s research on workplace interruptions has shown that recovering from interruptions can take substantial time, with widely cited estimates around 20-plus minutes depending on context. If AI tools interrupt frequently, they create efficiency losses alongside their gains.
Core principle: notification intensity should scale with urgency of required human intervention, not severity of system event.
These rankings are often inverted. An API timeout that the agent auto-retried successfully is a “severe” system event (a call failed) but requires zero human involvement — no notification warranted. An agent modifying the same function for five consecutive steps without progress isn’t a “severe” system event (no error thrown), but direction may have drifted — gentle nudge appropriate.
Concrete calibration:
- Self-healing issues: don’t disturb. Retries, rollbacks, alternative paths are the agent’s job, not the user’s concern.
- Issues that look normal but may indicate drift: gentle signal. No red alerts, no sounds. Add a subtle text line to the waiting interface, or shift Layer 1’s visual state slightly. Users who are looking will notice; users who aren’t won’t be interrupted.
- Issues genuinely requiring human decisions: escalate. And the notification content should specify what decision is needed, not what error occurred. “Agent reached a tradeoff at step 3: Option A is faster but less compatible; Option B is safer but requires refactoring. Which do you prefer?” beats “Error: unexpected conflict at step 3.”
One overlooked detail: landing buffer on task completion. If the user is engaged elsewhere (drafting an email), and AI suddenly pops a large window saying “Task complete! Click to view results!”, attention is yanked from the current task and forced to evaluate complex deliverables without preparation. Better: light signal first (badge, dot, near-silent chime); user clicks when ready. Give three to five seconds of attention-regathering time. Don’t demand judgment at peak cognitive diffuseness.
Closing: Efficiency Doesn’t Mean Filling Every Second
All five dimensions share an unstated assumption: every human minute should be filled with output. Waiting is waste; idleness is loss; AI exists to eliminate all “unproductive time.”
This assumption deserves questioning.
Return to opening scene one. You scrolled TikTok for eight minutes not because TikTok was irresistible, but because you didn’t know how to occupy yourself during those three minutes. Your brain shifted abruptly from high-intensity work to a no-task state and needed transition — a buffer for exiting work mode. TikTok filled that buffer, but poorly: it didn’t let you truly rest, just substituted one form of depletion for another.
If AI tool design aims to “keep users productive during every second of waiting,” it’s doing essentially the same thing as TikTok — filling cognitive bandwidth, just with “work” instead of “entertainment.” Neither permits genuinely, purposelessly, quietly existing for three minutes.
Sustainable productivity isn’t every second producing. It’s tightening when tightness is needed and genuinely loosening when looseness is needed. If AI tool design can offer users a real, low-stimulus, decision-free blank space during those “should-be-loose” minutes — rather than another interface to manage, another notification to respond to, another time block to optimize — it delivers more value than any efficiency feature.
AI’s next competitive cycle will see model capabilities homogenize. Context windows will lengthen, inference will accelerate, multimodality will expand. These are infrastructure-level advances; all players will arrive. True differentiation will emerge elsewhere: whoever first treats “the time humans spend while AI works” as a first-class design citizen. Not filling it. Not exploiting it. Not optimizing it. Respecting it.
Respecting that human attention has its own rhythm. That cognition needs recovery. That doing nothing is sometimes the most correct choice.
This isn’t a technical problem. It’s a design philosophy problem. And design philosophy ultimately determines whether a product leaves people more composed or more exhausted over time.
Read More of Intelligenr
-
Copilot vs. Cognitive Exoskeleton: How AI Is Reshaping Human Memory & Thinking
-
AI as a Cognitive Exoskeleton: How to Think Without Losing the Ability to Think
References
-
Gazzaley, A., & Rosen, L. (2016). The Distracted Mind: Ancient Brains in a High-Tech World. MIT Press.
https://mitpress.mit.edu/9780262034944/the-distracted-mind/ -
Mark, G., Gudith, D., & Klocke, U. (2008). The Cost of Interrupted Work: More Speed and Stress. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '08).
https://doi.org/10.1145/1357054.1357072 -
Nielsen Norman Group. AI Design Research: Transparency, Trust, and Human-Centered Interaction.
https://www.nngroup.com/articles/dimensions-of-ai-chatbots/
Author Note: This article examines a less discussed side of AI progress: the human experience of waiting, monitoring, and deciding while AI works. Rather than focusing only on model capabilities, it explores how future AI tools might better respect human attention and support more natural forms of collaboration.