Progressive rendering

Agent work is often slow, streaming, and partially known. A compatible Agent UI should show useful state early without blocking on full history, heavy tool output, or artifact previews.

Rendering order

Prefer this order for interactive work:

user action
  -> visible shell
  -> optimistic user message or pending preview
  -> early runtime status
  -> first answer text or process update
  -> tool and task details on demand
  -> artifact preview when available
  -> evidence and replay after completion or export

The shell should not wait for full history or every secondary panel.

Keep streams typed

Do not merge every event into one Markdown string.

Stream part	Surface	Rule
user text	Conversation	Show immediately after submit.
assistant text	Conversation	Render as answer text.
reasoning or thinking	Process	Summarize or collapse; do not mix into final answer.
runtime status	Process or Task	Show before or between text updates.
tool call	Process	Show compact step with details on demand.
queued input	Task	Show as queue or capsule state.
artifact reference	Artifact	Show summary card and open in Artifact Workspace.
evidence reference	Evidence	Show source, verification, or replay entry.

Hydrate history progressively

When opening existing work:

1. Show the shell and title first.
2. Show cached or recent messages if available.
3. Load a bounded recent history window.
4. Defer timeline, large tool output, artifact previews, and evidence details.
5. Ignore stale hydration results if the user switches away.

This avoids blocking the main UI on expensive secondary data.

Collapse high-volume process data

Process data should be searchable and inspectable, not always expanded.

Default behavior:

• active step expanded or summarized
• completed tool steps collapsed
• large outputs summarized with an open-details action
• errors and needs-input states promoted
• background work compressed into capsules

Avoid duplicate final text

Many runtimes emit both streaming deltas and a final completion payload. The UI must reconcile final content instead of appending it blindly.

Recommended behavior:

• Build answer text from typed text deltas.
• Use final content to reconcile, not duplicate.
• Keep reasoning, tool output, and status in their own parts.
• If the final payload conflicts with streamed text, prefer the runtime's explicit final answer and mark the reconciliation.

Latency signals

Clients SHOULD record enough timing to debug perceived slowness:

Metric	Meaning
submitToShellMs	Time from user submit to visible conversation shell.
submitToStatusMs	Time to first credible runtime status.
submitToFirstTextMs	Time to first assistant answer text.
firstTextToPaintMs	Rendering delay after first text delta.
historyClickToShellMs	Time from opening old work to visible shell.
historyClickToRecentMessagesMs	Time to useful recent content.
artifactReferenceToPreviewMs	Time from artifact reference to preview availability.

Metrics are not part of the user-facing UI contract, but they make acceptance scenarios testable.

Acceptance scenarios

A basic progressive rendering implementation should pass these scenarios:

1. Submitting a short prompt shows the user message and a runtime status before first text.
2. A tool-heavy task does not insert raw tool output into the final answer.
3. A generated artifact appears as a card or preview outside the final answer body.
4. Opening old work shows shell or recent content before full process history loads.
5. Switching between two sessions does not let stale hydration overwrite the active view.
6. A missing artifact kind is shown as unknown rather than guessed from message text.