A normal SaaS design system has buttons, inputs, modals, and a color scale. An AI product design system has all of that, plus a stack of components that did not exist three years ago: streaming message blocks, citation chips, tool-call cards, confidence meters, permission gates, agent timelines, model pickers, and context drawers. Most teams build these ad hoc, one per feature, and end up with five visual languages inside the same product.

This guide is the AI product design system we use at AY Design when we redesign products built on Lovable, Bolt, v0, and Cursor. Ten components, each scored by importance, build effort, and how often founders skip them. The point is to have one coherent system that handles every AI-specific pattern in your product, not a fresh pile of one-offs.

TL;DR, an AI product design system in 2026 needs a message primitive, a streaming state, a citation chip, a tool-call card, a confidence indicator, a permission gate, an empty state with starter prompts, an agent timeline, a context drawer, and a model picker, all sharing one type, color, and motion language.

AI product design system components: a brief overview

• The message primitive: One base block that handles user, assistant, system, and tool messages.

• Streaming state and skeletons: A consistent visual for "the model is working".

• Citation chip: Inline source pills with hover preview and click-through.

• Tool-call card: Labeled cards for every tool invocation, expandable for detail.

• Confidence indicator: A reusable signal for calibrated certainty.

• Permission gate component: An undismissable, accessible approve and reject UI for consequential actions.

• Empty state with starter prompts: A patterned replacement for the empty chat box.

• Agent timeline: A vertical step list for multi-step agent runs.

• Context drawer: A consistent place to view and edit what the model is conditioning on.

• Model and mode picker: A scoped selector that hides complexity from new users.

1. The message primitive

The message primitive is the base block every AI product is built on. It handles a user prompt, an assistant reply, a tool result, a system note, and an error, all from one component with role variants. Get this right and every other surface (chat, agent panel, history, share view) inherits the same visual logic.

Why it matters: When the message primitive is missing, teams ship a different layout for chat, sidebar Q&A, share pages, and agent traces. The product loses coherence, accessibility audits get harder, and every new feature is a fresh design problem. A real message primitive collapses that surface area.

Real product example: Claude.ai uses one underlying message block across chats, projects, and shared conversations. ChatGPT's message component handles user, assistant, tool, and reasoning roles with consistent typography and spacing. Linear AI inherits the Linear comment primitive, which is why the AI surface feels native to the rest of the product.

How to score yourself: Count the distinct message layouts in your product. If you have more than two, you do not have a primitive, you have a sprawl.

2. Streaming state and skeletons

Streaming state is the visual language for "the model is working". Done well, it makes a 20-second wait feel like productive progress. Done badly, it looks like the product is broken. The system needs one canonical streaming pattern, applied everywhere the model produces output.

Why it matters: AI products live in a different latency regime than normal SaaS. A static spinner does not communicate enough. The product needs a consistent skeleton, a typing cursor, a streamed-token visual, and a clear "finished" transition, all from one set of primitives.

Real product example: Claude streams text with a soft cursor and a clear stop-state. ChatGPT uses skeleton blocks for tool calls and streamed tokens for prose. Cursor streams shell output, file edits, and reasoning into distinct streaming containers, all visually consistent.

How to score yourself: Trigger every async action in your product back to back. If the loading and streaming visuals are not identical across all of them, the system has gaps.

3. Citation chip

A citation chip is the inline source pill that turns a claim into a verifiable claim. It needs three states: idle, hovered (with source preview), and clicked (with full source). Once you have it, every grounded output in the product can use it, from search results to chat answers to document summaries.

Why it matters: Trust in AI products scales with verifiability. Citations are the cheapest verifiability win you can ship, and once the component exists, the marginal cost of grounding the next feature is near zero. Without the chip, every feature reinvents source display.

Real product example: Perplexity's numbered citation chips are the canonical example, with hover previews and click-through to the source. Granola uses inline timestamp chips that play back the meeting audio at that moment. Notion AI links AI-generated facts to the source blocks they were derived from.

How to score yourself: Look at any AI-generated output in your product. If a claim is not clickable to its source, you are missing the chip.

4. Tool-call card

Tool-call cards are labeled, expandable UI blocks for every tool the AI invokes: web search, code execution, file read, API call, image generation. They turn an opaque agent trace into a legible workflow. This is the component that makes agents feel like real software instead of a magic box.

Why it matters: Agents that hide their tool calls are agents users cannot trust. When the tool-call card is a first-class component, every new tool the team adds inherits a consistent UI for inputs, outputs, errors, and retries. Without it, every tool is a custom UI problem.

Real product example: Claude's tool use renders each call as a labeled card with the tool name, inputs, output, and runtime. Cursor displays shell, file read, and edit calls as distinct, expandable blocks. Perplexity surfaces search tools as inline cards with the queries and result counts.

How to score yourself: Add a new tool to your agent. If it requires custom UI, the card is missing. The right component absorbs new tools as configuration, not code.

5. Confidence indicator

The confidence indicator is a small, reusable signal that says how sure the model is about a given output. It can be a bar, a label (low / medium / high), a color tint, or a verbal hedge in the copy. The system needs one canonical form, applied consistently, so users learn to read it.

Why it matters: Calibrated confidence is the difference between a model that is wrong sometimes and a product that is dangerous sometimes. When users can see the model's uncertainty, they self-correct on hedged outputs and trust scales. When the signal is missing, every wrong answer feels like a betrayal.

Real product example: Perplexity uses visual distinction between cited and uncited claims as an implicit confidence signal. Linear AI shows a confidence percentage on auto-categorized tickets. Anthropic's API exposes log probabilities, which design teams can surface as a visual signal in product.

How to score yourself: Show three outputs to a user without context. If they cannot rank them by confidence using only the UI, the signal does not exist yet.

6. Permission gate component

The permission gate is the approve-or-reject UI that runs before any consequential action: send, delete, charge, push, mutate. It needs to be undismissable, accessible (keyboard, screen reader), and consistent across every action it gates. This is one component, used many times, never reinvented per action.

Why it matters: Inconsistent gates train users to dismiss them. A unified component, applied everywhere, makes the gate predictable, which keeps users alert. It also enforces a design discipline: if you add an action, you choose the gate variant, not whether to gate at all.

Real product example: Cursor's "apply changes" confirmation is the same component whether the agent is editing one file or twenty. Anthropic's computer use gates every consequential action with a consistent confirmation surface. Granola asks before sharing notes using the same component everywhere a share is initiated.

How to score yourself: List every consequential action in your product. If the gate UI is not visually and behaviorally identical across them, the component is fragmented.

7. Empty state with starter prompts

An empty state with starter prompts replaces the bare chat box. It carries the product's tone of voice, scopes the model's strengths, and gives the user a one-click path to the first useful output. This is a single component with a slot for prompts and a slot for context (which project, which workspace, which document).

Why it matters: Empty states are first impressions. When the system has one canonical empty state, every new feature ships with a polished cold start. Without it, each feature ships a different blank box and the product feels uneven.

Real product example: Claude.ai shows project-scoped starter prompts in a consistent empty-state component. Cursor's chat shows scoped suggested actions based on the open file. Notion AI surfaces context-aware starter prompts inside any empty doc.

How to score yourself: Click into every empty surface in your product. If any of them is just placeholder text in a text input, that surface is missing the component.

8. Agent timeline

The agent timeline is a vertical step list that shows the agent's plan, current step, completed steps, and pending steps in one scrollable view. It is the spine of every multi-step agent UI. Built once as a component, it handles five-step agents and fifty-step agents with the same interaction model.

Why it matters: Long agent runs without a timeline feel like a black box. With a timeline, users can scroll back to see what happened, jump to a step to inspect inputs and outputs, and pause or steer at any point. The timeline is also where audit and replay live.

Real product example: Cursor's agent panel shows the sequence of edits, shell commands, and file reads as a timeline. Claude's tool use traces render as a vertical step list. Lovable shows the build steps as a timeline so the user can see what the agent did to ship the app.

How to score yourself: Run a 10-step agent task in your product. If you cannot see all 10 steps in one view, with status and the ability to expand any one, the timeline is missing.

9. Context drawer

The context drawer is the consistent place where users can view and edit what the model is conditioning on: open project, attached files, memory, instructions, tools, model version. It is a single component with a tabbed interior, slid out from the right or bottom, used everywhere context matters.

Why it matters: Context is the second most important variable in AI output quality after the model itself. When users cannot see or edit context, they cannot debug bad outputs. The context drawer turns the invisible into the editable.

Real product example: Claude's project panel shows attached files, custom instructions, and memory in one drawer. Cursor's context panel exposes which files and rules are in scope. ChatGPT's memory panel surfaces remembered facts in a single, editable view.

How to score yourself: Ask a user to fix a bad output by changing what the AI knows. If they cannot find a single place to edit context, the drawer is missing.

10. Model and mode picker

The model and mode picker is the scoped selector that lets users choose between models, reasoning effort, or response styles. The system needs one component with sensible defaults, clear labels, and graceful degradation when the user picks a slower or cheaper option. The wrong version of this component is a dropdown with model codenames no one understands.

Why it matters: Most users do not want to pick a model. The ones who do want full control. A good picker hides complexity behind a smart default and exposes power only when asked. A bad picker confuses everyone and looks like a config form.

Real product example: Claude.ai's model picker uses plain-language labels (smart, fast) over codenames in the default surface. Cursor's mode picker (ask, agent) is scoped by task, not by model. Perplexity's "focus" picker switches between search modes without exposing model details.

How to score yourself: Show your picker to a non-technical user. If they cannot tell which option to choose for their task, the component is too technical.

How to choose where to start

1) What is your product surface?

A chat-first product needs the message primitive, streaming state, citation chip, and empty state first. An agent-first product needs the tool-call card, permission gate, and agent timeline first. A copilot inside another app needs the message primitive, model picker, and context drawer first.

2) What is your team size?

A two-person team should ship the cheap, high-importance items (empty state, citation chip, model picker, permission gate) and defer the expensive ones (agent timeline, context drawer). A team of five or more can run two design system tracks in parallel: the primitives (1, 2, 6) and the AI-specific composites (3, 4, 8, 9).

3) How mature is your visual language?

If your product still looks like a default shadcn install, fix the type, color, and motion language before building these components. A design system without a voice is just a component library, and AI components will inherit the templated feel of the base.

4) Are you Figma-first or code-first?

If your team ships from Figma, build the components in Figma first with real variants and tokens, then translate to code. If your team is code-first (most AI startups), build in code (React, Tailwind, shadcn, Radix) with Storybook coverage, and reverse-document in Figma only for handoff to non-engineers.

If you have audited your AI product and want a design partner to build the system, that is what AY Design does. We help founders shipping with Lovable, Bolt, v0, and Cursor build coherent AI-product design systems that turn templated MVPs into unicorn-grade products. Book a design audit to see what to build first.

FAQ

What is an AI product design system?

An AI product design system is a coherent set of UI components, tokens, and patterns built specifically for products where the core value is generated by a model. It extends a normal design system with AI-specific primitives: message blocks, streaming states, citation chips, tool-call cards, confidence indicators, permission gates, agent timelines, context drawers, and model pickers.

How is it different from a normal SaaS design system?

A normal SaaS design system handles fixed-output components like buttons, inputs, modals, and tables. An AI product design system adds stochastic-output components that handle streamed text, citations, tool calls, agent steps, and confidence, which do not exist in conventional SaaS. The visual language and motion principles overlap, but the components do not.

Should we extend shadcn or build from scratch?

Most AI startups in 2026 should extend a base library like shadcn for primitives (buttons, inputs, layout) and build AI-specific components (message, streaming, tool-call, agent timeline) on top with a clear naming convention. Building from scratch is overkill at pre-Series-A; rejecting any base library entirely usually slows the team without improving the output.

What's the minimum viable AI product design system?

The minimum viable AI product design system is the message primitive, the streaming state, the empty state with starter prompts, and the permission gate. With those four, you can ship a coherent AI product. Citation chips, tool-call cards, agent timelines, and context drawers come next as the product surface expands.

Who owns the design system, design or engineering?

The design system should be co-owned, with design owning the patterns, tokens, and visual language, and engineering owning the code implementation and Storybook. AI-specific components especially benefit from co-ownership because the model behavior (streaming, tool use, latency) is a backend concern that shapes the front-end UX.

How do you keep an AI product design system from rotting?

Treat the system as a product with releases, versioning, and a roadmap. Every new AI feature is a vote on whether the existing components suffice or a new one is needed. Run a quarterly system audit, deprecate the duplicates, and make the design system the path of least resistance for shipping new features.

Do you need a Figma library if you ship in code?

If the team is engineering-led and ships from code, the Figma library is a documentation artifact, not the source of truth. Maintain it for non-engineer collaboration (marketing, sales, founders sketching) but accept that the code is canonical. The opposite trap, keeping Figma canonical when the code has diverged, is more dangerous.

How long does it take to build the full system?

A focused team can ship the message primitive, streaming state, empty state, and permission gate in two to three weeks. Citation chips, tool-call cards, and the model picker take another two to three weeks. Agent timelines and context drawers are the longest builds, typically four to six weeks each because they touch the most surfaces. A complete AI product design system lands in roughly a quarter of focused work.