For buttons and errors, teams don’t reinvent anything. A designer inherits the conventions. AI trust patterns have no such inheritance yet, so each team that adds AI decides for itself, in isolation, and often differently.
So every AI feature teaches users a different way to trust it. What did the system understand? What evidence did it use, and how confident is it? How does a person steer or recover in the next feature over? Design systems solved this once, for a simpler kind of software.
Classic systems standardized certainty
Design systems grew around deterministic software. Buttons, fields, modals, tables, loading, success, warning, and error states gave teams a shared visual and behavioral grammar. That worked because the software always knew which state it was in.
AI adds interpretation. The system can understand the request but lack evidence. It can complete most of the job and become blocked. It can produce a credible draft with one unsafe claim. It can change its plan while it works.
A spinner can’t tell the user what the agent is weighing. A toast can’t explain why the system is only moderately sure. A red error message can’t carry “finished the task, but leaned on weak evidence.”
Participation needs standardizing, not sparkles
An AI badge says the system generated something. It doesn’t tell the user whether the result is grounded, provisional, safe to act on, or reversible.
AI components answer surface questions. Where’s the feature? What did it produce? How do I regenerate it? Agentic components answer participation questions:
- What did the system understand?
- Which context and sources did it use?
- How confident is it, and about what?
- Is it suggesting, preparing, or acting?
- What can the user approve, change, stop, or undo?
- What did memory contribute?
- What happens next?
The goal is consistent trust, not consistent decoration.
Agentic components come in families
An agentic design system extends the classic system with reusable components, states, and rules for delegated interaction. It doesn’t replace the classic system. These are its core component families.
Fill-in table
Core component families
The reusable components an agentic design system adds for delegated interaction.
| Family | What they do | What they look like |
|---|---|---|
| Confidence states | Distinguish confidence in intent, source, claim, plan, and action. Each state changes what happens next. | Claim-level markers, “verify this part” highlights, draft-only states, “safe to send” versus “needs approval.” |
| Explanation surfaces | Provide citations, assumptions, rationale, diffs, and “what changed” summaries at the depth the decision requires. | A lightweight label for a user scanning, a compact rationale for a user reviewing, the evidence drawer before a consequential approval. |
| Override and recovery controls | Standardize accept, reject, edit, stop, undo, revert, escalate, and correct-with-scope. | Regenerate, correct-and-remember, correct-but-don’t-remember, narrow scope. |
| Memory affordances | Show what was remembered, where it applies, how fresh it is, and how to change or forget it. | Used-from-memory labels, remembered-preference chips, editable memory cards, “forget this” and “don’t use this here” controls, personal versus project versus team scope labels. |
| Agent status and plan components | Expose the current step, completed work, blockers, plan changes, and review points. | Plan cards, step trackers, “waiting on you” states, “plan changed” banners, review checkpoints. |
| Adaptive next moves | Connect the result to the right continuation: clarify, review, approve, apply, hand off, or finish. | Review this section, approve, clarify the missing input, apply to the workflow, escalate, rerun with narrower scope. |
Example
Core component families: states a spinner and a toast can’t carry
One task can move through several states named in this chapter. Each state needs a signal that tells the person what changed.
| State | Signal |
|---|---|
| Understood the request but lacked evidence | Separate confidence in intent from confidence in the source. |
| Produced a credible draft with one unsafe claim | A claim-level marker and a “verify this part” highlight. |
| Completed most of the job and became blocked | A step tracker showing completed work and the blocker. |
| Changed its plan while it worked | A “plan changed” banner. |
| Waiting on you | A “waiting on you” state that identifies the missing input. |
| Low confidence | What the system is unsure about. |
| Handoff | A review checkpoint and a way to hand off. |
Meaning comes before component form
The same confidence badge can appear everywhere and still fail if it means “grounded fact” on one screen and “plausible guess” on another. Inconsistent flagging trains users to ignore the signals because they can’t form a stable mental model of what they mean. Confidence isn’t decoration. It’s a routing signal for human attention.
Define the semantic contract first.
Fill-in card
Semantic contract
Answer these for a state before you design its component.
- Obligation
- What does this state obligate the product to show?
- Actions
- Which actions does it enable?
- Evidence
- What evidence is required? “Sources reviewed” should connect to the sources. “Tests passed” should identify the test run.
- Recovery
- What recovery is guaranteed?
Then design the component.
A shared visual without shared behavior creates false consistency.
The unhappy path belongs in the design system
An agentic system should include patterns for missing sources, conflicting evidence, denied permission, partial completion, rerouting, low confidence, and handoff.
These states aren’t rare exceptions. They’re normal conditions for intelligent systems working in messy environments.
Leave them to each feature team and the user ends up rebuilding their sense of what the system is doing every time they cross into a new part of the app. The design system exists to stop that drift.
A system audit
Inventory every AI surface, then:
0 of 8 done
