From Markdown to HTML Artifacts: The New Default Output Format for AI Agents

A practical guide to switching your default agent output format from Markdown to HTML — with prompt patterns, publishing setup, and when to keep using Markdown.

The shift in one paragraph

For four years, AI agents have defaulted to Markdown for almost every human-facing output. In May 2026, an Anthropic engineer named Thariq Shihipar made the case that this default is outdated. Context windows have grown 100x. Frontier models can produce rich HTML as cheaply as they once produced Markdown. And HTML — with SVG, CSS, interactive widgets, real typography — is a fundamentally better surface for the humans who actually read agent output.

This is the practical playbook for adopting the new default in your own workflow.

What you're switching from and to

Before (Markdown default):

Plans are bulleted lists
Reports are headers + tables + paragraphs
Reviews are numbered findings in prose
Status updates are plaintext

After (HTML artifact default):

Plans are interactive pages with collapsible sections, mockups, and code excerpts
Reports are styled documents with sortable tables, embedded charts, and color hierarchy
Reviews are diffs with inline annotations and severity colors
Status updates are scroll-narrated pages with metric callouts

Same information. Different ergonomic surface.

The four prompt patterns

Here are the four prompt patterns that move you from Markdown defaults to HTML artifacts. Drop these into your system prompt or the start of any task.

Pattern 1: The plan artifact

"Create an HTML file with a plan for [task]. Visualize the dependency graph as inline SVG. Include code excerpts where relevant. Add a 'Risks' section with severity color-coding. Use tabs to separate Plan, Implementation, and Open Questions. Self-contained — inline all CSS and JS."

Pattern 2: The review artifact

"Help me review this PR by creating a single HTML artifact. Render the actual diff with inline margin annotations. Color-code findings by severity (red / orange / yellow). Add a summary at the top with risk assessment and a recommended action."

Pattern 3: The report artifact

"Generate an HTML report summarizing [data]. Use a sortable table for the underlying numbers. Add inline SVG charts for the key metrics. Include an executive summary section that's visually distinct. Keep it as a single self-contained HTML file."

Pattern 4: The micro-app artifact

"Build a single-purpose HTML page where I can [interact with X]. No backend — keep all state client-side. Include simple controls for [action], a live preview area, and a summary of the current state. Inline all CSS and JS."

Each of these produces an artifact that's an order of magnitude more useful than the Markdown equivalent. The cost is roughly 2–4x more tokens — which, against a million-token context window, is roughly nothing.

The "self-contained" requirement

The single most important word in those prompts is self-contained. You want one HTML file with everything inlined: CSS, JavaScript, even small images as data URIs. Why:

It's one file you can drop on host-html and publish immediately
It works offline if you save it
There are no broken external dependencies six months later
It can be emailed or attached if needed

Tell your agent: "single self-contained HTML file, no external dependencies." That phrase will save you from a hundred small frustrations.

The publishing step

An HTML artifact that lives on your disk is half a solution. The pattern only really works when publishing is one step away.

The fastest path: drag and drop

1. Save the agent's output as artifact.html

2. Drop it on host-html

3. Click publish, copy URL, share

The agent-driven path: the skills protocol

Install once:

npx skills add phanosh/host-html --skill hosthtml-publish -g -y

Then any skills-protocol-aware agent (Claude Code, Cursor, Windsurf) can publish HTML inside the conversation:

"Publish this as a web page."

The agent calls the skill, sends the HTML, returns the URL. No file shuffling.

The programmatic path: REST API

For scripts and custom pipelines:

HOSTHTML_API_KEY="hh_YOUR_API_KEY"
curl -X POST https://suifgsvtcbrawzdhyuhk.supabase.co/functions/v1/publish \
  -H "Authorization: Bearer $HOSTHTML_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"html": "..."}'

Response includes a public URL plus an edit_token. Keep the token with the page — it's reserved for a future update endpoint (publishing is currently create-only).

When NOT to use HTML artifacts

It's important not to over-rotate. HTML isn't always the right answer.

Keep Markdown for:

Agent-to-agent state (one agent's output feeding into another agent's input)
README files, CONTRIBUTING guides, source-controlled documentation
Quick conversational responses ("what does this error mean?")
Anything that needs to be greppable by humans across years
Logs, structured outputs, tool results

Use HTML artifacts for:

Anything a human will read carefully (plans, reviews, reports, status updates)
Anything that benefits from visual hierarchy beyond headers + bullets
Anything you want to share via a URL with collaborators
Anything where interactivity adds value (calculators, comparisons, dashboards)

The simple rule: is the consumer a human reading carefully, or a model reading mechanically? Humans get HTML. Models get Markdown.

A 5-minute experiment to convince yourself

If you're skeptical, run this test in any agent of your choice:

1. Pick a real task you'd normally get a Markdown output for — a project plan, a code review, a quarterly report

2. Run it once with your normal prompt. Save the output.

3. Run it again with: "as a single self-contained HTML file with appropriate visual hierarchy, color coding, and interactive elements where useful."

4. Save the result as artifact.html and open it in a browser

5. Compare side-by-side

The Markdown version reads like a document. The HTML version reads like a product. That difference, replayed across every meaningful artifact your team produces, is what the "HTML is the new Markdown" framing is pointing at.

What this means for tooling and platforms

A few predictions that follow from the trend, written down so we can check back in six months:

1. More agents will ship with built-in publishing. Generating an HTML artifact and not publishing it is half a feature. The complete loop is: generate → publish → share. Agents that don't close the loop will feel broken.

2. The publishing layer becomes critical infrastructure. host-html is built for this. So are similar tools that will emerge. The "agent produces artifact → artifact gets a URL" path needs to be as friction-free as possible.

3. Output format becomes a UX surface. Prompt engineering for output format — "as an HTML artifact with..." — becomes a baseline skill, the same way "be concise" became a baseline skill in 2023.

4. Markdown doesn't die. It retreats to its real use case: agent-to-agent communication and source-controlled docs. Both still matter. Neither is what a status update should be.

The full loop, end to end

Putting all of this together, the workflow for shipping an HTML artifact in 2026 looks like this:

1. Prompt the agent with an HTML-artifact pattern

2. Iterate in conversation until the artifact looks right

3. Publish via the agent skill or REST API — the agent calls host-html and returns a URL

4. Share the URL in Slack, email, or your meeting

5. Discard or archive — free pages auto-expire after a few days, so the internet stays tidy

Total elapsed time: minutes. Friction: near zero. Result: a polished, interactive page on the open web that anyone with the URL can view.

That's the new normal. Worth adopting before the rest of your team catches up.