Show progress for AI runtime jobs: confirmed stages instead of invented percentages

A worked example: where the task becomes difficult

A fictional workspace prepares an imported app by loading source, installing dependencies, starting a process and waiting for a route. The UI shows 90% almost immediately and stays there after installation fails. A useful indicator names the confirmed stage and recent log summary. It should distinguish “process started” from “application route ready” and “browser rendered.”

Decisions to make before implementation

Define job identity and the event stream or status endpoint that owns progress. Use monotonic stage transitions where appropriate and account for retries. Keep sensitive runtime output redacted. Distinguish a slow stage from a failed or stalled one using bounded checks. A progress animation can communicate activity without pretending to know an exact completion time.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Map preparation stages and the evidence confirming each transition.
• Emit bounded structured events tied to a job identity.
• Render stage, elapsed time and recoverable failure without false precision.
• Test lost connection, process exit and a successful final route.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement preview-job progress from actual source, install, process and route events. Tie updates to active project and job identity. Show stage and elapsed time, using a percentage only with a real denominator. Handle disconnect, exit and retry. Redact logs and do not mark the app ready from process startup alone.

Failure modes that an attractive preview can hide

A UI timer cannot know how many packages remain or whether the runtime has crashed. Do not derive a fake percentage solely from elapsed time. Stale events from a previous project can mislabel the current preview; validate active job and project identity. Keep cancel and retry behavior consistent with whether a backend operation actually stopped.

Technical references: Google: Web Vitals

Acceptance checks and the evidence to retain

Keep the stage contract, event ownership, identity checks and failure tests. Explain which parts of completion remain uncertain instead of hiding them behind a near-finished bar.

Specific answers

Common questions