AI-NATIVE DESIGN COMPONENTS · THE CATALOGUE + THE BUILD GUIDE
Components that
think with you.
What they are. How to create them.
Twelve components that make a product AI-native - streaming messages, thinking traces, tool calls, approval gates, composed surfaces - each with the states you must design and a live example you can open today. Then six steps to build your own, with templates. Copy-paste primitives live in the pattern library; the end-to-end method lives in the process manual.
COMPONENT 01 / 12
Streaming message
Text that arrives as it is written.
The core unit of every AI surface: the model’s answer renders token by token instead of appearing whole. The stream is the interface - it tells the user work is happening, and it can be stopped.
THE STATES YOU MUST DESIGN
- Empty
- Streaming
- Done
- Stopped
- Error
WHEN YOU REACH FOR IT
Any time the answer takes more than a second. If it streams, the user reads along; if it spins, the user waits.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 02 / 12
Thinking trace
The agent shows its work.
A collapsed-by-default record of what the model is doing between your question and its answer - steps, searches, deliberation. Trust goes up when the work is inspectable, down when a spinner pretends nothing is happening.
THE STATES YOU MUST DESIGN
- Thinking
- Expanded
- Collapsed
- Done
WHEN YOU REACH FOR IT
Whenever the model does more than answer in one pass. Long-running or multi-step work needs a visible trail.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 03 / 12
Tool call card
What the agent touched, and what came back.
A compact card per tool invocation: the tool’s name, the inputs it was given, and the result or failure. This is the audit trail of an agentic product - without it, actions are invisible.
THE STATES YOU MUST DESIGN
- Running
- Success
- Failed
- Retrying
WHEN YOU REACH FOR IT
The moment your product calls anything: search, a database, an API, a calendar. One card per call, in place in the conversation.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 04 / 12
Approval gate
The human signs off before it happens.
A pause in the flow where the agent proposes an action - an edit, a send, a payment - and waits for an explicit yes. The card shows exactly what will happen, and the choice is the user’s.
THE STATES YOU MUST DESIGN
- Proposed
- Approved
- Rejected
- Edited
WHEN YOU REACH FOR IT
Before any action that costs money, changes data, or reaches another person. Irreversible always gates.
COMPONENT 05 / 12
Composer
The input is a control surface, not a text box.
The modern composer carries attachments, context, model choice and the stop button. It is where the user steers, so its states - focused, uploading, sending, disabled while streaming - are product decisions.
THE STATES YOU MUST DESIGN
- Idle
- Focused
- Attachments added
- Sending
- Disabled while streaming
WHEN YOU REACH FOR IT
Every chat surface has one. Design it as the steering wheel, not the form field.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 06 / 12
Branch picker
Edit and regenerate without losing the thread.
Every answer is one branch of several: the user edits their prompt or asks for another take, and the interface keeps both. Branching turns a conversation into a workspace instead of a one-shot vending machine.
THE STATES YOU MUST DESIGN
- Single branch
- Multiple branches
- Switching
WHEN YOU REACH FOR IT
As soon as regenerate or edit-message exists. Without branches, every retry destroys the previous answer.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 07 / 12
Composed surface
The model picks real components. It never writes markup.
Generative UI done safely: the model chooses and configures components from a registered catalog - a chart, a form, a map - and deterministic code renders them. The model decides what; your design system decides how.
THE STATES YOU MUST DESIGN
- Composing
- Rendered
- Interactive
- Invalid (rejected)
WHEN YOU REACH FOR IT
When the answer is better shown than said: comparisons, forms, dashboards, maps. Compose from your catalog, never free-generate HTML.
COMPONENT 08 / 12
Plan rail
Where the agent is in a multi-step job.
A persistent list of the steps the agent plans to take, which one is running, and which are done. Long tasks stop being a black box: the user can follow, interrupt, or skip ahead.
THE STATES YOU MUST DESIGN
- Planned
- Running
- Step done
- Blocked
WHEN YOU REACH FOR IT
Any task with three or more steps - research, bookings, multi-file edits. If the agent works for minutes, the plan must be visible.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 09 / 12
On-device states
Download, capability, context budget - first-class screens.
Local AI adds states cloud AI never had: a model downloading, a device that cannot run it, a context window filling up, storage running out. These are designed screens, not console warnings.
THE STATES YOU MUST DESIGN
- Not downloaded
- Downloading
- Ready
- Unsupported device
- Context nearly full
WHEN YOU REACH FOR IT
The moment any part of your product runs on the user’s hardware. The download is your new onboarding.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 10 / 12
Pause-commit composer
No send button. The pause commits.
An experiment worth studying: the model starts answering about 350ms after you stop typing, aborts the in-flight completion when you resume, and stacks replies instead of rewriting them. The pause, not the click, is the commit point.
THE STATES YOU MUST DESIGN
- Typing
- Paused (fired)
- Resumed (aborted)
- Stacked reply
WHEN YOU REACH FOR IT
Watch it as a pattern, not a default. The idea - commit on behavior, not on a button - will outlive this demo.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 11 / 12
Clarifying question
The agent asks before it acts.
A structured question rendered in the flow when the request is ambiguous - with options, not just a text reply. Asking well is a component: it has options, a skip path, and a place in the transcript.
THE STATES YOU MUST DESIGN
- Asked
- Answered
- Skipped
WHEN YOU REACH FOR IT
When the cost of guessing wrong exceeds the cost of one question. Ambiguous briefs, missing constraints, irreversible next steps.
SEE IT LIVE · VERIFIED 13 SEP 2026
COMPONENT 12 / 12
Multimodal card
The conversation picks the medium per beat.
One conversation, many surfaces: voice to explain, a visual to compare, a tap to confirm - without restarting. Cards, tables and forms arrive inside the thread, hosted by the product team and updated once across channels.
THE STATES YOU MUST DESIGN
- Prose beat
- Card beat
- Form beat
- Confirmed
WHEN YOU REACH FOR IT
When the answer has a natural shape that is not prose: a comparison table, a confirmation card, a form. Let the beat choose the medium.
SEE IT LIVE · VERIFIED 13 SEP 2026
THE BUILD GUIDE · 6 STEPS
How to create
your own.
The twelve above share one recipe. Six steps, in order - each with the tools, a template to copy, and the ways the step goes wrong.
BUILD STEP 1 / 6
States before screens
Draw the state machine, not the hero state.
Every AI-native component is a small state machine wearing pixels. A chat message is not one design - it is empty, streaming, done, stopped and errored, and each state needs a deliberate screen. Teams that design the happy path first ship components that panic the moment the network hiccups. List the states before you open a design tool; the pixels follow.
THE TOOLS · AND WHEN TO PICK WHICH
THE TEMPLATE
Component: [name] Trigger: [what starts it] State | What the user sees | What the user can do -------------|---------------------------------|--------------------- Empty | | Working | | Done | | Interrupted | | Failed | | Rule: every row gets pixels. A state with no design is a bug you have not met yet.
WHERE THIS STEP GOES WRONG
- Designing only the happy path. The error state is where trust is won or lost.
- Treating failure as a toast. A failed generation deserves a screen, a reason and a next step, not a notification.
- Forgetting the interrupted state. Users stop streams constantly; what remains on screen afterward is a design decision.
What good looks like: every state has pixels before the first prompt is written.
DONE WHENEvery row of the state table has a screen, and a stranger can tell you what each one lets them do.
BUILD STEP 2 / 6
Compose, don’t generate
The model picks components. Your code renders them.
The defining choice of AI-native UI: does the model emit markup, or does it choose from components you own? Generated markup makes the model responsible for accessibility, validation and browser behavior it cannot guarantee. Composed UI lets it decide what to show while your design system owns how it behaves. Compose by default; generate only when the surface is truly novel and disposable.
THE TOOLS · AND WHEN TO PICK WHICH
THE TEMPLATE
Before the model touches the interface: - A catalog of components it may use exists, and you own every one - Each component has typed inputs the model must fill - no free-form HTML - Invalid output is rejected and retried, never rendered - Accessibility, validation and keyboard behavior live in the components, not in the prompt - A human can edit the result afterward with normal tools If any line fails, you are generating, not composing - and the model owns bugs it cannot fix.
WHERE THIS STEP GOES WRONG
- Letting the model emit raw HTML. You have outsourced accessibility to a system that cannot test it.
- A catalog that is aspirational instead of real. Register components that exist, or the model improvises.
- Rendering invalid output anyway. Reject-and-retry is the whole safety mechanism.
What good looks like: the model can only assemble what you would have shipped anyway.
DONE WHENThe worst output the model can produce is a valid arrangement of components you own.
BUILD STEP 3 / 6
Own the primitive
Copy the source into your repo. Never rent a black box.
AI-native components get customized constantly - new states, new tokens, new behaviors the library author never imagined. If the component lives in node_modules, every change is a fight with someone else’s abstraction. The copy-owned model (shadcn/ui made it the default): the source lands in your repo, you read it, you change it, it is yours. Agents edit owned source happily; they mangle wrapped dependencies.
THE TOOLS · AND WHEN TO PICK WHICH
THE TEMPLATE
Build a [component name] for our AI surface. Rules: - Compose it only from components in /components/ui - do not add dependencies - Implement every state in this table: [paste your state table] - Streaming text must be stoppable; stopping leaves the partial text in place - Every interactive element works from the keyboard - Match the tokens in our theme; no hard-coded colors Then list the states you implemented, so I can check them one by one.
WHERE THIS STEP GOES WRONG
- Importing a chat kit as a package. The first custom state you need will not fit its API.
- Overriding library CSS from outside. Specificity wars are how design systems rot.
- Forking before reading. Owning source you have not read is just a different black box.
What good looks like: deleting the component is a one-line change, because nothing else depends on its internals.
DONE WHENThe component’s source lives in your repo, you have read all of it, and your agent can edit it in one pass.
BUILD STEP 4 / 6
Design the abort path
Streams get cancelled. Decide what remains.
Users stop generations mid-sentence, close laptops on running agents, and lose signal on mobile. Every AI-native component needs an answer to: what is on screen after the interruption? Half-finished text that stays readable, a stopped state that offers resume or retry, a tool call that never leaves the user wondering if it ran. The abort path is not an edge case - on mobile it is the common case.
THE TOOLS · AND WHEN TO PICK WHICH
THE TEMPLATE
For every long-running component: - The stop control is visible the whole time it runs - Stopping leaves partial output in place and readable - The stopped state offers: resume, retry, or discard - not a dead end - A retried answer does not destroy the stopped one (branch it) - Tool calls show whether they completed, were cancelled, or never ran - On mobile, all of the above survives a dropped connection Test: unplug the network mid-stream. Whatever the screen does next is your real design.
WHERE THIS STEP GOES WRONG
- A spinner with no stop button. The user’s only control is closing the tab.
- Aborting by clearing. Half an answer is often the useful half; deleting it punishes the interruption.
- Retry that mutates the last bubble. The user loses the version they almost liked.
What good looks like: interrupting the product feels like pausing, not breaking.
DONE WHENYou can stop any running component at any moment and the screen still makes sense.
BUILD STEP 5 / 6
Ground the claims
Every claim carries its source.
AI components make claims: this is the answer, these are the sources, this is what I did. Ungrounded claims are how products lose trust - one confident wrong answer undoes a hundred right ones. Design the grounding into the component: citations that resolve, a visible trail of what the agent opened, and honest labels when the model is guessing. And remember the O’Reilly line from the Fresh shelf: a tool’s self-description can inform a trust decision, but never establish it.
THE TOOLS · AND WHEN TO PICK WHICH
THE TEMPLATE
For each claim the component can make: Claim | Source shown to user | When it is unverified -------------------|-----------------------------|---------------------- Factual answer | Citation links that resolve | Labeled as unverified Data/numbers | Named source + date | Refuse to show Action taken | Tool call card with result | Marked as not confirmed Recommendation | Reasoning summary | Framed as a suggestion Rule: a claim with no source gets a label, not a citation-shaped decoration.
WHERE THIS STEP GOES WRONG
- Citations that do not resolve. A broken source link is worse than none - it performs trust while betraying it.
- Confidence with no trail. If the user cannot see what the agent read, fluent prose is a rumor.
- Trusting the tool’s description of itself. Verify against the source, not the summary.
What good looks like: a skeptical user can audit any claim in one click.
DONE WHENEvery claim type in the table has a real source mechanism, and unverified output is visibly labeled.
BUILD STEP 6 / 6
Eval the component
Score it before you ship it.
The process manual’s rule applies at component scale: write the test before the answer. A streaming message can be gorgeous and still fail - unreadable at speed, unstoppable from the keyboard, silent on error. Score every component against observable criteria, on a real device, on a bad network. The eval is the spec, and the component does not ship below full marks.
THE TOOLS · AND WHEN TO PICK WHICH
THE TEMPLATE
Component: [name] Score each 0 or 1. Criterion (make yours observable) | Score -----------------------------------------------------------|------ Every state in the state table renders deliberately | Works from the keyboard alone | Readable on a 390px phone on a slow connection | Stop/abort works and leaves a sensible screen | Failure state names the problem and the next step | Claims carry sources; unverified output is labeled | -----------------------------------------------------------|------ Below full marks: iterate, don’t ship.
WHERE THIS STEP GOES WRONG
- Judging from a screenshot. Components are behavior; a static image misses every state that matters.
- Testing only on fast wifi. Your users meet this component on a train.
- Criteria you cannot observe. "Feels snappy" is not a test; "stop responds within 200ms" is.
What good looks like: two people score the same component the same way without talking.
DONE WHENThe component scores full marks on a real phone, on a throttled connection, with the keyboard alone.
AFTER STEP 6 · SHIP ONE
Then ship one small.
Pick the component your product needs most, walk the six steps, and put it in front of a user this week. Everything here connects: 78 live patterns to start from, the full process for the product around the component, the rankings for choosing the model behind it, and the fresh shelf for the patterns still landing.
Back to the wall ↗