Overview
How might we show rich generated output without burying the conversation in code blocks or long paste walls?
When output deserves its own workspace
- Code, documents, diagrams, or UI mockups that users will edit, preview, or iterate on.
- Outputs long enough that inline chat would break scanability of the thread.
- Products where export, copy, or open-in-editor is a primary success path.
- Dual-pane layouts where conversation stays the control plane and the artifact is the payload.
When a side panel would be empty theater
- Short, disposable outputs like a one-line answer or single suggestion that do not warrant their own panel.
- Mobile layouts too narrow to show conversation and artifact side by side without heavy tab-switching.
- Outputs that are purely conversational text with nothing to interact with beyond reading.
States
Design the artifact lifecycle, not only a preview iframe that appears once.
Requested
The user asks for something substantial: a report, component, doc, or chart.
Generating
The agent streams reasoning in the thread while the artifact slot prepares or shows a skeleton.
Published
The artifact opens in a panel or sheet with a title and a visible chip back to the creating message.
Previewing
Users read, scroll, or interact with rendered content without losing chat context under or beside it.
Iterating
Follow-up prompts refine the artifact. Version labels or history show what changed.
Exported
Copy, download, or open actions move the output out of the panel when the user is done.
Key UX elements
The parts that must be present for generated output to feel first-class beside the thread.
Keep the chat readable.
Short agent prose in the thread. Put the heavy payload in the panel, not in the message bubble.
Link the panel to the message.
A preview card in the thread shows title and recency, and opens the artifact workspace when tapped.
Label title, type, and version.
Title plus format (HTML, Markdown) and optional version so people know what they are viewing.
Render the payload in place.
Show live preview or editable source in the panel body. Match the artifact type users expect.
Offer copy and open paths.
Copy, download, or open in editor. Never trap useful output inside the panel alone.
Anti-patterns to avoid
Artifacts that fork from the conversation with no visible link back to the message that created them.
Overwriting an artifact on every regeneration with no version history to compare or revert.
No export or copy path, trapping useful output inside the panel.
Panels that cannot resize or collapse, permanently eating screen space on smaller viewports.
How products use it
| Product | Implementation |
|---|---|
| Claude Artifacts | Code, documents, and interactive components render in a side panel with version history. |
| Cursor | Generated code changes surface as diffs and files outside the chat thread itself. |
| Replit Agent | Generated apps run live in a preview pane alongside the agent conversation. |
| Notion AI | Generated content is written directly into the document rather than staying in a chat bubble. |
Real-world examples
How shipped products implement chat artifacts, from our teardown guides.
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Chat Artifacts" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is a chat artifact in AI product design?
A chat artifact is a piece of AI-generated content, code, a document, a diagram, that displays in its own dedicated panel next to the conversation instead of inline, so users can interact with it without cluttering the chat thread.
Why use a side panel instead of showing content in the chat bubble?
Complex or evolving content like code and documents needs room to be read, edited, and re-rendered. Keeping it in a separate panel avoids bloating the conversation history with large blocks that get harder to scroll past over time.
Should artifacts keep version history?
For anything users iterate on, yes. Without version history, each regeneration silently replaces prior work, making it hard to compare alternatives or recover a better earlier version.