Microsoft Fluent and agent-design evidence profile
Type: System profile
Status: Active
Canonical for: Factual interpretation of preserved Microsoft Fluent and agent-design guidance
Depends on: corpus/microsoft/
Evidence boundary
Microsoft’s public evidence spans three connected but non-identical surfaces: Fluent foundations/components, Copilot design assets/content engineering, and Microsoft 365 agent-design guidance. The guidance tells teams to use Fluent, but the corpus does not expose every Copilot UI Kit implementation as public code. That boundary matters.
Four-question relevance
- Intent: strong human-facing agent/UX and content-engineering guidance, but limited DS component-selection intent for agent consumers.
- Structure: demonstrated APIs, tokens and Adaptive Card schemas; these express allowable implementation more than selection judgment.
- Retrieval: a public Fluent-specific semantic context layer is not established in the corpus.
- Constraint/evaluation: conventional tests exist; agent selection/composition evaluation is not established.
Microsoft is supporting rather than central for the primary research question.
AI product and agent experience
- Documented: Fluent’s design resources describe Copilot UI Kits as AI-focused components and patterns across web, iOS and Android, aligned with Fluent AI and OneCopilot Mobile. Fluent design resources
- Documented: Agent experiences are defined as complete interaction systems, not prompts. Microsoft names first-run expectation setting, active interaction, iterative refinement, context visibility, correction, regeneration, manual editing and recovery. Human-centered agent design
- Documented: Agents should be built for user intent, differentiated from humans and resistant to bias. Output should stay editable, controls for refinement visible, and language should avoid implying thought or feeling. Human-centered guidance, responsible-agent guidance
- Documented: Adaptive Cards turn responses into structured, interactive, JSON-defined UI with titles, bodies, actions and inputs that adapt across host surfaces. Cards may be standalone or paired with explanatory text. Adaptive Cards for agents
- Documented: Microsoft’s content engineering practice treats system prompts as designed behavior, organized around role, task, rules and examples. This expands design-system-adjacent work from UI copy into model-behavior content. Content engineering
- Documented: The AI-first Copilot architecture introduces interaction-level patterns beyond a component list. A simplified system
The preserved guidance is strong for onboarding, capability framing, iterative correction, contextual grounding and structured responses. It is less explicit about agent plans, fine-grained permissions, interruption, long-running background status, undo and auditable action history. Those appear more strongly in supporting safety/research evidence than in the Fluent corpus.
Accessibility
- Documented: Agent UI should use Fluent components/tokens, support high contrast and reflow, provide complete keyboard operation and logical focus order, and use semantic HTML/ARIA for screen readers. Agent accessibility
- Documented: Prompt suggestions should be simple and globally understandable; sounds can signal new/updated prompts, availability, completion and error; users should control pace and sequence; multiple input/output modalities should be supported. Agent accessibility
- Documented caveat: Microsoft calls this material a starting point, not a complete guide. It does not supply detailed public rules for streamed token announcements, focus during generated card replacement, or accessibility validation of arbitrary generated interfaces.
- Implemented: Fluent UI is a large typed, tested component codebase with tokens and Storybook examples. This validates its conventional accessibility foundation, not every agent-specific lifecycle claim. Fluent repository snapshot
Architecture and machine readability
- Implemented: Fluent exposes component source, TypeScript APIs, tokens, tests and Storybook assets. These make component existence and API use machine-readable.
- Documented: Microsoft directs agent builders to treat Fluent Web Components as the component source of truth and use theming/tokens instead of hardcoded styles. Human-centered guidance
- Implemented/documented: Adaptive Cards provide JSON structure for layout, data and actions. They are machine-generable and host-adaptive, but their schema expresses allowable UI more readily than contextual design judgment.
- Documented: Content engineering makes model-behavior instructions explicit through structured prompt sections and examples. This is machine-readable behavior context, but not a design-system component registry.
- Inferred: Microsoft demonstrates two machine-readable layers: conventional component APIs/tokens and JSON/prompt structures for agent output and behavior. The corpus does not show a public Fluent-specific MCP/context server comparable to Carbon or Storybook.
Governance and quality
- Documented: Outputs should be reviewable and correctable; capability and quality limits should be set during first run; bias and secondary audiences should be considered.
- Implemented: Fluent’s repository supplies conventional automated tests and typed APIs.
- Gap: The corpus contains little public, reproducible evaluation of whether coding agents select Fluent components correctly or follow Copilot patterns. “Use Fluent” is a rule; it is not evidence of compliance enforcement.
Evidence assessment
Microsoft provides the strongest formal public account of agent experience as a lifecycle and the most specific agent accessibility/content guidance. Its public implementation evidence is strongest for foundational Fluent components and Adaptive Card structure, but weaker for mapping every agent pattern to a reusable design-system asset or machine-facing DS context layer.