Show where the action will happen
A browser agent creates a design problem that a chat box alone cannot solve: the user must understand which page will change before the action happens. For a fictional team-settings task, the important context is the account, environment, selected tab, and permission boundary, not an animated “working” badge.
Keep the target visible near the action history. A local preview and a production settings page can look almost identical. A readable URL, page title, and environment label help the user notice a mistaken target before approving a sensitive step.
Use progress states that correspond to real events
Separate queued work, an executing tool call, a completed call, and a verified outcome. A command can exit successfully while the expected interface is still broken. Likewise, an agent composing a reply is not evidence that it is interacting with the browser.
Avoid adding a new row for every small streaming update. Update the active operation in place and preserve completed evidence. Let the reader inspect details without losing their place when new content arrives.
- Waiting: say what input or tool availability is needed.
- Running: show the current operation and its target.
- Needs approval: explain the concrete change and scope.
- Completed: connect the result to an observation or artifact.
- Blocked: explain what was not tested and what would unblock it.
Make approval a decision, not a reflex
Consider a change to member roles. “Allow tool call?” is less useful than a summary identifying the workspace, affected test member, old role, and proposed role. Place the approval next to that context, and do not use a visual treatment that makes every request look routine.
Prompt text is not a substitute for real authorization controls. Restrict accounts and tools appropriately, and test that the application respects the selected mode. If the task involves a purchase, message, or deletion, the interface should make that consequence explicit.
Review the small-screen and streaming experience
At a narrow width, preserve the message and the active operation before auxiliary panels. Long URLs and command output should wrap or scroll within their own area, not push the page sideways. Keep a stable input area so growing output does not move the user's controls.
Respect users who scroll up to read earlier evidence. A follow-output control is preferable to repeatedly pulling them to the bottom. Reduced-motion preferences should disable decorative movement without hiding status changes or content.
Use a fictional test account and a local settings page.
Start a task, then read an earlier message while output continues.
Open one tool result and return to the conversation.
Interrupt the task before a sensitive action.
Repeat at a narrow viewport and with reduced motion enabled.
Verify that target, status, input, and evidence remain understandable.End with what is known
A final message should state what changed, what was checked, what remains uncertain, and whether any external action occurred. Keep “prepared,” “tested,” and “deployed” distinct. The purpose of the interface is to help the user make the next decision, not to make every run look successful.
For public demonstrations, use synthetic workspaces and representative examples. Do not expose real customer sessions to make a demo appear more convincing. A realistic workflow can demonstrate the product while clearly labeling illustrative data.