Agents UX Feedback (Aug 2026)

~800 posts of internal feedback across four months point to five clusters of UX friction with Mattermost's agents today. Underneath, the evidence keeps asking for the same set of HMT primitives to be defined. Ten design-forcing questions surface from that — the input Design needs to build the UX vision that makes Trail Agents' "feel like teammates" ambition concrete.

Key takeaways for making agents feel like teammates:

• Presence and state legibility. Users need to reliably tell whether an agent is thinking, stuck, waiting, or done — for themselves and for onlookers in the channel.

• Addressability and conversational continuity. Agents need to know when they're being spoken to — including mid-thread with the same agent, without requiring an @mention every turn. Works implicitly for 1H+1A; unresolved for multi-agent.

• Turn-taking and attention. How process is shown to onlookers vs. participants, and how output is budgeted to human attention — both process and prose.

• Correctability and control. Humans need to steer, stop, undo, and intervene mid-flight without restarting the whole run.

• Mutual awareness and grounding. Users need to know what agents can do, what they know, and where their answers came from.

• Governance and provenance as UX. Users and admins need to see what the agent retrieved, on what authority, and with what policy active — visible and auditable, not buried in logs.

• Memory and continuity. What the agent remembers, for whom, and across which surfaces — with memory scopes that respect individuals, threads, channels, and teams without bleeding between them.

Ten design-forcing questions the vision work needs to answer (expanded in Design-forcing questions below):

1. What does "feel like teammates" mean concretely in a Mattermost channel?

2. Who is the agent addressable to, and by whom? And once addressed, does it stay addressed?

3. How does agent state render to onlookers vs. participants?

4. What's the pattern for humans steering agents mid-flight?

5. How is autonomy granted — statically or through earned trust?

6. What are the primitives for multi-agent coordination in a channel?

7. What are the UX primitives for governance and provenance?

8. What does the agent remember, and for whom? How does memory scope to individuals, threads, channels, and teams?

9. Should agent output be text, or first-class interactive artifacts?

10. What can the agent do in Mattermost itself — not just from it?

On Aug 24, Ian asked in ~broken-windows whether there's a design vision for Human-Machine Teaming in Mattermost, and — with the current UX — struggled to file bugs because he couldn't tell what was intentional. Christopher confirmed there's no master HMT design doc.

The platform and positioning vision for Trail Agents is well-articulated in Nick and Chris's Mattermost AI Trail — Kubernetes-native runtime, sovereign deployment, framework-agnostic, DISC-aligned competitive moat. Trail's stated UX ambition is that "agents feel like teammates" — they respond in threads, react to events, take actions with a rich streaming chat experience. What hasn't been written yet is the design layer that turns "feel like teammates" into something concrete for Mattermost's chat surface specifically.

This doc doesn't fill that gap. It uses the feedback we already have to make the case for doing the work, and to surface the questions Design needs to answer to do it well. It's input to the conversation Jason asked for at the next Agents standup, not the conclusion of it.

Synthesized from six sources over the last four to eight months:

• ~agents-broken-windows (~500 posts, Apr → Aug 2026)

• ~broken-windows agent-scoped threads

• ~3M: Mattermost on Mattermost and Microsoft (Nov 2025 → Aug 2026)

• ~customer-feedback (agent-scoped threads, Jan → Aug 2026)

• Bill Anderson's July 29 PM memo on the PDE Intake agent

• Ian Tien's Aug 24 HMT thread

Contributors span designers, PMs, engineers, admins, executives, and — via the customer-feedback channel — customer-facing staff summarizing customer conversations. Themes were kept only if they appeared in ≥2 independent voices; single-source items are captured in the appendix. Customer feedback is summarized without naming specific customers in this doc; source threads on Hub are linked inline for readers with access who want the direct context.

Explicitly out of scope: Automations plugin, model behavior tuning, MCP protocol design, RAG infrastructure. Some findings brush these; UX-owned work is the frame.

Five clusters, kept as evidence rather than proposed solutions. Each is what people actually said. What the clusters mean together comes after.

Evidence

• Bill Anderson (PM memo, §3.5): No progress indication during 15–35s agent runs.

• Pablo (May 26): "Second time I see Matty do this when waiting for approval… reloading sometimes shows the button, sometimes not."

• Matthew Birtch (Jun 22): Two threads with blank Matty responses; response finally arrived after 5 minutes.

• Asaad (May 6): "Bro, why does it keep saying that? Is it something I typed, or is the agent down?"

• Vishal (May 20): Prompt-size limit exceeded → "Failed to save agent. Please try again." No indication of the real problem.

• gj.yoo (Apr 9): "Failed to call AI agent." — generic, unactionable, in Rewrite flow.

• Vishal + Katie (Aug 11): CIA agent's MCP had disconnected weeks earlier; no admin was notified; agent kept "working" but silently useless.

• Sven (May 20): "Sorry! The LLM did not return a result." — verbatim server text with no follow-up path.

Pattern. State indicators exist across most agent surfaces — the problem is they work inconsistently and don't always map to the real state. Approval buttons that don't render on reload, spinners that never resolve, silent MCP disconnections, verbatim server errors surfaced to users — the same visual output covers "thinking," "stuck," "waiting," "degraded," and "dead," so users can't reliably distinguish them. Much of this is a reliability problem more than a design gap. The design question underneath, though, is worth naming: what should the indicator vocabulary be, and how consistently does it need to map to actual agent states across every surface where an agent appears?

Evidence

• Marco (May 7): Three complaints in one post — selection doesn't persist, dropdown scrolls beyond viewport, ordering is non-deterministic.

• Corey (May 18): "Each time I improve writing I must select Matty because Aria fails a lot."

• Sven (May 18) → MM-68856: AI Actions doesn't honor system default agent.

• MM-68323: Sparkle menu loses focus, wipes selection.

• Harshil (Jun 11): Long agent names truncated.

• Katie (May 20): "No descriptions for agents — no way to know what they specialize in."

• Vishal (Jun 11): "Mark agents as favorites from the RHS."

• Guillermo (May 13): "Column tagging who created the agent" — for improvement contact.

• Harshil (May 21): "Not all agents should be visible to all."

• Ian (Jan 8): "@ai not working on Hub — no auto-complete, it's as if we had zero AI in Mattermost."

• Carrie (Jan 8): "We need to make the AI name more self-discoverable somehow."

• Nick (Nov 11): Bot @mention autocomplete requires channel membership; plugin bots don't actually need it but the UI treats them like user bots.

• Customer feedback (Mar 2026, thread): Enterprise SOC customer flagged bot slash command discoverability — "/" autocomplete for bot commands is not well-known; requested better in-product discovery for users to leverage bots more effectively.

• Internal design proposal (months ago): A designer demoed an "Agents view" concept — a directory-level UI for browsing agents, their capabilities, ownership, and access — as a solution to the picker + discovery + capability visibility problems above. Not built. Still one of the bigger UX gaps.

Pattern. Selection is a per-invocation papercut across every AI surface. As agent count grows (Nick noted 90 new tools shipped in 11.10, and agent count is following), the friction compounds. It's also the surface where "which agent am I even talking to" gets negotiated — a question that matters more, not less, as the roster grows. A dedicated Agents view was proposed months ago and remains unbuilt.

Two related but distinct problems.

Evidence

• Harshil (Jul 23): "The AI bot prompts and process posts should only be visible to the person who triggered the command. It pollutes the threads."

• Sven (Jul 23): "Whenever a more complex prompt is invoked it turns me off from continuing to follow the thread. So much noise and wasted vertical space for things that are essentially of little interest to me."

• Sven (Jul 23): "Maybe 20–30% of the displayed data is of actual value to me."

• Asaad (Apr 17): "Shouldn't even be separate posts to begin with. All in one post. Not sure if we need to show all tool calls visibly, rather have all in a hidden drop-down."

• Joram (Apr 17): "It'd be great if these auto-collapsed like they do in Cursor/Claude."

• Nick (Jul 23): On the other side of the tension — "intentionally visible to onlookers to provide visual feedback that something is happening." Defending something real: onlookers need to see the agent hasn't died.

• Customer feedback (Mar 2026, thread): Enterprise SOC customer requested alert threading via bots — detect repeated alerts from the same source, thread under a root post, and clean up extraneous messages while preserving audit logs.

• In flight: Nick is working on an expand/collapse model similar to Cursor's tool-call collapsing pattern (reference), which addresses this tension directly — process visible by default for onlookers, collapsible so participants can find the answer. Right direction.

Evidence

• mattycode's "Broken Window Assessment" template — consistently produces 30–50 line structured responses (steps to repro, expected, actual, project, note-to-fixing-engineer) for what is often a two-line UI polish acknowledgement.

• Copilot laptop-spec answer (Nov 11, ~3M): Ian asked a simple recommendation question, got 40+ lines with sections, subsections, and Japan-specific footnotes. dschalla's next reply: one link to the handbook.

• Copilot cert-error diagnosis (Nov 6, ~3M): ~30 lines across 6 subsections speculating on cause. dschalla's earlier one-line hint got Ian to the answer.

• General pattern: agents don't calibrate length or format to question complexity. Every response gets maximum-effort treatment.

Pattern (both variants). Both share a root cause: agent output isn't budgeted to the human's attention. Whether the noise is process or prose, users pay the same cost — scanning past filler to find what they need. Nick's onlooker-legibility concern is real, and it's distinct from the answer-verbosity concern; the vision has to hold both. 3a has a fix in flight (expand/collapse). 3b is largely a prompt/agent-config concern rather than a UX-pattern problem — the primary fix lives at the agent-config layer, where "reply brief" defaults, response length preferences, or a baked-in system-wide brevity default would move the needle more than any UI affordance. Design's role in 3b is limited to defaults, preferences, and truncation-with-expand — but if verbosity is systemic across agents, a platform-level default is worth considering.

Evidence

• Guillermo (Jul 24) → MM-69972: Approval timeout confuses the LLM; approval prompts inconsistent (sometimes shown, sometimes not).

• Pablo (May 26): Stuck approval state; reload sometimes reveals the button, sometimes doesn't.

• Harshil (Jan 5): Cannot undo AI Rewrite — Cmd+Z doesn't restore original text.

• Matthew Birtch (Apr 13): Stop-generating button doesn't work while agent is thinking (mobile iOS).

• Vishal (May 15): Rewrite fails, send button disabled — user must refresh the page.

• Corey (Jun 25): Same — "when it hits an error it disables the send button."

• Paul (Jul 20): "Despite repeatedly pushing the IT_support bot to only tag IT staff… it continues to tag people." User has no way to correct behavior in-flight — and the correction doesn't persist across turns either.

• Paul (Jun 1) + Christopher (Aug 24): The "you must @mention the agent" ephemeral is a workaround for a deeper gap: agents have no conversational continuity in threads. Users' mental model is "we're in a conversation"; the agent's model is "you must invoke me every turn." Christopher confirmed the ephemeral fires deliberately because "many people forget" — but it also fires when unintended, and it doesn't fix the underlying issue. Once a user invokes an agent in a thread, subsequent messages contextually directed at that agent should be picked up without re-mentioning; the agent should track thread context and infer when it's being addressed based on message relevance.

• Ian (Aug 24): The HMT concern in its entirety.

Pattern. The human can invoke; correcting requires restart. In every case where an agent went sideways, the human's only recourse was to abort and start over — or accept the wrong output. The primitives for intervening mid-flight aren't there, and even the primitives for staying in an ongoing conversation with the agent aren't there. Notably, corrections also don't persist across turns — the same mistake gets made again on the next invocation.

Evidence

• Ian (Nov 11, ~3M): Copilot inferred "MLT" from context on Ian's first prompt — knowing who Ian is, what team he's on, what MLT means in that org context. Asked what it would take for Matty to work like this. Nick's answer: 3 parts (act, ground in our data, backfill Mattermost-specific context). We have part 1.

• Bill (PM memo, §2.1): Web search unavailable in Automations context — capability regression.

• Bill (PM memo): No vision/attachment support (screenshots).

• Ian (Nov 6): "Just paste in the screenshot" as a natural expectation.

• Katie (May 20): "No information on what agents specialize in."

• Guillermo (May 13): "Column tagging who created the agent."

• Sven (Apr 9): "Search root posts only" — capability gap.

• Vishal (Jul 31): search_posts tool has silent-wrong-answer failure modes. LLM confidently reports "no activity" when there is some.

• Matthew Birtch + Christopher (Apr 22 → Jun 4, thread): Semantic/RAG search on Hub returns 5–10+ year old posts as top results for prompts explicitly asking for "the latest" or "recent." Reported at ~6-week intervals with no resolution. Christopher confirmed on Jun 4 that indexing has been "start and stop on hub." RAG-based grounding doesn't reliably work on our largest deployment, and users can't tell whether it's a bug, misconfiguration, or incomplete indexing.

• Matthew Birtch (May 26): "I see Jira but not Confluence in the tools list. Matty tells me it is connected. So is the tools list wrong?"

• Internal UX team observation: Connector/tool access failure states are dead-ends. When an agent doesn't have access to an app, users hit a "connector not available" message with no next action. The affordance should tell the user clearly what's missing and surface inline CTAs to connect directly from chat (Zoom, Jira, GitHub, etc.). Turns a failure state into an actionable moment.

• Internal UX team observation: Users expect Mattermost agents to know and operate the Mattermost platform itself — "set my autoresponder for next week, I'm on PTO," "mute this channel until Monday," "add Sarah to this channel," "create a channel for the launch team." The Mattermost MCP server exposes many of these actions to agents (channel membership, status, DND, post creation, and dozens more), so much of the capability foundation exists. Coverage isn't fully complete — some user-expected actions may not yet be exposed — but the bigger gap is UX: users don't know what platform actions the agent can take on their behalf, don't have a clear pattern for asking, and don't have a clean authorization model for granting the scope.

• Customer feedback (Feb 2026, thread): Very large enterprise deployment observed single-node chokepoints during AI Search re-indexing and suggested batched indexing (by row count or date). Same class of grounding-at-scale problem as the Hub indexing issue.

• Customer feedback (Jul 2026, thread): Docs vs product mismatch — AI Agents docs list the feature as available from Entry level, but a lower-tier customer could configure AI services and couldn't actually use them due to the multi-LLM license gate. "Broken experience rather than a clear upgrade path."

Pattern. Users can't tell what an agent knows, where it got it, or what it can do — including what it can do to the Mattermost platform itself. Grounding fails at multiple layers — tool implementation (Vishal's search_posts case), indexing and infrastructure (semantic search on Hub, customer scale-of-indexing feedback), and data provenance (missing Confluence in tools list) — and users can't distinguish between "the agent doesn't know" and "the agent can't retrieve." For platform-native actions, the MCP provides most of the capability but there's no UX surface that tells users what the agent can operate on their behalf or how to authorize it. Failure states compound the problem — a "connector not available" dead-end is a missed opportunity to turn a stuck user into a resolved one.

Feedback from customer-facing conversations over the last 6–8 months reinforces the internal patterns and adds one dimension the internal clusters don't fully capture. Threads on Hub linked inline for readers with access.

Reinforcing the internal signal. Customers report the same friction internal users do: docs vs. product mismatches on plan eligibility, poor bot and slash-command discoverability, thread noise from alerts and process output, and unreliable retrieval at scale. Where internal users hit these as papercuts, customers hit them as adoption blockers.

Governance, provenance, and permissioning as UX concerns. This is the dimension the internal clusters point at but customer feedback names sharply. Customers building on Mattermost for governed AI use cases are treating agents as a governance surface, and the UX doesn't yet reflect that. One Enterprise customer building a governed AI layer built four things themselves that they'd expect from the platform: document-chunk-level access control, a governed RAG pipeline (pre-LLM access and classification checks), an AI compliance audit trail with provenance logging (chunks used, chunks blocked, policy active, token counts), and a document classification state machine. A Cloud POC customer preparing a Responsible Use of AI (RUAI) governance submission asked for AI architecture documentation, DPA clarity, pre-transmission PII filtering, and ABAC for Agents. Another customer with premium support actively probed the agent's cross-channel access controls — testing whether it could retrieve from channels their user didn't belong to — as part of a security and data privacy evaluation.

The pattern: customers are asking questions the current UX can't answer — what did the agent retrieve, on what authority, with what policy active, and can I see and audit that? These aren't polish concerns for the customers Trail is targeting. They're closer to gating requirements.

Positive signal worth naming. Customers who have engaged with the plugin at depth are generally positive on the answer quality and see clear value in the direction. The pressure isn't on whether to build agents; it's on how to build the UX around them well enough to trust with production workloads.

Look at all five together — and read them alongside the customer signal — and what emerges is a set of primitives the evidence keeps pointing at without naming:

• Presence and state legibility (from cluster 1) — is the agent alive, working, stuck, done? Does everyone in the conversation know that?

• Addressability and conversational continuity (from clusters 2 and 4) — who is being spoken to, how do others know who's part of the conversation, and does the agent stay "addressed" across a thread once invoked, or does every turn require re-invocation?

• Turn-taking and attention (from cluster 3) — when does the agent respond, when does it defer, what does it do while onlookers watch, how much of its process is theirs to see?

• Correctability and control (from cluster 4) — can the human steer, stop, undo, or intervene without a full restart? Can they do it in-flight, or only between turns?

• Mutual awareness and grounding (from cluster 5) — what does the agent know, from where, and how do we (and the agent) know that it knows?

• Governance and provenance (from customer signal, reinforced by clusters 4 and 5) — what did the agent retrieve, on what authority, with what policy active, and how does that render as a visible, auditable UX surface rather than a log to grep?

• Memory and continuity (from clusters 4 and 5) — what does the agent remember about the user, the thread, the channel, the team? How do memory scopes stay separate so an individual's context doesn't leak into shared spaces, and shared context doesn't get overwritten by any one user's preferences?

These aren't the primitives of HMT. They're what the evidence is asking us to define. Whatever the vision ultimately says, it will need to have taken positions on each one.

Trail's ambition of "agents feel like teammates" reduces, in practice, to whether these primitives are in place. State legibility is what makes a teammate visible. Addressability and continuity are what make them speakable to. Turn-taking is what keeps the collaboration from becoming noise. Correctability is what makes teaming different from tool use. Grounding is what makes the teammate credible. Governance and provenance are what make the teammate trustable at production scale — especially for DISC customers. Memory is what turns transactional invocations into an accumulating working relationship — with individuals, in threads, across channels, and at the team level. The Trail platform gives us the runtime for teammates; the UX design layer is what would make them actually feel like ones.

The Agents team has shipped fast, and it shows. Nick and Chris's Trail Agents proposal articulates the platform vision, the product-market case, and the capability roadmap comprehensively. The competitive moat argument is well-made. The DISC customer alignment is explicit. The horizon includes cross-agent orchestration.

What hasn't been written yet is the UX design vision — the layer that would turn Trail's ambition of "agents feel like teammates" into a concrete answer for what teaming looks and feels like in Mattermost specifically. This isn't a criticism of anyone's work. It's what happens when platform velocity outpaces the design conversation, which is a good problem to have. Ian's Aug 24 question is that gap becoming visible; the customer signal above is the same gap seen from outside.

Three framings for the vision work to hold. Not conclusions.

Single-human-single-agent is the volume case. Multi-human-multi-agent is the design-forcing case. Most interactions in Mattermost today (and probably for a while) will be 1H+1A. But the primitives designed for 1H+1A have to scale into NH+NA without asking users to switch mental models. Trail names cross-agent orchestration as a long-term item. Design should shape the primitives before that lands, not after. A companion working doc, Agents UX: HMT Scenarios (working doc), is a scaffolded scenario library for pressure-testing the design-forcing questions against concrete multi-player, multi-agent shapes — filled in collaboratively during and after the working session.

Mattermost is inherently multi-user. Even 1H+1A on Mattermost usually has onlookers. Nick's on-record position — that agent process should be visible to non-invokers so they can see the agent hasn't died — is defending something real. Slack's framing for Slack Code makes the same point commercially: "great code shouldn't be a private conversation, with no context. Slack is already where that context lives, and where your team works with AI." Whatever the vision says, it can't treat teaming as a private affair between one invoker and one agent.

DISC and sovereign customers change the weighting. For the customers Trail is targeting, provenance, audit, correctability, and observability aren't just good UX — they're differentiators or compliance requirements. The customer signal above confirms this directly: customers are asking for governance and permissioning primitives today, not on a future roadmap. What might be polish for a Slack customer is closer to table stakes for a Mattermost DISC customer. The design vision should be calibrated to the higher bar.

Questions the vision work needs to answer. Each is anchored in something Trail claims, something the feedback surfaced, or something customers are asking for — paired with how others in the industry are framing the tradeoff. These are not answered here. They're what the standup should chew on.

Trail's central UX ambition, undefined. Slack ships explicit guidance on the platform-level equivalent: agent responses should be made in threads to prevent flooding the main conversation; related notifications organized into batches (five issue updates as one message, not five); responses in DMs and channels behaving differently, appropriate to the expectations of each space. Mattermost has to take a position on threading discipline, DM vs. channel behavior, and what "teammate" behaviorally means in each space.

Even in 1H+1A, addressability isn't quite implicit today — the human's conversational model ("we're in a thread together, you know I'm still talking to you") doesn't match the agent's invocation model ("you must @mention me every turn"). Paul's Jun 1 confusion is the concrete symptom; the ephemeral "you must @mention" is a workaround, not a fix. Whatever the vision says about multi-agent addressability has to first take a position on single-agent conversational continuity, or NH+NA design will inherit a broken 1H+1A foundation.

In NH+NA — which Trail names as long-term — addressability becomes the whole design problem. Group-chat agent patterns with multiple agents in a round-robin require explicit design for loop prevention, "done" signals, and careful limits on agent count to prevent runaway conversations (per Hatchworks' 2026 agent-UX pattern library). The current @mention model works for one agent per conversation with re-invocation each turn; it doesn't scale to multiple agents, and it doesn't feel like teaming even at one. Design has to decide what's addressable (agent by name, class of agent, task, conversation) and how addressing persists across turns.

Nick's position (visible process for onlookers) and Harshil/Sven's position (process dominates threads) are both correct about their side of the coin. Hiding process by default isn't the answer either — streaming tool output (showing tool inputs and outputs as they happen, rather than waiting for a complete agent response) is consistently cited by teams that shipped agentic products in 2025-2026 as the highest-value UX improvement per Zylos Research's May 2026 retrospective. The question is how presence signaling and detail-on-demand co-exist for two audiences of the same post: onlookers who need to know the agent is alive, and participants who need to find the answer. Nick's in-flight expand/collapse work (Cursor-style) points at the resolution.

Correctability is the primitive that distinguishes teaming from tool use. Today the human can invoke; correction requires a restart. Industry guidance on the approval side is that approval requests including the agent's accumulated context (what has been done, what this step does, what comes next) get faster and more accurate human decisions than terse ones. Paul's IT-support-bot example is what happens without in-flight steering: repeated corrections in the prompt don't take because they can't intervene during a run. The vision needs to say what steering primitives look like — approvals, interrupts, redirects, corrections mid-turn — and what failure recovery looks like when the agent hits a dead-end (a "connector not available" state should surface next actions, not just terminate).

The industry reference list often includes autonomy dials (Advisor / Co-pilot / Autopilot). Newer thinking is skeptical of user-configured autonomy. Progressive delegation — where the user's own approval history sets the pace of autonomy expansion, and the system earns permission through demonstrated reliability rather than demanding it at launch — is the framing NN Group's State of UX 2026 report identifies as directly addressing the trust problem. For DISC customers this is especially load-bearing — trust in an agent has to be earned and revocable, not toggled by a slider. Design should take a position on which model Mattermost supports, and whether that varies by customer profile.

Trail names cross-agent orchestration as long-term. Slack's agent design docs admit that some newer interaction patterns — including ambient agents and agent-to-agent handoffs — are still being defined and under exploration industry-wide. Anthropic's own coordination patterns (orchestrator-subagent, teams, handoffs, fan-out, debate) each produce different visible artifacts and require different UX affordances. This is the horizon where Design has the most room to shape the vision before implementation forces the shape.

Customers with governance requirements are asking questions the current UX can't answer: what did the agent retrieve, on what authority, with what policy active, and can I see and audit that? Multiple customers in the last 6–8 months have built these primitives themselves — permission-aware retrieval, provenance logging, classification state machines — because the platform didn't provide them. For DISC customers this sits closer to a gating requirement than a polish concern. Industry patterns for the enterprise agent space consistently call out planning visibility, tool-use disclosure, memory surfacing, and recovery routing as first-class UX responsibilities of the design team, not backend concerns to be surfaced later (per Fuselab Creative's May 2026 enterprise agent-UX patterns). The vision needs to say what governance affordances look like in the chat surface — how the agent surfaces its permissions context, how retrieval provenance renders to users, how policy and classification state are visible in the agent's actions, and how admins get an audit trail that's legible without leaving the platform.

Memory keeps surfacing in the evidence without being named. Paul's IT-support bot doesn't remember corrections across turns; the "@mention every turn" ephemeral exists because agents don't remember they're mid-conversation with someone. Ian's Nov 11 Copilot observation is partly memory — the agent knowing who Ian is and what team he's on, so "MLT" resolves without asking. The current model has essentially no memory beyond the immediate turn context, and users are hitting the ceiling of that immediately.

The multi-user dimensions are what make memory a design problem rather than a feature request. Memory has to scope carefully: individual (Matt prefers concise answers — does that apply to Matt's messages in a shared channel, or only in his DMs?), conversational (within a thread, the last N turns are known — where Paul's continuity gap lives), channel-scoped (the agent in ~feature-launch remembers "we decided the launch date is X" across everyone in the channel), team-scoped (org-wide conventions like "we use Jira not Linear" that all agents inherit), and DM-scoped (a 1:1 relationship that must not leak into channel contexts, even for the same user).

The design decisions have hard edges. Bleed: does Matt's stated preference reach Asaad's session in the same channel? Ownership: who can view, edit, or purge channel-scoped memory? Privacy: how does the agent avoid surfacing one user's confidential context to another? Governance: for DISC customers, what gets remembered, for how long, and who audits it? Industry patterns are still forming — Slack and Microsoft are early in defining workspace-level memory scopes; the enterprise agent space doesn't yet have a consensus pattern. Which means Design has room to shape this before implementation forces the shape.

Today, Mattermost agent output is prose in chat. Claude, Cursor, and other agent products treat certain outputs — charts, diagrams, forms, dashboards, code, drafts — as first-class artifacts: interactive, reusable, editable, shareable objects that live alongside the conversation rather than being embedded as text. The UX team has flagged artifacts as a meaningful gap in making agent output actually useful and interactive. This has been discussed internally more than once and remains unbuilt.

The vision needs to say whether Mattermost agents should produce artifacts, what types, how they render in threads, how they persist and get referenced later, and how they interact with the artifact-adjacent primitives Mattermost already has (Canvas, Playbooks, Boards). Or whether continued investment in chat-native prose output is the intentional direction — but that requires an answer to why. The industry is moving toward artifacts; Mattermost taking the other direction should be an explicit choice, not a defaults-based drift.

Users expect Mattermost agents to be platform-native operators, not just chat interlocutors. "Set my autoresponder for next week, I'm on PTO." "Add Sarah to this channel." "Mute this channel until Monday." "Create a channel for the launch team." "Set my status to focused until 3pm."

The capability piece is largely in place. The Mattermost MCP server exposes many of these actions to agents — channel membership, status, DND, muting, post creation, and dozens of others. Coverage isn't fully complete, and some user-expected actions may not yet be exposed via MCP, but the capability foundation is there.

The bigger design gap is UX, not capability. Users don't know which platform actions their agent can take on their behalf; there's no clear pattern for "agent, what can you do to my account?"; there's no clean authorization model for "agent, do this once vs. persistently vs. never." How does the agent surface its platform-action scope to the user? How does the user grant, revoke, or scope authorization? What's the model for admin-scoped agents vs. user-scoped ones? How does the audit trail render agent-executed platform actions differently from human-executed ones? What are the guardrails that keep an over-eager agent from setting the wrong autoresponder or archiving the wrong channel?

For DISC customers this is especially charged. An agent that can modify user or team settings, even at the user's request, needs a governance model as robust as the one for the human-executed equivalent — and probably more so, since the human's active presence at each action can't be assumed. The vision needs to say how MCP-exposed platform capabilities get discovered, authorized, audited, and undone — as a legible UX layer, not just a set of available tool calls. This connects directly to autonomy (Q5) and governance (Q7) — but is neither, because the underlying question is capability discovery and authorization UX.

This doc is scaffolding for the vision work, not the vision itself. To do that work well, Design needs:

• A working session with Chris and Nick to sync on the Trail roadmap, especially the timing of cross-agent orchestration and the constraints the sovereign/DISC customer profile puts on the design.

• Input from Asaad and Trevor on the primitives, per Jason's Aug 24 ask.

• Time. This isn't a sprint deliverable.

A companion working doc — Agents UX: HMT Scenarios (working doc) — is where the design-forcing questions get grounded in concrete multi-player, multi-agent scenarios. Scaffolded now, filled in collaboratively.

The evidence in this doc is the input. The design-forcing questions are the agenda. Trail Agents is the platform vision the design work has to serve. Nothing here should be read as a critique of what's been built — the opposite. The platform's velocity is what makes this design conversation possible now.

• ~agents-broken-windows (~500 posts, Apr 2 → Aug 24, 2026)

• ~broken-windows (agent-scoped searches)

• ~3M: Mattermost on Mattermost and Microsoft (Nov 2025 → Aug 2026)

• ~customer-feedback (agent-scoped searches, Jan → Aug 2026)

• Bill Anderson, PDE Intake Agent memo, Jul 29, 2026

• Ian Tien, "Unclear UX for Human-Machine Teaming" thread, Aug 24, 2026

• Nick Misasi & Christopher Speller, The Mattermost AI Trail

• CJK input in Agent input box (GJ Yoo, Aug 17, MM-70289 — fixed)

• Squished profile images in AI Actions selector (Nick, Aug 20)

• Persistent scrollbar in agent list (Harshil, Jun 22, MM-69410)

• Discard-changes modal appearing with no changes (Vishal, Jun 10, MM-69185)

• Header height mismatch (Matthew Birtch, Apr 23)

• "Improve writing" defaulting to Aria that always fails (Corey, multiple)

• ~ai crime channel javascript error (Paul/Dustin, Aug 7, still active)

• Playbooks regression dropping AI-seeded content (John Landells, Jun 17)

• AI Rewrite IME confirmation broken (Shigeru, Mar 2, MM-67749)

• AI Rewrite button real estate contention with formatting controls (long thread, Dec 2025 → Jun 2026)

• Default recap agent unclear (Dustin, May 4)

• Pre-v2 agents inherited by all sysadmins with no owner (Vishal, Apr 22 → Nick)