Human To Agent Messaging UI Research for NeuroWikis

Full report

On this page

Design goal

The strongest fit for NeuroWikis is an authenticated, human-first messaging page that stays inside the existing product boundary: humans compose and review messages in NeuroWikis, while agents continue consuming them through the existing internal exchange path and audit model rather than a new public API. That aligns with NeuroWikis’ public positioning as the human-facing guide with “plain language for everyone” and “visual, human-first explanations,” while NeuralWikis remains the structured agent-exchange layer with provenance, audit records, rollback-aware workflows, and permissioned exchange patterns.

The main UX challenge is not message composition; it is safe targeting across nested scopes without overwhelming nontechnical users. The most relevant research patterns point in the same direction: use hierarchical navigation for deep structures, breadcrumbs for orientation, progressive disclosure for advanced options, and multi-layer interfaces so novices can stay in a simple mode while experienced operators open deeper controls only when needed. Tree views are specifically meant for multi-level nested content, breadcrumbs preserve location in deep hierarchies, and progressive disclosure reduces errors by moving advanced features to secondary surfaces.

My recommendation is a single authenticated Message agents surface with one compact compose card, a scope-aware recipient selector, and a persistent outbox/status area below it. The common path should be: choose scope, choose audience, write message, set action requirement, send, then watch delivery and acknowledgement counts in place. Advanced targeting, inactive-agent inclusion, and per-agent inspection should stay one click deeper. That structure follows current design-system guidance to keep tasks contextual, minimize visual clutter, and surface only the controls relevant to the current step.

Research synthesis

A large nested selector should not be a giant dropdown. NNGroup notes that dropdowns are often overused, long dropdowns are hard to scan, and interactive or disappearing options create confusion; Carbon’s tree-view guidance instead supports nested hierarchies, and breadcrumbs provide low-space orientation for structures with more than two levels. For this problem, that means a scope path plus a tree or drill-down list is preferable to a single “Target” dropdown containing company, workspaces, projects, events, and agents.

For “all agents versus some agents,” the best pattern is hierarchical multiselect with parent-child semantics. Fluent’s tree guidance explicitly supports multiselect where selecting a parent selects its children and deselecting a child leaves the parent in a mixed state; Carbon’s data-table guidance similarly supports a tri-state “select all” checkbox with checked, unchecked, and indeterminate states. That maps cleanly to “All agents in scope,” “All active agents in scope,” and “Specific agents in scope” without forcing users to hand-pick every recipient.

Presence should be shown as a hint, not as a delivery gate. Teams documents presence as near-real-time availability, and Slack uses simple active/away indicators with a dot and status text. That makes presence useful for expectation-setting, but it should never change permission, delivery, or authority. In this UI, “Active now,” “Idle,” or “Inactive” should help users estimate response timing, while delivery still means the message entered the intended internal lane for the targeted agents.

Receipts need to distinguish delivery, view, and resolution. Teams uses a clear “Delivered” versus “Seen/Read by” distinction, while Slack’s message-activity pattern demonstrates that aggregate interaction counts are often enough for broad announcements. For NeuroWikis, that suggests a three-level human-facing model: delivered to targeted agents, viewed by targeted agents, and resolved by targeted agents, with detailed per-agent visibility only where the sender is authorized and the audience is small enough to keep the UI readable.

A separate control for urgency and action requirement is better than one overloaded priority field. Carbon separates notification status from notification type and explicitly distinguishes optional action from required action. That is a strong precedent for using one field to express message seriousness and another to express whether an agent must reply or only acknowledge. It prevents the common confusion where “urgent” gets used as a substitute for “response required.”

Authority boundaries should be visible and strict. NIST defines RBAC as permissions tied to roles rather than individual identities, and OWASP recommends deny-by-default authorization. Carbon’s guidance is especially useful here: permissions-based actions should be hidden when the user can never perform them, while temporarily unavailable actions can be disabled and explained. That means forbidden scopes should not appear as selectable targets, but temporarily locked states such as an event under review may appear disabled with a short explanation.

For nontechnical users, multi-layer design is directly applicable. Shneiderman’s multi-layer interface work argues that novices should be able to start with a limited feature set and move up only when needed, while NNGroup’s form research emphasizes structure, transparency, clarity, and support. NeuroWikis’ own public language also leans toward plain-language explanation rather than expert-only terminology. So the UI should default to a short, plain-language form and tuck advanced routing and operational metadata into an expandable Advanced options panel.

Recommended surface

I recommend a dedicated authenticated page named Message agents inside the account/dashboard area. The page should be a single desktop surface, not a modal-first workflow. Use a breadcrumb at the top, a compact compose card in the main column, and an outbox/activity region below. A right-side details drawer is appropriate for receipt inspection because non-modal side panels let users keep seeing the underlying list while reviewing one record, and drawers are specifically suited to contextual, short multi-step tasks.

A compact wireframe would look like this:

Company › Workspace › Project › Event

[Scope]
Acme Corp / Research / Neuro Project / July Summit

[Audience]
(•) All active agents in this scope
( ) All agents in this scope
( ) Specific agents

[Specific agents]  Search agents by name…   [Typeahead when enabled]

[Message purpose]      [Operational update v]
[Action needed]        [Response required v]
[Priority]             [Normal v]

[Message]
____________________________________________________
____________________________________________________
____________________________________________________

[Advanced options ▾]
  Include inactive agents [ ]
  Short title             [________________]
  Due by                  [________________]
  Related event/object    [________________]

[Send to agents]   [Preview recipients]

Recent messages
| Title | Scope | Audience | Delivered | Viewed | Resolved | Last activity |

The key targeting pattern should be scope first, audience second. First the user lands in a scope through breadcrumb or drill-down. Then the audience control asks whether to target all active agents, all agents, or specific agents inside that scope. This sequencing is simpler than asking users to think about hierarchy and recipient membership at the same time, and it is consistent with progressive disclosure and task-first information architecture.

For drilling through company, workspace, project, and event levels, use a narrow scope tree or drill-down list on the left side only when users need to change context. Carbon’s guidance is clear that tree views are good for large nested information sets but should not become the entire product navigation by themselves; pairing them with breadcrumbs gives place-awareness without clutter. That combination suits this use case well: users can browse down to a project or event, and the compose area then stays focused on messaging rather than navigation.

For selecting named agents, do not show a long static checklist by default. Carbon’s filterable multiselect and combo-box guidance is better for large option sets because users can type to narrow the list, selected items move into a compact summarized state, and the control supports filtering without closing after each pick. Use that pattern only when Specific agents is chosen.

For active and inactive agents, show a short text badge next to each agent name in results and details: Active now, Idle, Inactive, or Off duty. Keep those labels short because compact badges scan better, and use text plus color rather than color alone so status remains accessible. Fluent notes that badges on tree nodes are an effective compact way to show status, and Carbon recommends short status labels for tags.

Send confirmation should not interrupt the task. Both Fluent and Carbon advise using dialogs only for genuinely disruptive or risky moments, while inline notifications and toasts are better for normal feedback. So after a normal send, show a short inline success state in the compose card and a toast saying the receipt is ready. Reserve a confirmation dialog for unusual cases such as sending to all company agents or resending a previously unresolved urgent message to a very broad audience.

Field labels and copy

The default compose form should expose only the fields that most users need. Labels should stay outside fields, placeholders should not carry the burden of meaning, required fields should be obvious, and action labels should be brief and verb-led. NNGroup specifically warns that placeholder-only labeling hurts usability, recommends marking required fields clearly, and recommends brief informative command labels.

I recommend these default field labels for the compact form:

• Scope — read-only once chosen, with breadcrumb above it.
• Audience — values: All active agents in this scope, All agents in this scope, Specific agents.
• Specific agents — only visible when needed; typeahead multiselect.
• Message purpose — values: Operational update, Question, Request, Announcement.
• Action needed — values: Response required and Acknowledge only. Map these internally to required_response and viewed_acknowledgement.
• Priority — values: Normal, High, Urgent.
• Message — main multiline body.
• Send to agents — primary button.
• Preview recipients — secondary button.

I would keep these in Advanced options instead of the default view:

• Short title — optional, for outbox scanning. If omitted, the system can derive one from the first line.
• Include inactive agents — off by default.
• Due by — only when Response required is chosen.
• Related event or object — optional contextual link for low-level operational traffic.
• Show delivery details — opens receipt drawer after send.

The copy should stay deliberately human. Carbon’s notification guidance says messages should be clear, concise, contextual, and free of jargon; NeuroWikis’ own public positioning emphasizes plain-language explanations. So avoid labels such as “packet route,” “lane commit,” or raw status codes in the primary UI. Those can exist in internal logging and admin traces, but the human-facing copy should say what happened in ordinary language.

Recommended helper copy:

• Under Audience: “Choose who should receive this message within the current scope.”
• Under Action needed for Acknowledge only: “Agents should mark this as seen. No reply is required.”
• Under Action needed for Response required: “Agents should reply before this message is considered resolved.”
• Under Include inactive agents: “Use this only when the message should wait for agents that are not currently active.”

Recommended empty and error copy:

• Empty outbox: “No messages yet. Start by choosing a scope and writing a message.”
• Forbidden target: do not show the option at all if never allowed.
• Temporarily unavailable target: “Messaging is unavailable in this scope right now.”
• Validation error: “Enter a message before sending.” / “Choose at least one agent.”
• Broad-send confirmation: “You are about to message every active agent in this company.”

Receipt and boundary model

The receipt model should be simple on the surface and rigorous underneath. User-facing receipts should prove that the message was accepted and routed, but they should not expose internal record IDs, session details, lane internals, or hidden agent identifiers. OWASP recommends that identifiers exposed to clients be meaningless and not contain sensitive information, and it also recommends protecting logs and considering masking, sanitizing, hashing, or excluding sensitive fields. NIST likewise recommends anonymizing shared log data and removing unnecessary identifiers such as session or user identifiers.

The internal implementation should therefore keep a tamper-resistant audit trail and a separate external receipt reference. OWASP’s logging guidance recommends integrity controls for high-value audit trails, such as append-only storage, and warns against exposing logging details to users in ways that create information leakage. This is a strong fit for a design where the database stores full routing and acknowledgement detail, while the UI exposes only a redacted receipt summary plus an opaque public reference code.

I recommend this user-facing receipt language:

• Immediate send confirmation: “Message sent. Delivery receipt created.”
• Delivery line: “Delivered to 18 targeted agents.”
• View-only resolution line: “12 viewed · 6 not yet viewed.”
• Response-required resolution line: “12 viewed · 5 responses recorded · 1 response pending.”
• Privacy line: “Receipt reference: NWM-7X3C-K4Q9.”
• Optional note: “Internal routing details are hidden.”

I also recommend a very explicit status ladder in the outbox:

• Queued — accepted for routing.
• Delivered — written to all targeted agent message lanes.
• Partially viewed — at least one but not all recipients have acknowledged viewing.
• Fully viewed — all recipients have acknowledged viewing for acknowledge-only messages.
• Partially resolved — at least one required response recorded, but not all.
• Resolved — all targeted recipients have met the expected acknowledgement or response requirement.

For broad audiences, detailed per-agent receipts should be constrained. Teams shows full “Read by” detail only in small chats, which is a useful precedent. For company-wide broadcasts, the main view should show counts by status and only open named recipient detail for users who have the right to inspect that scope. That reduces clutter and reinforces privacy boundaries.

Authority boundaries should work like this. If a user does not have the role to message a company or workspace, that target should be absent. If the user has broad access but a specific object is temporarily unavailable, show it disabled with a short explanation. If the user lacks permission to inspect individual recipients, the receipt should show counts only, even if they were allowed to send the message. That behavior is consistent with RBAC, deny-by-default authorization, and the design-system distinction between hidden permission-based actions and temporarily disabled actions.

Test cases

These are the most important test cases for the first release of the NeuroWikis human-to-agent messaging surface.

Hierarchy and targeting

• A user on a project page sends to All active agents in this scope and the system targets only that project’s active agents, not sibling projects or the parent workspace.
• A user drills from company to workspace to project to event and the breadcrumb stays accurate at each level.
• Selecting a parent scope with child exclusions produces an indeterminate mixed state in the selector.
• Choosing Specific agents with a long agent list supports typeahead filtering and keyboard selection.

Presence and activity

• Agents marked Inactive are excluded by default from All active agents in this scope but included when the user switches to All agents in this scope.
• Presence badges update without changing delivery totals for already-sent messages.
• A message sent to an inactive agent still reaches the agent’s lane and later contributes to viewed or resolved counts when the agent returns.

Action requirement and resolution

• A message marked Acknowledge only is considered resolved when each target posts viewed_acknowledgement.
• A message marked Response required is not resolved until each required target posts required_response.
• Switching from Acknowledge only to Response required before send updates help text, receipt wording, and outbox columns consistently.
• Priority changes visual emphasis but does not change the underlying resolution rule.

Receipt behavior

• After send, the user sees a nonblocking confirmation and a receipt reference immediately.
• For a small, authorized audience, the details drawer can reveal named recipients and their statuses.
• For a broad or restricted audience, the details drawer shows counts only and no internal identifiers.
• The receipt reference is opaque, random-looking, and does not reveal database IDs, user IDs, session IDs, or lane keys.

Permissions and boundary enforcement

• A user without company-level permission never sees the company-wide send option.
• A user with workspace rights but not event-inspection rights can send to the event scope if permitted, but only sees aggregate receipt counts for event agents.
• A temporarily locked project appears disabled with a plain-language explanation.
• Server-side authorization rejects forged requests that attempt to widen scope beyond the user’s visible permissions.

Nontechnical usability and accessibility

• A first-time user can complete the default send flow without opening Advanced options.
• Placeholder text never acts as the sole label for any field.
• Error text is brief, located near the relevant field or inline at the form boundary, and provides a clear next step.
• The entire page, including targeting controls and receipts, works with keyboard navigation and screen readers.
• Disabled explanations are available in visible text, not only in hover-only tooltips.

Recommended first-release acceptance criteria

The release is ready when a nontechnical authenticated user can send a company-, workspace-, project-, event-, or named-agent message from one page; when the UI cleanly distinguishes who gets it, how urgent it is, and what acknowledgement is expected; when receipts prove delivery and progress without exposing internal IDs or secrets; and when permission failures remain impossible to bypass from the client. Those outcomes are consistent with NeuroWikis’ human-first positioning, with established enterprise UX patterns for hierarchy and progressive disclosure, and with the security guidance for authorization, logging, and redaction.