One Sentence, 198 Pages: AI Agents Rewrote Their Reports

round            pages   source before   source after
first pass          36        2,350 KB         708 KB
first retry          8          559 KB         175 KB
second retry        18        1,603 KB         482 KB
total               62        4,513 KB       1,365 KB   (-70%)

198 pages reviewed, 13 closed, 62 converted, 0 stored answers lost

What the Brief Asked For

Our fleet writes a lot of pages: status boards, reviews, plans and long tables, each one a standalone web page an agent wrote by hand. Handwritten pages are expensive in the one currency that matters to an agent, which is tokens. A single 500 KB audit page costs a model a large share of a working session to read, edit or regenerate.

So the platform got a second way to write a page: a short source file made of plain text plus a fixed set of building blocks, such as a decision card, a findings list, a chart or a data table. The page is generated from that source. The brief he sent was the same for every agent:

• Close each open page that is done or obsolete. Never delete one.
• Convert a page to the new format only if the building blocks cover it with the same content, the same answer controls and the stored answers still there.
• If a page cannot be converted, keep it as it is and name the missing piece.
• Check every page you change before and after, at phone width and at desktop width, and roll it back if anything is lost.

He did not tell the agents how to do it. He told them what counted as done.

The Loop That Made It Work

Round one was modest: 36 pages, 2,350 KB down to 708 KB. The valuable output of round one was the list of what blocked everything else. Agents reported the same few gaps: a row of links, small status chips, a way to show a finished decision as a result instead of as an open question, and inline diagrams. Each report named a missing piece, not a feeling.

The engine shipped those pieces in two releases overnight. The agents ran the brief again. The first retry converted 8 pages (559 KB to 175 KB) and the second 18 (1,603 KB to 482 KB). The reports of what blocked the agents were the specification for the next release. That is the part I would copy first if you run agents: make "what blocks me" a required line in every report, and treat the answers as a backlog.

Three Pages That Show It

• A 227-row audit table: 502 KB of handwritten HTML became 69 KB of source, and the reader gets a sortable, filterable data table instead of a static one.
• A 5,000-row URL table: 54.6 KB became 8.6 KB.
• A board with 23 decisions: it converted with every stored answer kept. This was the check that mattered most, because a board that forgets an answer is worse than a big page.

Want more like this?

New posts in your inbox, a few a month.

Email address subscribe

Website

By signing up you agree to receive articles, product news and offers from XNDR by email. We measure whether emails are opened and which links are clicked, and you can leave in one click. Privacy policy.

What the Numbers Do Not Say

A result that is only good news is an advertisement, so here are the limits.

• The page a visitor downloads is not smaller. The saving is in what an agent reads and writes. The generated page is still a normal web page.
• Most pages are still in the old format. Live apps, canvases and slide decks do not fit a fixed set of blocks, and they were left alone. 62 of 198 is a third of the pages, not most of them.
• The "content updated" counts are the agents' own. Each agent reported what it changed on its pages. I have not audited all of them.
• The figures come from the agents' result reports, compiled by the admin agent. I checked that the rounds add up (36 + 8 + 18 = 62 pages, 708 + 175 + 482 = 1,365 KB). I did not re-measure every page.

How Other Agent Tools Handle Agent-Written Pages

I read the official documentation of three tools on 18 October 2026. I did not run them, so this is what their docs say and where I found nothing.

• Claude Code artifacts: the agent writes one self-contained page as an .html, .htm or .md file, and the rendered page must be 16 MiB or smaller. Each publish becomes a version of the same page. The docs say a styled page costs more output tokens than the same content as terminal text, and suggest SVG over images and summarising large datasets to keep it down. The agent writes the whole page each time. See the artifacts documentation.
• OpenClaw Canvas: an agent-controlled panel inside the macOS app. The agent can put HTML, CSS and JavaScript or a structured A2UI message in it, and the docs say only A2UI v0.8 messages are accepted. A structured message format is the nearest thing to a fixed set of blocks that I found. I found no documented way to publish a canvas as a shareable page. See the Canvas documentation.
• Hermes Agent: its scheduled jobs deliver the agent's final response to a chat target or save it as a Markdown file in a local output folder. The scheduling page does not mention agents publishing HTML pages or documents. See the scheduled jobs documentation.

None of these is wrong for what it does. The difference is where the structure lives. In the first, the agent holds all of it on every write. In the second, a message format holds some. In what we built, the platform holds the vocabulary and the agent only chooses blocks.

What I Would Copy If You Run Agents

1. Give agents a small fixed vocabulary of blocks for the documents they write all the time, and leave free-form pages for the rare case.
2. Define done in the brief, including what must not be lost. "Zero stored answers lost" was the line every agent checked.
3. Make blockers a report field. Agents are good at naming what stopped them when you ask for it, and each name becomes a small, testable change.
4. Count source size where the agent works, not page weight in the browser. They are different numbers and only one of them is your token bill.

We run this kind of fleet daily, and the same pattern ran through the earlier posts: controlling a Claude Code session from a phone and diagnosing Windows with Claude Code. If you want agents that do real recurring work for your team, that is what XNDR builds.

FAQ

How much smaller are agent-written pages with a fixed set of building blocks?

In one overnight run, 62 pages went from 4,513 KB of page source to 1,365 KB, a 70% reduction. One 227-row audit table went from 502 KB to 69 KB. The saving is in what the agent reads and writes, not in what a visitor downloads.

Does a smaller page source make the page load faster?

No. The generated page a visitor downloads is not smaller, so load time does not change. The gain is that an agent spends fewer tokens to read, edit or regenerate the page.

Can AI agents convert their own pages without losing data?

In this run, yes: 0 stored answers were lost across the 62 converted pages, including a board with 23 decisions. The brief told each agent to compare before and after and to roll a page back on any loss. I checked the totals, not every page.

Which pages cannot be converted to a fixed set of blocks?

Live apps, canvases and slide decks, plus any page that needs a piece the vocabulary does not have yet. In this run 123 of 198 pages were neither closed nor converted. Each page the agents could not convert came back with the missing piece named.

Related Articles

• Building a Telegram-to-CLI Bridge for Claude Code
• Diagnosing Windows with Claude Code
• XNDR work: projects built and tested end to end.
• XNDR services: AI agents and automation for real recurring work.

Liked this one? Get the next in your inbox.

New posts and the odd product note, a few emails a month. Easy to leave.

Email address subscribe

Website

By signing up you agree to receive articles, product news and offers from XNDR by email. We measure whether emails are opened and which links are clicked, and you can leave in one click. Privacy policy.