- 01
- September
"What are Claude Artifacts?" — the short answer is a separate window where Claude builds self-contained work: a document, a diagram, a dashboard, or a small tool people can actually click — and share as a link. Unlike an answer buried in a chat, an artifact can be iterated on and kept. This article covers what can be built, where to switch it on, the documented limits, and the work artifacts should not be used for.
In one line: An artifact is a dedicated window for self-contained content (typically more than 15 lines). Available on every plan including Free, but the "Code execution and file creation" capability must be enabled first — and on Team or Enterprise, only an organisation admin can enable it.
How an artifact differs from a chat answer
Ordinary questions produce answers that scroll past in the conversation. But when what you asked for is a piece of work — self-contained and substantial, typically more than about fifteen lines — Claude moves it into a separate panel on the right called an artifact.
Three practical differences follow. It can be revised round after round without scrolling back through chat; if it is a web page or diagram you see the real rendered result immediately; and it can be shared as a link without handing someone the entire conversation to read.
| Type | What organisations use it for |
|---|---|
| Documents (Markdown / text) | Drafting policies, manuals and memos that go through several revisions |
| Diagrams and SVG | Approval flows, organisation charts, document routing maps |
| HTML pages | Executive summary pages, filterable tables |
| Code | Conversion scripts and calculation logic to hand to IT for review |
| Interactive tools (React) | Penalty calculators, assessment forms, triage screens people can actually use |
That last row is what changes how work gets done. A request that used to mean raising a ticket and waiting a month — "we want a screen that calculates late-delivery penalties using our formula" — becomes something a person on the front line describes in plain language and has running in minutes.
How to switch it on
Artifacts work on Free, Pro, Max, Team and Enterprise plans through Claude on the web and desktop, but the capability has to be enabled — and where it is enabled depends on the account type.
| Account type | Where to enable | Who can do it |
|---|---|---|
| Free / Pro / Max | Settings > Capabilities > Code execution and file creation | The user, for themselves |
| Team / Enterprise | Organization settings > Capabilities > the same toggle | Organisation admins only |
| Claude Code | Artifacts are supported on Team and Enterprise plans only | Per organisation configuration |
It is the same switch that controls Excel uploads: "Code execution and file creation" governs both artifacts and XLSX uploads. If an organisation has it off, users hit both symptoms at once — no artifacts, and Excel files that will not upload. The file side is covered in analysing Excel, CSV and PDF files with Claude.
Sharing: you have to publish first
Every artifact starts life inside its own conversation. To let anyone else open it, or to embed it in a site, you have to publish it. Published artifacts collect in the Artifacts section of the sidebar — artifacts that were never published do not appear there.
Read this before sharing with a client or anyone outside: when you share an artifact, viewers also gain access to the attachments and files in the conversation that created it. If you uploaded internal accounts while building a summary page for a customer, those accounts travel with the link. The safe practice is to build anything you intend to share in a fresh, clean conversation — never as a continuation of a thread containing internal documents. The same principle runs through data governance for Claude in the enterprise.
Documented limits
| Limit | Practical consequence |
|---|---|
| Personal storage of 20 MB per artifact | Fine for tools and forms, not a place to hold real datasets |
| Code execution must be enabled | Organisations that disable it for security reasons cannot use artifacts at all |
| MCP integration inside artifacts requires Pro or above | Free accounts can build artifacts but cannot connect them to external systems |
| Unpublishing permanently deletes the artifact's stored data | If an artifact has been collecting responses, unpublishing loses them for good — always export first |
| Viewers of a shared artifact must confirm before data is shared | Do not design a flow that assumes people will click straight through |
Five things worth building on day one
| Job | Artifact type | Why it pays |
|---|---|---|
| Approval flow map | Diagram | Redraw it live in the meeting as objections come up |
| Internal formula calculator | Interactive tool | Test the formula against real cases before commissioning development |
| Policy or manual draft | Document | Revise in rounds while always seeing the full current version |
| Numbers summary for a meeting | HTML page | Send executives a link they can open on a phone, no attachment |
| Screen prototype before development | Interactive tool | Let real users click it first, cutting spec rework after build |
The underrated one is the last: in ERP projects the expensive failure is not writing code, it is writing the wrong code and discovering it at handover. An hour of real users clicking a prototype saves weeks of rework — and building that prototype no longer requires queuing for developer time.
Three things to agree before opening this up organisation-wide
1. Who is allowed to publish. Publishing makes an artifact openable from a link. Decide which categories of work may be published, and keep anything containing internal data unpublished, inside the conversation.
2. Name prototypes as prototypes. A prototype that looks finished gets forwarded until someone believes it is a live system. Putting the word "prototype" in the title from the start removes the problem entirely.
3. Always export before unpublishing. Unpublishing permanently deletes the artifact's stored data, so anything it collected from users has to be pulled out and stored elsewhere first.
Artifacts with AI inside them
The level few teams have reached is the artifact that embeds Claude's own intelligence, so whoever opens the link does not just see a static page — they can type a question into it and get an answer back, without needing a Claude account of their own.
The jobs that suit this are the ones where the questions are open-ended: an intake page where an applicant describes their situation in ordinary language and the page classifies it before it reaches an officer's queue, or a policy explainer people can interrogate directly rather than searching a manual.
The caution arrives with the capability. Once outsiders can type anything into it, assume some of them will type something designed to manipulate it, and never design the page to make binding decisions on an officer's behalf. Let it organise information before it reaches a human — the same principle set out in what prompt injection is.
The line that matters most: an artifact is not a business system
Being able to produce a usable tool in minutes immediately raises the question: "so can we just run stock requisitions as an artifact?" The answer is no, and the reason is not capability. It is everything a real business system needs and an artifact does not have.
A real requisition system has to know who clicked, tie that to role-based permissions, record who approved what and when, decrement stock safely when two people submit simultaneously, and retain the record for years of audit. Those properties come built into an ERP system by design. Artifacts were designed for presentation and experimentation.
So the highest-value use is as a rehearsal layer before the real thing — design the screen, test the formula, settle the argument about what is actually wanted, then build that agreed thing in a system with permissions and an audit trail. It is the same separation we draw between projects and databases: AI helps you think and draft; it does not record transactions.
Good fit / poor fit
| Good fit | Poor fit |
|---|---|
| Prototypes that align everyone on the requirement before development | Systems needing authentication and role-based permissions |
| Documents or diagrams that go through several rounds before approval | Work that must be retained and audited over years |
| One-off calculators not worth commissioning as a project | Anything containing personal data that then gets shared externally |
| Summary pages you can send executives as a link | Work several people must edit concurrently in one version |
Conclusion
Artifacts are the part of Claude that turns an answer into a piece of work you can revise, share and actually click. They are available on every plan, provided "Code execution and file creation" is switched on — and in a Team or Enterprise organisation, only an admin can switch it on.
Two things are worth carrying around. First, sharing an artifact carries the conversation's attachments with it, so build anything destined for outside eyes in a clean conversation. Second, artifacts excel at experimentation and presentation but were never designed to be the system of record — use them to settle what you want, then build the real thing where permissions and audit trails live.
Artifacts make a prototype appear in minutes, but even the best prototype is still only an agreement about what we want — not a system accountable for the data.
- The Saeree ERP team
References
- Anthropic — What are artifacts and how do I use them? (checked 1 Sep 2026)
- Anthropic — Publish and share artifacts
- Anthropic — Build and share AI-powered apps with Claude
Want to prototype before committing to development?
We use artifacts to prototype screens and calculation logic so the requirement is settled first, then build it properly — and we supply Claude licences with full Thai procurement documentation.
Get advice / request a quoteTel 02-347-7730 | sale@grandlinux.com
