Designing Ethen for Work That Takes Minutes or Hours

Ethen designs background AI tasks so that their status and progress stay clear however long they run. It does that by matching the experience to how long the work takes, and by making the job — not the conversation — the thing people watch, leave and come back to. In practice that means five design commitments. Work is presented by duration tier: seconds stay in Chat, minutes become a visible job, hours run in the background with a timeline, and days become delegated work with checkpoints. Status uses a small, honest vocabulary that simplifies what the system tracks without ever rounding an unknown outcome into success or failure. Costs are shown before work runs where they can be known. Interruptions are reserved for decisions that genuinely need a person. And every long job resumes safely and ends in a review with evidence. These commitments rest on foundations described in our engineering posts; the experience built on them is still evolving.

Key takeaways

• Duration decides the design. A ten-second answer and a ten-hour job need different presentation, not the same spinner.
• Simplify status, never hide uncertainty. People see fewer states than the system tracks, but "unknown" is never shown as "done" or "failed".
• Know the cost first. Expensive work quotes its cost and reserves budget before it starts.
• Interrupt for decisions, not for updates. Notifications arrive when a person is needed, with the context to act.
• Resume, then review. Interrupted work continues from its last good point; finished work arrives with evidence.

Why design by duration?

Designing by duration matters because how long work takes changes what people need from the interface. A response that arrives in about a second keeps someone's train of thought intact; beyond roughly ten seconds, people's attention drifts and they want progress feedback and the freedom to do something else (Nielsen, 1993). AI work in Ethen spans that range and goes far beyond it — from a quick answer in Chat to a media generation that takes minutes, to a research or code task that takes an hour, to delegated work that unfolds over days.

Seconds. Conversational answers stream in Chat. Nothing else is needed, and adding job machinery here would only slow things down.

Minutes. Work such as generating a video clip or running a research pass becomes a visible job inside the app where it started. You see the phase it is in and the current step. For work with a meaningful cost, you see the cost before it runs.

Hours. Work that takes longer than anyone will watch becomes a background job with a timeline. You can close the window, change devices and come back. Ethen reaches out only when a decision needs you.

Days. Delegated work and goal-driven jobs — the kind of work Ethen Founder and the direction we call Ethen Work are designed for — have a plan, planned checkpoints, progress summaries and a review at the end.

Work can move between tiers. A research question that turns out to be bigger than expected should become a job rather than leave someone staring at a spinner. The general case for why longer work needs a different interface is in Why Long-Running AI Work Needs a Different UX Than Chat.

What should the status say?

Status should say what is true in words a person can act on. Ethen's shared job service tracks a precise set of internal states — including queued, claimed, running, completed, failed, cancelled, timed out, a state for jobs that have been retried too often, a state for jobs whose outcome is indeterminate, and a state for jobs halted because continuing would be unsafe. That precision is essential for the system: it is how a job knows which moves are legal after a crash. The details are in Inside Ethen's Durable Job Service.

People need a smaller vocabulary. The design direction is a handful of user-facing states:

• Waiting to start or Working — with the current phase and step.
• Needs you — a decision or approval is waiting, and the job is paused safely until it is made.
• Checking what happened — an action's outcome is uncertain, and Ethen is confirming it before doing anything else.
• Paused for safety — continuing could cause harm, so the job stopped and is waiting for a person.
• Done — with evidence — the result is ready for review.
• Stopped — with a reason — the job failed, was cancelled, or could not continue, and says why.

The rule that governs the mapping is strict: simplify freely, but never hide uncertainty. A job whose outcome is indeterminate is shown as "checking what happened", not as "failed" (which invites a duplicate retry) and not as "done" (which invites someone to rely on something that may not exist). In Ethen's job service, an indeterminate job can only leave that state through an explicit reconciliation step, and the interface should reflect that rather than paper over it.

How does Ethen handle cost for long work?

Long work can be expensive, and surprises are worse than costs. Where a cost can be known in advance, Ethen's direction is to show it before the work runs and to reserve budget so the job cannot overspend silently. Ethen Studio's media job path already works this way: a generation is validated, its cost is quoted, and budget is reserved before it begins; uncertain provider outcomes are reconciled rather than resubmitted blindly, which avoids paying twice. See Building Durable Image and Video Jobs in Ethen Studio.

There is a second, less obvious cost to plan for: checking the work. An agent that spends its whole budget doing the work has nothing left to verify it. In Ethen's mission system, verification capacity is reserved before execution spending begins, as described in Reserving a Budget for Verification. For people, the practical consequence is that a job's budget covers finishing and checking — not just doing.

Some costs cannot be known in advance, such as how many sources a research task will need to read. In those cases the direction is to show a budget limit and the spend so far, and to ask before exceeding the limit.

When should Ethen interrupt you?

Ethen should interrupt you when a decision needs a person, and otherwise leave you alone. Three kinds of moment qualify.

Consequential actions. Sending messages, spending money beyond an agreed limit, changing records outside the agreed scope, or anything else hard to undo. Ethen binds approvals to the specific action they cover, so approving one action cannot be stretched to cover a different one; see Binding Computer-Use Approvals to Specific Actions.

Genuine ambiguity. Two reasonable interpretations, conflicting sources, or a missing piece of information that the job cannot safely assume.

Failures that need a person. An outcome that cannot be confirmed automatically, a permission that has been revoked, or a situation where stopping is safer than continuing.

Everything else — routine progress, minor retries, intermediate results — belongs in the timeline, not in your notifications. Human-AI interaction guidelines have long recommended timing a system's interventions to the user's context and making them easy to dismiss or act on (Amershi et al., 2019). A notification that arrives with the context to decide in under a minute respects that; one that says "your job needs attention" and nothing else does not.

How does long work survive interruptions?

Long work survives interruptions because it does not live in a browser tab or a single process. Ethen's job service is designed so that only one worker acts on a job at a time, a worker that has lost its claim cannot overwrite newer progress, and a job can be picked up by another worker after a crash. For the person, that means closing the window, losing a connection or a routine server restart should show up as, at most, a short pause in the timeline.

The harder part is resuming without repeating effects. If a step was in flight when the interruption happened, the job first establishes whether it took effect. Only then does it continue. We explain the principle in Why Ethen Is Building for Recoverable AI Work, and what people see when it happens in What Happens When an AI Task Fails Halfway Through?.

What about teams?

Long work is often shared work. A job started by one person may need approval from another, review by a third, and follow-up by whoever is on duty tomorrow. The design direction treats jobs as belonging to a project or team space, not only to the person who clicked start.

Three consequences follow. Ownership is explicit. Every job shows who started it, who can approve its consequential steps, and who will review the result, so a decision never waits on someone who does not know it exists. Hand-offs keep the history. When a colleague picks up a job, they see the same timeline, decisions and evidence the original owner saw, rather than a summary written from memory. Permissions follow the work. A colleague who can view a job is not automatically able to approve its spending or widen its access; those rights are part of the job's boundaries.

This matters most for work that spans days. A delegated task that pauses for an approval over a weekend should be easy for whoever is responsible on Monday to understand and act on in a minute, with nothing lost in between.

What does the end of a long job look like?

The end of a long job is a review, not a reply. The direction for every app that runs long work in Ethen is a review view with four parts:

1. The result — the report, the change, the assets, the completed task.
2. The evidence — sources linked to claims, records of actions taken, checks that ran and their outcomes.
3. What remains open — unknown outcomes, unfinished obligations, items the job could not complete, each with a reason.
4. The timeline — what happened, in order, including pauses, decisions and recoveries.

In Ethen's mission system, a mission cannot be marked complete without independent evidence, and cannot complete while an outcome is still unknown; see Making Mission Completion Depend on Evidence. The review view is where that rule becomes visible to people.

An example across tiers

Illustrative example — describes intended experience, not a specific shipped screen.

A marketing lead asks Ethen Chat for a quick tagline (seconds; streamed in the conversation). They then ask for a short product video; Studio shows the cost before generating and a phase indicator while it renders (minutes). Next, they ask Ethen to compile a competitive analysis from twenty sources; that becomes a background job, and they close the laptop (hours). An hour later a notification asks which of two conflicting market-size figures to treat as authoritative, with both sources shown; they choose from their phone. When they return, the review shows the analysis, each claim linked to its source, one source marked as unreachable, and a timeline that includes a short pause where a server restarted. Nothing about the restart required their attention.

What is direction and what is implemented?

The foundations described here — the durable job service and its states, quoting and reserving cost for Studio media jobs, reserving verification budget in the mission system, binding approvals to actions, and evidence-gated completion — are implemented mechanisms described in our engineering posts, each with its stated test limits. The user-facing experience — duration tiers, the simplified status vocabulary, notification policy and review views across apps — is design direction. We are not announcing release dates or availability.

Tradeoffs

Designing by duration means the same kind of request can look different depending on how long it turns out to take, which can surprise people. A smaller status vocabulary loses some precision that engineers would want; the full detail needs to remain available for anyone who looks. Quoting costs up front requires knowing them, which is not always possible. And fewer notifications place more weight on the job's boundaries being right. Each tradeoff is a reason to keep the underlying record detailed even when the presentation is simple.

Frequently asked questions

Will my Ethen task continue if I close the browser? Long-running work is designed to run as a job that does not depend on your browser staying open. You can return to it later or from another device.

How will I know if a long job needs me? The direction is for Ethen to notify you when a decision, approval or failure needs a person, with the context to act — and to wait safely until you do.

What does "checking what happened" mean? An action's outcome was uncertain, for example after a timeout. Ethen confirms what happened before doing anything else, so it does not repeat the action.

Can I see what a job will cost before it runs? Where cost can be known in advance, as with Studio media jobs, it is quoted and reserved before the work begins. Where it cannot, the direction is to show a budget limit and spend so far.

Related reading

• Why Long-Running AI Work Needs a Different UX Than Chat
• AI Agents and Autonomous Work
• Ethen Orchestration

References

1. Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group. https://www.nngroup.com/articles/response-times-3-important-limits/
2. Amershi, S. et al. (2019). Guidelines for Human-AI Interaction. Proceedings of CHI 2019. https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/
3. Ethen Blog (2026). Inside Ethen's Durable Job Service. https://upcube.ai/blog/inside-ethens-durable-job-service
4. Ethen Blog (2026). Building Durable Image and Video Jobs in Ethen Studio. https://upcube.ai/blog/building-durable-image-and-video-jobs-in-ethen-studio
5. Ethen Blog (2026). Reserving a Budget for Verification. https://upcube.ai/blog/reserving-a-budget-for-verification
6. Ethen Blog (2026). Binding Computer-Use Approvals to Specific Actions. https://upcube.ai/blog/binding-computer-use-approvals-to-specific-actions
7. Ethen Blog (2026). Making Mission Completion Depend on Evidence. https://upcube.ai/blog/making-mission-completion-depend-on-evidence