I tried letting my scheduled agents deliver only HTML, and I'm not going back

A couple weeks ago Thariq published "Using Claude Code: The Unreasonable Effectiveness of HTML," and it hit 12.6M views. His argument: Markdown has become the bottleneck for agent output, and he's almost completely switched to HTML.

I read it at the time and shrugged. Markdown is simple, diffable, greppable, cheap on tokens, and easy to hand off between agents. I figured this was a taste thing, not worth touching, and I left it alone.

Then yesterday I came across a repo called html-anything. The tagline: "Markdown is the draft, HTML is what humans read." That hit a nerve. So I just tried it, lol.

Today I changed the output format on a few cron jobs inside X Manager (the X content management agent I run myself). Instead of pasting Markdown into Telegram, each job now delivers one HTML report. I expected this to be heavy: new rendering scaffolding, storage paths to wire up, maybe a rebuild of the downstream review flow. I even ran a benchmark first.

Turns out the entire cost was 51ms of extra render time per run.

Way easier on the eyes.

The original mess

My X Manager cron runs more than a dozen stages a day: scan timeline, check mentions, aggregate key accounts, generate draft packs, surface decisions for me. After each stage, the agent dumps about 2,000 words of source data, cron history, risks, and next actions into Telegram all at once.

The content was all correct. The problem was I couldn't read it. The chat turned into one long wall of text, important state buried, and the next stage had to guess what the previous one said.

At first I thought it was a length problem and wanted to give the agent stricter summary constraints. After a while I realized output length was secondary. The real block was that the chat surface itself wasn't supposed to be doing this job. I also really wanted every final decision to be mine, which meant I had to actually read all the output. Telegram is an IM tool, built for 5-line notifications. Cramming a 2,000-word technical report into it just breaks it.

My blind spot was never really about Markdown itself. Markdown as source is fine. The problem was I'd been using it as a review surface, forcing myself to read long Markdown reports the agent generated. That drains real energy.

The new delivery contract

I changed the output contract for the agent's cron jobs. Each real run now produces three things:

• A 5-line chat summary into Telegram: verdict, stage state, next action. Nothing more.

• A persistent Markdown file under content/memory/daily/, the source of truth and the input for the next agent.

• An HTML report into the gateway's outbound directory, the review surface for humans.

Markdown stays the source. HTML is for humans. Telegram is just for notifications.

The 51ms cost

I benchmarked it on the 12:30 stage. Source Markdown 22.4KB, local read in 0.000016 seconds, Markdown-to-HTML render in 0.0508 seconds. That works out to about 51ms extra per run.

For an agent task that runs for minutes, that overhead is below the noise floor.

I thought the expensive part would be the rendering. Turns out rendering is only tens of milliseconds. What was actually eating my energy was the cognitive cost of opening Telegram every day and staring at that wall of text. My brain felt like mush by the end of the day.

Markdown and HTML do different jobs

Once that clicked, the rule was clear:

• Markdown is the source. The next agent reads it, greps it, indexes it, version-controls it.

• HTML is the handoff. Humans open it, scan it, forward it, confirm the next step.

Use both, and one agent run leaves behind two things: the source material, and a finished product humans can read directly.

Pretty HTML isn't enough. You need an artifact contract.

Just rendering the output as HTML isn't enough. A usable agent report has to preserve these fields:

• Source chain: what the previous stage saw and which sources it used.

• The latest direction from the user that day.

• Current stage state.

• Risks and factual guardrails.

• Budget and tools used.

• Whether public actions need confirmation (this one matters a lot to me, since posting on X requires my manual approval).

• Next action.

Pretty HTML plus this contract is what counts as delivery. Without the contract, you've just got a nicely formatted piece of waste paper.

The same rule for any long-running agent

I ended up applying this rule to every scheduled agent I run. Claude Code on long tasks, Codex on batch refactors, subagents on multi-step reasoning. Anything where the run takes more than a minute or two shouldn't end with a wall of text in a chat box.

It should be an artifact contract. Three pieces:

• Source = Markdown

• Report = HTML

• Summary = chat

Where I landed

I thought figuring out a new framework would eat my whole afternoon. The actual work: change the cron output function, add an HTML template, write the artifact to the outbound directory. Three steps. 51ms of extra render per run, and the most annoying part of my day is gone.

Reading the output now feels great.

I'm not going back.

Everything I'm writing as I build: voxyz.ai/insights.

References

• Thariq, "Using Claude Code: The Unreasonable Effectiveness of HTML," X, 2026-05-08.

• html-anything: github.com/nexu-io/html-anything.