HTML for humans, markdown for machines

Two pieces have been doing the rounds on what AI agents should produce as output. Thariq Shihipar's html-effectiveness gallery makes the case that LLMs ought to be emitting interactive HTML artifacts rather than walls of markdown - diff viewers, throwable prototypes, call-graph explorers, design-system docs you actually click through. Rob Hammond's "Evil things HTML can do" makes the opposite case, that normalising agent-generated HTML trains users to execute code from strangers, opens pastejacking through doctored copy buttons, smuggles prompt injection through hidden comments, and reopens the protocol-handler attack surface most of us forgot existed.

Both are right. They're answering different questions.

The question that resolves it is who reads the output next. If the next reader is a human looking at one artifact one time, HTML is the obvious choice; spatial relationships render, interactions can be felt rather than described, and a thirty-second click-through beats ten minutes of prose. If the next reader is another agent (a planner consuming a researcher's notes, an orchestrator picking up a sub-task's result, a downstream tool ingesting a report) HTML is approximately the worst format you could pick. It's token-heavy, brittle to grep, ambiguous to parse, and the whole point of the visual layer is wasted on a model that's about to flatten it back to a DOM tree anyway.

We've ended up with a working rule on this across our own agent systems. HTML and SVG are terminal outputs - leaves of the chain, generated once, rendered once, never piped onward. Markdown, JSON, and plain text are the composable formats - the middle of the chain, where structure has to survive being read, edited, diffed, and handed to the next step. A Ledga risk summary rendered for a treasury operator is HTML with charts. The same analysis consumed by the alerting agent that decides whether to page someone is JSON. They're the same underlying work; the medium changes because the consumer changed.

Most of the agent frameworks we look at still get this backwards. They emit HTML in the middle of the loop, where it bloats context and resists composition, and they emit markdown at the leaves, where the human reader would have happily clicked through a richer artifact. Thariq's camp is right about the leaves. Hammond's camp is right that the leaves need handling.

Which is where Hammond's piece deserves more credit than it's getting. AI-generated HTML is the macro-enabled Word document of 2026, and the industry has collectively forgotten the playbook we built for the last round of this problem. Office's answer to macros was Protected View, a no-execute default, signed provenance, and a one-click "this came from outside, are you sure" prompt you have to dismiss before any code runs. Email's answer to attachments was a sandboxed preview and an explicit warning shelf. PDF readers learned the same lesson the same decade.

Agent-generated HTML needs the same furniture, and almost none of it ships by default in the tools we use. A sandboxed iframe with JavaScript off until the user opts in. A clear "this artifact was generated by [agent] from [prompt]" provenance banner that survives copy and re-share. Copy buttons that copy exactly the visible text and nothing else, including no leading "!" that an upstream Claude Code session would obediently execute. No protocol handlers without confirmation. A diff against the previous version of the same artifact when one exists, so file-swap attacks aren't invisible. None of this is exotic; it's the trust UX we built for Office macros twenty years ago, and we shouldn't have to invent it twice.

Until that layer ships, the working rule holds. HTML for the human at the end. Markdown for everything else along the way.