HTML instead of Markdown as agent output: what a design call from the Claude Code team means for Mittelstand stacks
On 8 May 2026 Thariq Shihipar from the Claude Code team published a thread that has been widely discussed in the tech industry ever since. His suggestion: have agents return HTML by default instead of Markdown. Simon Willison flipped his three-year Markdown default. For Mittelstand stacks the story is not a headline but an architecture question — who renders where, who sanitises what and where does the reliable source of truth live.
The 90-second summary
On 8 May 2026 Thariq Shihipar from the Claude Code team at Anthropic published a thread on X that has been widely discussed in the tech industry ever since: he argues for having agents return HTML by default instead of Markdown. The reasoning is pragmatic — HTML can express nested tables, inline SVGs, diagrams, jump anchors and small interactive widgets that Markdown cannot. The thread is accompanied by a collection of twenty concrete examples. In his link-blog reaction, Simon Willison disclosed that after three years of a Markdown default he is changing his workflow. For Mittelstand stacks the story is not a headline but an architecture question: in which output format should an agent answer in your organisation, who renders that and how, and how well does your CMS and security setup keep up?
What is actually new this week
The Thariq thread is not a product launch and not a model update. It is a reasoned design choice from the team that builds Claude Code. The argument goes like this. In the GPT-4 days an 8,192-token context window was tight, and Markdown saved enough tokens over HTML to establish itself as the default. That tightness is gone today. What remains is the question of which format can carry more information in the same answer. Here Markdown systematically loses: no merged table cells, no colour coding, no inline SVG sketch, no short collapsible navigation. HTML can do all of that, and a model like Claude Opus 4.7 produces it reliably.
Alongside the thread Thariq published a collection of twenty HTML examples — pull-request reviews, code explanations, architecture diagrams, data analyses, onboarding documents. Each example is a single self-contained HTML file that runs in the browser without external dependencies. Simon Willison stated publicly the same day that he is dropping his Markdown default, and documented that on his link blog.
From an engineering practice perspective this is a plausible shift. From an architecture and procurement view in the Mittelstand it raises follow-up questions that the industry discussion has so far paid little attention to.
What it means for the Mittelstand
If you are running agents in production today or planning to, the output-format discussion touches four places in your stack.
The first is the editorial workflow. If a research or briefing agent in future delivers an HTML document instead of a Markdown file, editors get a richer template — tables, jump anchors, embedded diagrams — that fits more directly into the finished look of a CMS page. Your TYPO3 backends already work with HTML body fields; the conversion of Markdown back into HTML disappears. At the same time, manual editing becomes more demanding, because HTML offers more places to hide structural problems than Markdown.
The second is delivery. As soon as HTML enters the output path, you should have a clear answer to where this HTML is rendered and in which security contexts. An HTML snippet from an agent is untrusted input until proven otherwise. Internal wiki, Slack channel, email and CMS frontend each have different sanitisation, CSP and tracking rules. Anyone who lets agents respond in HTML without having set those rules first ends up with untested DOM structures in productive render paths.
The third is versioning. Markdown can be diffed in Git, linted in CI pipelines, and previewed in Slack. HTML can do that too, but with significantly more noise — a changed class, an additional style attribute, an embedded SVG coordinate produce diffs that are barely readable without tooling. Mittelstand teams that version agent-generated content should decide whether they treat the HTML file or an underlying structured format as the source of truth.
The fourth is the interface between agent and human. When an agent returns an answer as an interactive HTML widget, it changes how humans review the result. A well-designed HTML briefing allows quick jumping, sorting and filtering. A poorly designed one hides content behind toggles. Both need to be reflected in your quality gate for agent output, otherwise you end up with reports that look great but bury essential data behind UI effects.
Technical developments in detail
At the stack level, there are three points worth knowing if you want to translate the idea into your own architecture.
Prompt pattern. Thariq’s examples follow a consistent pattern: state the task, name the target format “HTML artifact”, and explicitly call out desired structural elements (tables with inline annotations, colour-coded severity, jump navigation). This works substantially better than a generic “respond in HTML”. In Kim Lab testing, Claude Opus 4.7 produces HTML outputs with this prompt pattern that are usable in a CMS backend without further polishing.
Sandbox and sanitisation. Self-contained HTML files with inline CSS and occasional JavaScript snippets run harmlessly in a local browser. As soon as that output moves into a multi-user environment — say as TYPO3 body text, as email HTML or as a Slack card — you need a clear sanitiser strategy. In our stacks we use HTML Purifier with a tailored tag and attribute list for agent-generated content, plus a Content Security Policy that blocks inline scripts and external stylesheets in agent-generated areas. Anyone who lets agents write directly into a frontend renderer without this layer is courting XSS vectors via model hallucinations.
Storage and render path. Two architectures make sense. First: the agent delivers HTML, this is stored in a structured store (CMS field, Markdown with HTML blocks, JSON schema with HTML substrings), and the frontend renders it under control. Second: the agent delivers a structured format (for example a custom JSON schema), and a downstream renderer turns it into HTML — the HTML path stays under your control. Which variant suits your use case depends on how much creative freedom the output needs and how strict layout and security requirements are. For pull-request reviews and ad-hoc briefings variant one is faster. For productive customer communication variant two is cleaner.
What we actually observe
In our own TYPO3 stacks we tested the idea this week on a small, controlled piece of workflow — the generation of weekly briefings for internal stakeholders. Switching from Markdown to HTML made the briefings noticeably denser: tables with merged rows, small sparkline SVGs for metrics, clickable jump anchors in multi-section reports. At the same time we learned that versioning the generated HTML files without an upstream JSON intermediate format gets messy very quickly. For internal briefings the trade-off is acceptable. For external communication, we hold the JSON intermediate as the source of truth to be the more reliable architecture.
Frequently asked questions about the HTML-instead-of-Markdown debate
Does this mean we should give up Markdown in agent workflows?+
No. Markdown remains the better default for everything that lives as source text — Git repos, CI logs, technical documentation, pull-request descriptions, Slack threads. Thariq’s HTML proposal targets output that is read and not further edited: briefings, reports, explanations, reviews, onboarding documents. For that class of output the switch is justified. For everything else Markdown remains the sensible choice.
How do we handle HTML output safely in a CMS frontend?+
With a sanitiser layer and a tailored Content Security Policy. We recommend never letting agent-generated HTML strings reach a productive render path unfiltered — an HTML Purifier step with a tightly curated allowlist for tags and attributes, plus a CSP that blocks inline scripts in agent-generated areas, is the minimum. Anyone letting agents write directly into frontend code should only do so inside an isolated sandbox iframe.
Is the switch worthwhile for internal briefings in the Mittelstand?+
For internal reports with a data focus, often yes — tables, small charts and jump navigation noticeably improve the reading flow. For pure text briefings without data elements, Markdown remains more practical because it flows more easily through Git and tickets. Try it on a clearly scoped workflow — a weekly report, for instance — before triggering a larger rollout.
How does this relate to structured output formats like JSON schema?+
Complementary. JSON schema is ideal for machine-readable outputs that a downstream renderer turns into HTML or another representation. HTML-direct is ideal for human-readable outputs where you do not want to build a renderer between model and display. In productive architectures we often see a combination: the model writes into an internal schema, and a simple renderer turns it into HTML which we sanitise and serve under control.
What does this concretely mean for TYPO3 editorial teams?+
If your stack moves agent-generated content into the CMS, one conversion layer goes away. TYPO3 body-text fields are RTE-HTML; agent-generated HTML can flow in directly — provided it has been sanitised cleanly first and sticks to the tag allowlist of your RTE profile. For container CTypes, FAQ cards and blog-hero fields this is a direct gain. Make sure your sanitiser profile is consistent with the TYPO3 RTE profile, otherwise tags get stripped and layouts break.
How do we measure whether HTML output is really better for our purposes?+
Three metrics, all easy to collect. The time a human reviewer needs per briefing — if it drops, the format change is a win. The number of follow-up questions a briefing triggers — if that drops too, even better. And the number of revisions needed before the document can be shared — if that rises, your sanitiser or prompt pattern is not mature yet.
We look at your output path together with you.
If you are considering whether HTML output is the better default for one of your agent workflows, we will spend 30 minutes with you looking at the specific use case and sorting which sanitiser, CSP and render-path layers need to be prepared in your stack. No pitch — a working session with a concrete outcome.
Conclusion
The HTML-instead-of-Markdown discussion is not a fashion trend but a sensible shift that was overdue anyway, given larger context windows and more mature models. For Mittelstand stacks it is less a format decision than an architecture question: who renders where, who sanitises what, and where the reliable source of truth lives. Anyone who thinks the output path of their agents through cleanly today has less cleanup ahead in twelve months. Anyone who does not will build a second generation of legacy Markdown converters that nobody will want to maintain.