Agent progress UI: make a stalled tool visible

Current snapshot

Observe work, not a reassuring spinner

The worker inspector and the product status panel deliberately expose different information. The inspector shows the computed task state, attempt identifier, completed work units and heartbeat timestamps. The product panel displays only notifications allowed by Update policy. Emit milestones reports acceptance, tool start, deadline warnings, accepted tool results and final delivery. Final response only withholds intermediate states and publishes success or cancellation. Comparing these panels shows how a responsive worker can coexist with an uninformative product interface. Heartbeats never increase the completed work count and never reset the work deadline.

Choose the workload and deadline

Tool behavior sets the first read-only attempt to finish after ten seconds, finish after twenty-five seconds, or never return. The attempt starts at modeled second five. After its accepted result, report drafting takes three more seconds. No-work deadline selects eight, fifteen or thirty seconds from attempt start; it detects overdue work rather than proving a worker has failed. Heartbeats arrive every five seconds when enabled. Turning them off removes only liveness events; it does not change task completion or deadline decisions. The two work units are tool completion and report completion. They are discrete milestones, not equal shares of effort or an estimated percentage of elapsed runtime.

Compare exact outcomes

With the normal tool, fifteen-second deadline and Keep waiting, tool completion occurs at second fifteen and the report at eighteen. Choose the slow tool: the warning appears at twenty, the late but still current tool result is accepted at thirty, and success follows at thirty-three. At second twenty-five, the worker can be stalled with a fresh heartbeat and zero completed units. Set Final response only and the product still says it is waiting despite these inspector events. Change to the thirty-second deadline: the slow tool completes before its deadline and no warning is produced.

Exercise recovery and late results

After deadline selects Keep waiting, Retry once or Cancel locally. Retry and cancellation are scheduled two modeled seconds after the warning. With a stuck first attempt, fifteen-second deadline and Retry once, attempt two starts at twenty-two, completes at thirty-two and delivers the report at thirty-five. The replacement read-only attempt always needs ten seconds; there is never a third attempt. With a slow first attempt, retry also starts at twenty-two, and the original result at thirty is ignored because its attempt identifier is stale. Cancel locally instead stops accepting results at twenty-two; the original result at thirty cannot turn cancellation into success. Cancellation here proves only a local state transition, not termination or rollback of remote work.

Inspect boundaries and control time

An eight-second deadline can flag the normal ten-second tool too early. Its result arrives at fifteen, exactly when recovery would run, and completion is processed first, avoiding an unnecessary retry or cancellation. Play advances a sixty-second modeled timeline; Pause freezes it. Next event pauses at the next distinct event time. Restart preserves scenario choices and speed while rewinding. Time seeks and pauses; Speed selects quarter, half, normal or double pace. Changing a scenario rewinds without autoplay. Hiding the tab pauses playback. Events and the JSON snapshot include only the inspected prefix, so future success is not displayed early. Export events JSON explicitly includes both the full computed model and the inspected prefix.

Record comparisons and respect the model boundary

Capture baseline stores the current result and settings; Replace baseline updates it and Clear baseline removes it. Notebook observations persist in this browser; Export notes downloads them. Expand experiment and Exit full screen change the workspace view. All durations and responses are deterministic teaching inputs, not measurements of an ADK service. This page does not send MCP messages, invoke an LLM, run a remote tool or implement distributed cancellation. The retried tool is read-only; replaying a write would require separate idempotency and effect reconciliation. Heartbeat liveness cannot establish useful progress, and an expired local deadline cannot establish that a remote operation had no effect.