Web Workbench

AgentHub Web (port 5174) is the Hub-backed IM-form collaboration surface. It shares the same workbench UI with Desktop, showing the agent conversation in chat and review results in dedicated panels. A team can see projects, shared sessions, run history, review state, and integration-created tasks without the browser having direct access to a developer’s local filesystem or CLI processes.

When To Use Web

Use AgentHub Web when the workflow needs shared visibility rather than direct local execution:

Scenario	Use Web for	Use Desktop / Edge for
Team review	Shared conversation, review state, audit trail	Local file preview and local diff approval
Project overview	Project context, tasks, agents, devices, run history	Workspace management and runtime process control
IM-created work	Hub task created from Feishu/Lark or automation	Runtime execution after Hub authorization
Remote target planning	Target selection, authorization state, degraded state	Actual workspace access through an approved Edge

Web is the collaboration layer. Local execution belongs to Desktop plus Edge.

Surface Model

A complete Web workbench organizes these surfaces without turning the page into a generic chat app:

Surface	Purpose	Current status
Project list	Entry point for team-owned work	In progress
Project detail	Context, files, runs, agents, tasks, members	In progress
Shared session	IM-form group chat, selected agent, target, events, approvals	In progress
Review view	Results, diffs, comments, approve/reject actions	In progress
Target/device view	Online state, authorization, last seen, capabilities	In development
Audit/status view	Product events, degraded state, failure reason	In progress

Hub Contract

Web talks to Hub. Hub owns identity, product sessions, project membership, device routing, task creation, shared state, and audit.

The minimum useful Hub-backed Web session includes:

• TokenDance ID subject and AgentHub product session (OIDC PKCE).
• Project id, role, and membership state.
• Task or run id.
• Selected Agent Profile and target Edge.
• Conversation events and run lifecycle events.
• Results, diffs, approvals, and failure reviews.
• Audit events for who requested, approved, rejected, cancelled, or escalated work.

Web renders local execution state only after Hub has authorized the target and Edge has emitted safe events.

Local File Boundary

The core rule for Web: Web does not own the local filesystem.

Request	Correct behavior
User asks Web to inspect local files	Create a Hub task and route to an authorized Edge target
User opens a diff produced by Edge	Render normalized diff data, not arbitrary local paths
User clicks approve	Send a Hub/Edge approval action with audit context
User asks for a terminal command	Require explicit policy and route through Edge approval
Edge is offline	Show unavailable or degraded state

Public screenshots should avoid private absolute paths, secrets, provider keys, internal host names, and real user data.

Interaction States

Web exposes stable product states that are readable in desktop and mobile layouts:

State	Meaning	UI expectation
Empty	No project or run selected	Compact prompt to pick or create a task
Ready	Hub session and project context are loaded	Clear primary action, visible target state
Running	Edge has accepted the run and streams events	Message stream, progress, cancel affordance
Needs approval	Edge is waiting on user or reviewer action	Results (diffs/artifacts) visible, decision controls clear
Completed	Run finished with results	Summary, results, next action
Failed	Runtime, policy, schema, auth, or network failure	Stable error code and recovery path
Degraded	Target, Hub, or integration is partially unavailable	Honest status display

Avoid jumpy layout, heavy hover shadows, old purple accents, black footer blocks, and browser-default blue focus outlines in product mocks. Focus states still need to exist for real controls, but mock-only decorative controls should not look like selected DOM.

Review Flow

A Web review flow makes the decision chain visible:

1. A user, integration, or automation creates a Hub task.
2. Hub resolves project membership, product authorization, Agent Profile, and target policy.
3. Edge starts the runtime only after authorization and workspace policy pass.
4. Edge streams normalized events and candidate results.
5. Web renders the conversation, results, diffs, and approval state.
6. A reviewer approves, rejects, comments, escalates, or cancels.
7. Hub records audit events and exposes final state.

Design Requirements

Web follows the same product direction as AgentHub Desktop and the public website. Both share the same workbench UI:

• Light-first TokenDance Blue surfaces.
• Dense but readable tool layouts.
• Small radii and restrained glass.
• Icon-first controls where the meaning is familiar.
• No marketing cards inside tool panes.
• Tables and panels that do not overflow on mobile.
• zh/en text that describes the same capability and status.
• Chat messages and review results rendered consistently with Desktop.
• Motion that helps continuity without changing layout after hydration.

Evidence Checklist

Before moving Web copy from “in progress” to a stronger claim, capture:

Evidence	What to prove
Route screenshot	Project/session/review route renders in desktop and mobile
Hub API trace	Web reads Hub state through product session boundaries
Edge routing trace	Target selection and Edge events are authorized through Hub
Review screenshot	Review surface renders workbench contracts and does not expose private paths
Approval audit	Approve/reject/cancel actions produce recorded events
Failure screenshot	Offline target, unauthorized target, runtime unavailable, and timeout are readable

Related Pages

• Architecture
• Hub And Edge
• Collaboration
• Run Lifecycle
• Security

Edit this page on GitHub