Expert Workspace
Current turn contract: ADR-046
The Expert Workspace is an internal operations surface under /workspace/*.
It lets authorized Experts handle explicit human requests and genuine failures,
inspect a delivered Specialist conversation when they intentionally open it,
coordinate optional follow-up, add internal notes, and correct canonical text.
Ordinary successful delivery does not create Expert work.
It is not a default human-in-the-loop release queue. A successful managed
Hermes reply reaches the client directly and exactly once. Workspace status,
confidence, risk, assignment, unread state, and Expert availability cannot set
held_for_review, hide a reply, or create substitute prose.
Surfacesโ
| Route | Purpose |
|---|---|
/workspace/queue | Explicit human requests, genuine failures, assignment, optional follow-up and correction |
/workspace/tasks | Long-running product task visibility |
/workspace/approvals | Explicitly configured external write-action compatibility requests |
/workspace/analytics | Operational and quality analytics |
/workspace/settings | Expert preferences and stable assignment configuration |
The UI receives live changes through Socket.io and performs a bounded refresh after reconnect. It must not poll full active/all-status snapshots on a fixed timer when no event occurred.
Canonical conversation and correctionโ
The conversation pane is populated by an authorized API read directly against the cloud SessionDB authority. The API serializes canonical rows transiently for that response; it does not persist a mirrored transcript, Postgres prose history, or UI projection. The pane renders every turn in order, and a later Specialist reply must not replace or hide an earlier one.
When an authorized Expert corrects delivered Hermes text, the write targets the
exact SessionDB assistant locator returned by Hermes. A genuinely human-authored
follow-up with no Hermes row is appended once, and the locator returned by
SessionDB becomes its identity. Retries are idempotent at that boundary;
Humanwork does not create a delivered_message envelope, Postgres prose
projection, or UI-only deduplication mask.
Human-only context toolsโ
Customer-history and KB-search panels may help an Expert investigate or author a follow-up. Those UI queries are human workspace features. They do not cause Humanwork to retrieve KB, build history, or insert citations before Hermes sees a client message.
Attachments and generated files remain in the conversation's cloud AgentFS. The API accesses that authority directly; the Expert UI receives normal authorized download metadata. Python and hermes-run are not file proxies.
Explicit write-approval compatibilityโ
/workspace/approvals may display a concrete external write that a
server-owned action policy explicitly opted into the narrow compatibility
carrier. The request binds tenant, assignment, run, tool, operation, parameters,
and policy version; approve executes once, while reject/cancel never executes.
This carrier is distinct from conversation observation:
- it does not classify a user message or narrow Hermes tools;
- it does not inject approval instructions into the prompt;
- it does not withhold an unrelated successful reply; and
- it does not append a synthetic continuation to SessionDB.
See the compatibility carrier decision for its isolated verification boundary.
Access and evidenceโ
All reads and writes retain the existing expert_access Org ร Specialist
scope. Browser acceptance must prove the client-visible conversation and reload
persistence; an API response, queue row, or Expert-side rendering alone is not
proof that the client received the reply.
Related: