# I finally figured out what Claude Artifacts are actually for > Source: > Published: 2026-07-17 15:27:28+00:00 I've been using Claude for a long time and mostly ignored Artifacts. Fine for a quick React demo. Not something I reached for. Then I needed to send an analysis to a few people at work, and it clicked. Or I'm just using it in a way nobody intended. Hard to say. I own the paywall backend at a Czech media house. The subscription offer on our news site is embedded as an iframe, and iframes are a bad neighbourhood: context isolation means the iframe has no access to the parent page's session, so user identity kept breaking and we kept patching it over postMessage. Every iframe is its own page view, so GA4 data was skewed and we had to build server-side tracking and session stitching to make the numbers mean anything. And ad blockers, CSP, and timeouts mean sometimes the thing just doesn't render, so we maintain a fallback UI in parallel. I wanted to propose we drop the iframe and ship a JS embed library instead, distributed through our internal npm registry. That's an architecture change, so it needs a document: what we fixed, why the iframe is still structurally wrong, what the alternative costs, what the numbers say. The numbers part came out of the same agent session, by the way. GA4 said roughly 0.14% of paywalled page views hit an error, about half of them iframe-blocked-by-browser. That's every 700th reader. Small number, real money. You get a good answer out of the model. Now what? You paste it into a doc. Reformat it, because chat markdown does not survive the trip. Fix the tables. Decide whether it goes in Confluence or an email. Send it. Then someone asks a follow-up, you go back to the model, get a better answer, and now there are two versions of the truth and one of them is in someone's inbox. I've done the email version of exactly this document before. Outlook ate the markdown. I ended up hand-rolling plain text with unicode bullets and uppercase section headers like it was 1998. Half of that work is transport, not thinking. And the transport step is where the document goes stale. I had the same agent that produced the analysis publish it as an Artifact, and sent people the link. We have Claude on a team plan, so they just open it. No docx export. No Confluence page. No slide deck. One URL. The thing worth noticing: there is no handoff. The agent that has the analysis in context is the agent that renders it. No step where I copy something out of one tool into another, which means no step where I introduce a formatting mistake or quietly drop a caveat. The Artifact is not a snapshot. As the thing moved (proposal → decision → plan with tickets), I had the agent rewrite it. Same URL the whole time. So it stopped being "the thing I sent on Tuesday" and became the current state of the project. Nobody hunts for the newest version, because there is only one version. Nobody asks "is this still accurate?", because the answer is yes or the doc gets rewritten. That's a surprising amount of what a wiki does, without the part where you have to remember the wiki exists. It is not documentation. No history, no diff, no "who changed this and why". If you need to know what the architecture decision was six months ago and what the reasoning was, you need a real doc in a real system. This is a tool for one phase: the window between "I have a finding" and "we've decided what to do". A few days, sometimes a couple of weeks. During that window the document changes constantly and permanence is a liability. After the decision lands, the durable version goes in the wiki. The Artifact was scaffolding. The other limit is obvious but worth saying: everyone who needs to read it has to be on the same team plan. Not a public publishing tool. Be deliberate about what data goes in. The agent will happily render whatever it has in context. When the analysis touched production analytics, "whatever it has in context" included things that should not exist in a link pasted into a chat channel. In that same GA4 dig I found we were sending subscriber UUIDs to Google as an event category, which is its own separate problem, but it's a good illustration: the raw data had identifiers in it, and the shareable document must not. Aggregates only. No personal data. Decide that before you ask for the artifact, not after you've shared it. I ended up writing my conventions down as a skill file so the agent applies them the same way every time instead of me remembering to say it. A rule you have to remember is a rule you will forget. My skills live here if you want the format: [https://github.com/freema/ai-skills](https://github.com/freema/ai-skills) Genuinely not sure. The feature is marketed as a place to preview code and content, and I'm using it as an internal document surface with a stable URL. Might just be a shape that happens to fit. But "one link that stays current" is quietly the best part of it, and I haven't seen anyone talk about it that way. Are you doing something similar on your team?