Describe a tool. Watch it appear.

So far, Claude’s output has been words. This chapter, it becomes things — working web pages that render right in the conversation, that you can click, type into, and hand to other people.

Here is the setup at Cornwall Market. Sarah has her categorization rules captured (Chapter 02). But her staff does not read process documents — and honestly, she does not want them to. What she wants is: a new cashier gets an invoice, needs to know which account it goes to, and gets the answer in five seconds without calling her.

So she asks Claude:

“Build me a searchable cheat-sheet web page for my staff. It should have a search box at the top. When you type a vendor name, it shows that vendor’s account code, when their invoices arrive, and any warnings. Here are the rules: [she pastes the structured document from Chapter 02]. Make it big and readable — it’ll be used on an iPad at the register. Title it ‘Cornwall Market — Invoice Codes’.”

Claude builds it. Not a description of a page — an actual page, rendered in a panel next to the conversation. A title, a search box, vendor cards. Sarah types “chen” into the search box and both Chen’s vendors appear, each with its account code in large type, its delivery days, and the warning in red: “Do not confuse Produce (5100) with Bakery Supplies (5120) — check the items.”

Ninety seconds ago this was a paragraph of dictated rules. Now it is a tool.

Real pages, living next to the conversation

What Claude just built is called an artifact — a self-contained piece of work that lives in its own panel beside the chat. Artifacts can be documents, diagrams, code files — but the ones this chapter cares about are interactive web pages: HTML, styling, and working logic, rendered live.

Three properties make artifacts more than a demo trick:

They are self-contained. An artifact is a complete page — everything it needs is inside it. That is why it can be shared with a link, opened on any device, and kept working long after the conversation ends.

They are versioned. Every time you ask for a change, Claude produces a new version — and the old ones remain. There is a version selector on the artifact panel. You can compare, and you can go back. This makes iteration safe: “try making it dark blue” costs nothing, because reverting costs nothing.

They are remixable. An artifact you receive can be opened and modified in your own conversation — “take this and add a column for delivery days.” Someone else’s tool becomes your starting point.

What can they be? The honest answer is “any single-page web thing,” which is a much bigger space than it sounds:

One boundary to know now, so it does not surprise you later: an artifact is a page, not a service. It does not have its own database — when Sarah’s prices change, she asks Claude to update the artifact and republishes it. It cannot reach into QuickBooks on its own. For live data and automatic updates, you need the connections that start in Chapter 05. An artifact is the front of a tool. The rest of this course builds the back.

Check your understanding

Answer in your own words — write it down before opening the key. Your tutor grades against the criteria and generates fresh variants on retries.

Q1. An artifact is a page, not a service. Name two things your cheat-sheet artifact cannot do on its own, and which later capabilities in this course close each gap.

Next: Iterate Like a Designer