System Messages
A classification framework for non-conversational messages in the Microsoft Copilot chat surface. Covers 4 categories, 5 visual types, content guidelines, behavior rules, and 16 scenario mappings.
Overview
A system message is any message displayed within the chat surface that originates from the system — not from the user and not from Copilot. System messages sit outside the normal conversational flow and serve four distinct purposes:
A user or system action that changed the state of the conversation has completed.
e.g., Saved as agent, stopped responding, regenerated with a different model
A mode, session, or time period has started or ended, creating a structural break in the timeline.
e.g., Screen sharing ended, voice chat ended, date changed
A condition about ownership, permissions, visibility, or access — either conversation-wide or at a specific point in the timeline.
e.g., Someone shared this chat with you, this chat is read-only, messages beyond this point are only visible to you
The system solicits user input about an experience, feature, or interaction quality.
e.g., How is Copilot performing? (1–5 scale), Rate this voice session
Never has a Copilot avatar, never appears in a chat bubble, and never implies Copilot is speaking.
Positioned relative to the messages around them, contextual to where they appear.
Confirms an action, marks a transition, establishes a boundary, or communicates a caveat.
System messages are never attributed to Copilot. They have no avatar, no "Copilot" label, and no conversational framing. They are from the system, presented as neutral facts.
What is NOT a system message
Several patterns in the chat surface may look similar to system messages but serve different purposes and use different treatments.
| Scenario | Correct Pattern | Why |
|---|---|---|
| Copilot performing an action visible in the main canvas (e.g., generating a document, editing a slide) | Chat Output | The action and its result are part of the conversational exchange. Copilot is responding to a user request. |
| System-level errors (e.g., "Copilot is unavailable," network failure) | Message Bar | These are application-level states that affect the entire surface, not specific to a point in the chat timeline. |
| UI state changes (e.g., suggestion chips collapsing, input field resizing) | UI Behavior | These are visual state transitions of interactive components, not informational messages. |
| Transient action feedback (e.g., "Response copied," "Feedback submitted") | Toast | These confirm micro-interactions that have no lasting impact on the conversation. The action doesn’t change the state of the chat or system — it’s momentary UI feedback that can safely disappear. |
Classification Taxonomy
Every system message falls into exactly one of four categories. Each category maps to one or more visual types and answers a different question:
What just happened?
Something the user or system did has completed. The message is a receipt.
What just started or ended?
A mode, session, or time period has transitioned. The divider separates before from after.
What should I know about visibility or access?
A condition about ownership, permissions, visibility, or access — either conversation-wide (Banner) or at a specific point (Inline Notice).
How was this experience?
The system solicits user input about an experience, feature, or interaction quality. Unlike other categories, feedback messages are interactive.
Confirmation
Communicates that something happened. The action is complete; the message is a receipt. Specifically, Confirmations are for state-changing actions — actions that alter the conversation, create something new, or change how the system behaves.
- Always appears at the point in the timeline where the action occurred
- Never requires user response
- May include an optional action link (e.g., "Give feedback") but the link is supplementary, not primary
Examples: "Saved as agent," "Stopped responding," "Regenerated with GPT-4"
What qualifies as an Confirmation?
The test is timeline significance: if you returned to this conversation tomorrow, would you need to know this action happened?
| Action | Timeline impact? | Pattern |
|---|---|---|
| Save as agent | Yes | Confirmation — a new entity was created |
| Stop responding | Yes | Confirmation — the conversation flow was altered |
| Regenerate with GPT-4 | Yes | Confirmation — the response below uses a different model |
| Copy response | No | Toast — clipboard is transient, nothing in the chat changed |
| Share response | No | Toast — sharing happens outside the chat |
| Thumbs up / down | No | Toast — feedback is captured elsewhere |
Both confirm a completed action, but they differ in scope. Confirmations confirm system/operational actions that change state (save, stop, regenerate, export). Toasts confirm transient micro-interactions with no lasting impact (copy, share, like). Toasts live outside the timeline as ephemeral overlays. Confirmations live inside the timeline as permanent records.
Confirmation vs. Chat Output
Not every action in the chat is a system message. If Copilot is performing work and showing you the result as part of conversation, that's a Chat Output — not a system message.
| System message (Confirmation) | NOT a system message (Chat Output) |
|---|---|
| Saved as Research Assistant | "Here's your research summary..." |
| Stopped responding | Copilot generating a document |
| Regenerated with GPT-4 | Copilot editing a slide |
State Change
Marks a structural break in the conversation timeline. The chat had a mode or session active, and it has now ended (or begun).
- Visually spans the full width of the chat surface
- Acts as a separator between what came before and what comes after
- May include a timestamp or session label
Examples: "Screen sharing ended," "Voice chat ended," "February 23, 2026"
Notice
Communicates a condition about ownership, permissions, visibility, or access. Notices come in two forms depending on scope:
- Conversation-wide (Banner): Applies to the entire conversation. Appears at the top of the chat surface, above all messages. May be dismissible if non-critical after first read.
- Point-specific (Inline Notice): Marks a specific point in the timeline where visibility or interaction rules change. Always includes a directional reference ("beyond this point," "from here"). Persistent — never dismissible, because the boundary condition is permanent.
Examples: "Mona Kane shared this chat with you," "This chat is read-only," "Messages beyond this point are only visible to you"
Feedback
Solicits user input about an experience, feature, or interaction quality. Unlike the other three categories which are purely informational, feedback messages are interactive — they expect a response.
- Triggered by the system at determined intervals — not tied to a specific user action
- May appear after specific interaction types (e.g., after a voice agent session)
- Always dismissible — the user can skip or ignore the prompt
- Collapses to a confirmation after submission (e.g., "Thanks for your feedback")
Examples: "How is Copilot performing?" (1–5 scale), "Rate this voice session"
Thumbs up/down on individual responses is a Toast — it's a transient micro-interaction confirming the feedback was captured. A Feedback message is different: it's a system-initiated prompt that asks the user to evaluate a broader experience, not a single response.
Decision Tree
Use this flowchart to classify any new scenario:
Decision principles
1. Mutual exclusivity. Every scenario maps to exactly one category. If a scenario seems to fit two, use the more specific one (Confirmation > State Change > Notice > Feedback).
2. Timeline specificity. If the message is tied to a specific point in the chat timeline, it's not an Notice. Notices apply globally.
3. Action vs. state. If something "happened" (verb, past tense), it's likely an Confirmation. If something "is" (state, present tense), it's likely an Notice.
Visual Anatomy
Each of the four system message categories maps to one or more visual types. Below are the component specifications, token references, and live rendered examples.
Inline Notice — Confirmation
Used for action confirmations. Lightweight, non-interruptive.
| Element | Required | Description |
|---|---|---|
| Icon | Yes | 16px icon indicating the action type. Positioned left of the text. |
| Message text | Yes | Single sentence describing the completed action. |
| Entity name | Conditional | Bold text for the specific entity involved (e.g., agent name, model name). |
| Action link | Optional | Tertiary text link for supplementary actions (e.g., "Give feedback"). |
Message text: colorNeutralForeground2 Body 2 / regular
Entity name: colorNeutralForeground1 Body 2 / semibold
Action link: colorBrandForeground1 Body 2 / regular
Icon: colorNeutralForeground3 16px
Container: No background, no border, no card. Spacing: 8px compact, 12px standard.
Divider — State Change
Used to mark structural breaks in the timeline. Visually separates "before" from "after."
| Element | Required | Description |
|---|---|---|
| Divider line | Yes | Full-width horizontal rule spanning the chat content area. |
| Label text | Optional | Centered text sitting on top of the divider line (e.g., "Screen sharing ended"). |
| Timestamp | Optional | Time or date displayed alongside or replacing the label. |
| Icon | Optional | 16px icon to the left of the label for additional context. |
Label text: colorNeutralForeground3 Caption 1 / regular (12px/16px)
Line: 1px solid colorNeutralStroke2
Spacing: 16px above and below.
Banner & Inline Notice — Notice
Notice uses two visual expressions depending on scope.
Banner — conversation-wide
Used to communicate conversation-wide conditions. Prominent, positioned at the top.
| Element | Required | Description |
|---|---|---|
| Container | Yes | Full-width background fill spanning the chat surface. |
| Icon | Yes | 16px icon indicating the notice type (e.g., info, warning). |
| Message text | Yes | Single sentence describing the access condition. |
| Entity name | Conditional | Bold text for specific entities (e.g., person name, org name). |
| Dismiss button | Optional | "X" button to dismiss the banner after reading. |
| Action link | Optional | Link for further action (e.g., "Learn more"). |
Info background: colorNeutralBackground4
Warning background: colorPaletteYellowBackground1
Info icon: colorNeutralForeground2
Warning icon: colorPaletteYellowForeground1
Text: colorNeutralForeground1 Body 2 / regular. Entity: semibold.
Layout: Pinned to top, full width, 12px internal padding, no border-radius.
Inline Notice — point-specific
Used to indicate a change in visibility or interaction rules at a specific point in the timeline.
| Element | Required | Description |
|---|---|---|
| Icon | Yes | 16px icon indicating the boundary type (e.g., lock icon for visibility). |
| Message text | Yes | Single sentence describing the boundary condition. |
| Divider line | Optional | A subtle horizontal line above or below the text to reinforce the boundary. |
Message text: colorNeutralForeground3 Caption 1 / regular (12px/16px)
Icon: colorNeutralForeground3 16px
Container: No background. Whitespace + optional divider for separation. Spacing: 16px above and below.
Feedback Card — Feedback
Used to solicit user input about an experience or interaction. The only interactive system message type — it contains response controls (rating scale, buttons) and expects user action.
| Element | Required | Description |
|---|---|---|
| Container | Yes | Rounded card with subtle background and border. Visually distinct from chat bubbles. |
| Icon | Yes | 16px icon indicating the feedback type (e.g., star for rating). Positioned top-left. |
| Question text | Yes | Short, direct question about the experience. Semibold weight to distinguish from body text. |
| Rating controls | Yes | Interactive input — numbered scale (1–5), star rating, or thumbs up/down. Must be clearly tappable. |
| Scale labels | Optional | Anchor labels at each end of the scale (e.g., "Not helpful" / "Very helpful"). |
| Dismiss button | Yes | "X" button to dismiss the card without responding. Feedback is always optional. |
Question text: colorNeutralForeground1 Body 2 / semibold
Scale labels: colorNeutralForeground4 Caption 1 / regular
Icon: colorNeutralForeground3 16px
Container: colorNeutralBackground4 with 1px colorNeutralStroke2 border. Border-radius: 8px. Padding: 12px 16px.
Rating buttons: 32×32px, 1px border colorNeutralStroke2, white fill. On hover: colorNeutralBackground4.
Content Guidelines
Tense
| Situation | Tense | Example |
|---|---|---|
| An action just completed | Past tense | "Saved as My Agent" |
| A session or mode ended | Past tense | "Screen sharing ended" |
| An ongoing condition or state | Present tense | "Messages beyond this point are only visible to you" |
| Ownership or access info | Past tense for the action, present for the state | "Mona Kane shared this chat with you" |
| Soliciting feedback | Present tense (question form) | "How is Copilot performing?" |
Brevity
- One sentence maximum. No periods at the end unless the sentence is structurally complex enough to require one.
- Prefer fragments over full sentences when the meaning is clear:
Saved as My Agentnot "Your response has been saved as an agent called My Agent." - Never include redundant phrasing like "Please note that" or "This is to inform you that."
Bold formatting
Bold the specific entity name when one is present:
- "Saved as Research Assistant"
- "Regenerated with GPT-4"
- "Mona Kane shared this chat with you"
Do not bold generic descriptions. "Stopped responding" has no entity name to bold. "Screen sharing ended" has no entity name to bold.
Action links
- Use action links sparingly — only when there's a meaningful follow-up action the user might want to take.
- Phrase as verbs: "Give feedback," "Learn more," "Undo"
- Action links are always tertiary-styled text links, never buttons.
Attribution
System messages are never attributed to Copilot. They have no avatar, no "Copilot" label, and no conversational framing. They are from the system, presented as neutral facts.
Quick reference
| Rule | Guideline |
|---|---|
| Length | One sentence max. Prefer fragments when clear. |
| Tense | Past for completed actions ("Saved as..."). Present for ongoing states ("Messages beyond this point..."). |
| Bold | Bold the entity name: Saved as Research Assistant. Don't bold generic descriptions. |
| Links | Verb-phrased, sparingly used: "Give feedback," "Undo," "Learn more" |
| Attribution | Never from Copilot. No avatar, no label, no chat bubble. |
| Periods | No period unless the sentence is structurally complex. |
Behavior
Persistence
| Visual Type | Persistence | Rationale |
|---|---|---|
| Inline Notice | Permanent | Part of the timeline history. Removing it would create a gap in the record of what happened. |
| Divider | Permanent | Structural marker. The session boundary is a fact; it doesn't expire. |
| Inline Notice | Permanent | The boundary condition is ongoing. Removing it would obscure the visibility change. |
| Banner | Dismissible (optional) | The access condition persists, but the user may not need the reminder after first read. If dismissed, it should be accessible via a "chat info" affordance. |
| Feedback Card | Dismissible | Feedback is always optional. The card is dismissed after submission or when the user closes it. After submission, collapses to a brief confirmation. |
Timing
- Confirmation: Appears immediately after the action completes, at the point in the timeline where the action occurred.
- State Change: Appears immediately when the session or mode ends (or begins).
- Notice (conversation-wide): Appears when the chat is opened, before any messages are scrolled into view.
- Notice (point-specific): Appears at the exact point in the timeline where the boundary takes effect.
- Feedback: Appears at system-determined intervals, or immediately after a specific interaction type ends (e.g., voice session).
Scroll behavior
| Visual Type | Behavior |
|---|---|
| Inline Notice, Divider, Inline Notice, Feedback Card | Scroll with the chat content. They are part of the timeline. |
| Banner | Pinned to the top of the chat surface. Does not scroll. Remains visible regardless of scroll position (until dismissed). |
Interaction
- System messages are not interactive by default. They do not have hover states, focus states, or click targets (except for optional action links and dismiss buttons).
- Action links follow standard link interaction patterns (hover underline, focus ring).
- System messages are not selectable as text (they are UI elements, not content).
Animation
- System messages appear without animation. They are inserted into the timeline or pinned to the top as part of a state change.
- Dismissing a banner uses a standard fade-out (200ms, ease-out).
Behavior summary
| Visual Type | Persists? | Scrolls? | Animated? |
|---|---|---|---|
| Inline Notice | Permanent | Yes (in timeline) | No |
| Divider | Permanent | Yes (in timeline) | No |
| Inline Notice | Permanent | Yes (in timeline) | No |
| Banner | Dismissible | No (pinned to top) | Fade-out on dismiss (200ms ease-out) |
| Feedback Card | Dismissible | Yes (in timeline) | Collapse on submit (200ms ease-out) |
Related pattern: UI State Collapse
When the user bypasses an interactive suggestion (e.g., types a new message instead of tapping a suggestion chip), the suggestion UI should collapse to avoid cluttering the timeline. This is a UI behavior, not a system message.
The collapsed state shows a brief label (e.g., "3 suggestions") or collapses entirely. No system message is generated — the collapse is a UI behavior, not an informational event.
Scenarios
This section maps every audited scenario (and anticipated future scenarios) to the framework. For each scenario, it identifies the correct category, visual type, and what changes are needed from the current implementation.
Audited Scenarios
These 7 scenarios have been observed and audited against the current Copilot implementation.
Summary of Changes
| # | Scenario | Change Level | Action |
|---|---|---|---|
| 1 | Save as Agent | Major | Replace Copilot chat response with Inline Notice |
| 2 | Suggestions Bypassed | Major | Implement UI collapse behavior (not a system message) |
| 3 | Screen/Voice Ended | Minor | Formalize existing Divider pattern |
| 4 | Stopped Copilot | Minor | Align with Inline Notice spec |
| 5 | Regenerated with Model | Minor | Align with Inline Notice spec |
| 6 | Shared Chat | Minor | Formalize Banner pattern; reconsider warning-level styling |
| 7 | Visibility Boundary | Minor | Formalize Inline Notice pattern (Notice) |
Future Scenarios
The following scenarios have not been observed in the current audit but are anticipated. Each is pre-classified using the framework's decision tree.
Validation
The framework was validated against all 16 scenarios (7 audited + 9 future) to ensure consistency, completeness, and mutual exclusivity.
Mutual exclusivity check
Every scenario maps to exactly one category. No scenario was ambiguous between two categories.
| Category | Scenarios |
|---|---|
| Confirmation | #1 Save as Agent, #4 Stopped Copilot, #5 Regenerated, Plugin Installed, File Upload, Chat Exported |
| State Change | #3 Screen/Voice Ended, Conversation Transferred, Date Boundary |
| Notice | #6 Shared Chat, #7 Visibility Boundary, Admin-Restricted Topic, Context Window Limit |
| Feedback | System-Initiated Feedback Prompt, Post-Session Feedback |
| Not a System Message | #2 Suggestions Bypassed (UI State Collapse) |
Decision tree consistency
Each scenario was run through the decision tree and produced the same result as the manual classification. No conflicts or ambiguities were found.
Visual type purity
No visual type is used for contradictory purposes:
- Inline Notice — always confirms a completed action
- Divider — always marks a structural break
- Banner — always communicates conversation-wide access conditions
- Inline Notice — always establishes a point-specific visibility/interaction change
- Feedback Card — always solicits user input about an experience
Notice is the only category with two visual types. Banner handles conversation-wide conditions (pinned to top), while Inline Notice handles point-specific visibility changes (in the timeline). Both communicate access/visibility information — the scope determines which visual expression is used.
Feedback Card is the only visual type that expects user input. All other system messages are informational — they tell the user something. Feedback Cards ask the user something. This makes them uniquely dismissible and collapsible after interaction.
Coverage metrics
| Check | Result |
|---|---|
| Mutual exclusivity | Every scenario maps to exactly one category |
| Decision tree consistency | All scenarios produce same result via tree and manual classification |
| Visual type purity | Each type serves one purpose; Notice uses two visual expressions (Banner + Inline Notice) |
| Coverage | 16/16 scenarios classified across 4 categories |