The previous post argued that a single HTML file can be a self-modifying application — that the file is the deployment unit, the agent loop is the modification interface, and the browser tab is the habitat. That was an argument about software. This is the same argument, made one level up. It's about documents.
The office suite — Word, Excel, PowerPoint, and the PDFs we generate from them — is overdue for replacement, and the replacement was always going to be HTML. The thing that finally makes the case airtight is what reWritable demonstrated: the file can edit itself, and the user's interface is a sentence.
The office suite is a coordination protocol
The office suite is at its core an agreement. We use docx, xlsx, pptx, and pdf because everyone else does. The handoff is the artifact: someone makes a file, attaches it to an email, and the recipient opens it in a compatible application. This works because three things hold together. The format is widely supported. The editor is widely installed. The viewer is widely installed. Take away any one of them and the protocol breaks: the recipient gets a file they can't open, or can open but not edit, or can edit but the formatting drifts. For thirty years, the office suite has been the only coordination point that satisfies all three.
HTML always had the technical case
HTML was the obvious candidate to replace this stack from at least 1997. Universal. Text-based. Viewable on any device made in the last quarter-century. Style with CSS, calculate with JavaScript, present full-screen, print with @media print. There was nothing the office formats did that HTML couldn't. It lost on one count: you couldn't edit an HTML file the way you edit a Word doc. Opening report.html in a browser showed you the rendered output. Editing it required a separate tool — a text editor, an IDE, an external WYSIWYG editor. The file's editing surface was not the file itself.
The office suite kept its place because of this gap. Word was the only thing that opened a Word document in editable form. The format was the moat.
The gap just closed
reWritable's contribution is small and complete. An HTML file with an embedded LLM API is its own editor. You don't open it in a browser to read and then alt-tab to a different program to modify it. You open it in a browser, and the browser is the editor. ⌘K is the writing surface. The instruction is the edit. This is what the office suite kept exclusive for thirty years: a format that opens, renders, and accepts modifications in the same artifact. Microsoft sold this as a product. It was never a product. It was an integration.
The integration is now available in twenty lines of seed HTML and an OpenRouter key.
The chat is not a bolt-on
The interesting piece — the piece that makes this not just "HTML catches up to Word" — is what an LLM in the document does that a Word installation never could.
A PDF of a contract is opaque. You read it. If something is unclear, you ask a lawyer. A Word document of a financial model is opaque the same way: you can edit numbers, but the model's logic is what someone else built, and changing it requires understanding it. The artifact does not explain itself. An HTML document with an LLM in it can. The entire source is in the agent's context window — prose, styles, data, formulas, structure. The user can ask: what does clause 7 actually require? what would change if I removed this paragraph? summarise the assumptions in this model. re-run the projections with revenue down 15%.
The document is no longer just a thing you read. It is a thing you can interview. And — because the same agent that answers questions can rewrite the file — every interview can become an edit. This is the feature that PDF, Word, and Excel structurally cannot have. Their formats are not the agent's context. The application reads the format; the agent has no relationship with it. You can bolt on Copilot or ChatGPT-in-Word, but those are external services reading external snapshots. The document and the assistant are two things stitched together at runtime. In an HTML file with an embedded LLM, they are one thing. The document is the context. The context is the document.
What replaces what
The office suite is a bundle, and the bundle disaggregates differently for each format.
| Office format | Replacement | What's harder |
|---|---|---|
Word (.docx) |
HTML with prose styling and the runtime | Nothing significant |
Excel (.xlsx) |
HTML with a JS grid and IndexedDB for data | Thirty years of muscle memory and an installed base of macros |
PowerPoint (.pptx) |
HTML with full-screen slides | Nothing significant — revealjs already proved the format works |
| HTML, runtime stripped, read-only | PDF retains a real niche for "this artifact must not change" — legal filings, signed contracts, archival records |
For prose documents and presentations, the displacement is clean. For spreadsheets, it is slow but inevitable: the new artifact is more powerful than the old one in every dimension that matters for non-trivial models, and Excel's lock-in is a coordination problem, not a capability problem. For PDFs, the displacement is partial — HTML replaces the convenience-distribution use case (which is most PDFs in practice), and PDF keeps the freeze-the-artifact use case it was designed for.
The file is the version
If I edit the document and the edits live in my browser, what happens when I attach the file to an email? Does the recipient get my edits, or the original? The recipient gets nothing if you attach the seed file. The seed is the bootstrap — stateless by design, it builds from scratch on first open. Your edits live in your browser, not in the file you downloaded.
⌘S exists for this. Save, in this model, is export. Hitting save serialises document.documentElement.outerHTML — the entire running app, runtime included — and downloads it as a new .html file. The runtime also writes any IndexedDB data into a <script type="application/json" id="app-seed-data"> tag inside that file. When the recipient opens it, the runtime detects the tag, hydrates IndexedDB from it, removes the tag, and the file picks up exactly where the sender left off.
You attach that file. Not the seed.
In Word, save overwrites the file you opened. In reWritable, save creates a new file — every save is a portable snapshot. There is no ambiguity about which version you sent: the file is the version. Git diffs work because it's text. The file you downloaded yesterday is not the file that has your edits. The file with your edits is the one you just exported. The runtime helps — after five rewrites without an export it surfaces a non-modal nudge — but the user-facing rule is one line. Save means make a new file. Send that one.
This is the email model, not the Google Docs model. Two people editing in parallel is not a problem the format solves — it's a problem deferred to git, or to a shared null-origin folder, or to whatever sync layer the user picks. That's the trade-off for not having a server. It's the same trade-off PDFs and Word documents have always had, just with the frozen-artifact assumption removed.
The objections
Formatting. Modern CSS does everything the print engines of the 1990s did. Paged media, page breaks, running headers, font control, columns. The browser is among the most capable layout engines ever shipped, and the only one installed on every device. The "but the layout will break" argument was true twenty years ago. It is not true now.
Offline. Files work offline. The runtime works offline. The agent call requires a network — which is the same constraint Microsoft 365, Google Docs, Notion, and every cloud office product live with. The local-first version is strictly better: the file works offline, only modifications need network.
File size. A docx is a ZIP of XML. A pptx is a ZIP of XML and images. An HTML document with inline assets is comparable in size, often smaller, because there is no XML overhead.
Archival. HTML is the most stable format that has ever shipped. The original pages from CERN in the early 1990s still render. PDF is similarly stable. Word, famously, is not. If you care about "will this open in 2050," HTML is your safest bet.
Trust. "But it has executable code in it." Yes. So does every Excel file with a macro, every PDF with embedded JavaScript, every email with an attachment. The runtime is small, inspectable, and the seed file is text you can read end to end in five minutes. This is more transparent than any binary format the office suite ships.
What the office suite was actually selling
The office suite was selling three things, and only one of them was the file format. The first was a default editor. HTML now has one — every browser, plus the LLM as the writing assistant. The second was network effects. Everyone uses docx, so I have to use docx. This is the strongest lock-in. It does not break in a single news cycle. It breaks the way paper-to-PDF broke: slowly, then all at once, in pockets where the new artifact is good enough to overcome the coordination cost. The third was the illusion of a stable artifact. The file you sent and the file the recipient opened were supposed to be the same thing. Anyone who has emailed a docx across two versions of Word knows this is partly fiction. HTML is the format where the artifact is genuinely stable across viewers — there is exactly one rendering target, and every browser implements it.
When you net out what the office suite is actually doing — providing an editor, a network, and a stability guarantee — HTML now does all three. With one differentiator the bundle structurally cannot match: the document can answer questions about itself.
What's next
The harder problem is not technical. The office suite is a workflow, not just a format. People expect attachments to end in .docx. Compliance teams have approved Microsoft 365 deployments. Auditors look for .xlsx artifacts. The format is the protocol, and changing the protocol is the actual work.
Two things make me think this gets done faster than the docx-to-cloud transition did. The first is that HTML doesn't require migrating anyone — it runs in the tool everyone already has. The second is that the killer capability is asymmetric. Once one team in an organisation discovers that their RFP responses, contracts, or financial models are dramatically more useful as a self-explaining HTML file, the surrounding tooling rearranges around them.
The office suite was a coordination protocol that solved a specific problem: how do many people work on the same kind of file. It solved it by standardising on a bundle of incompatible formats and a single vendor's editor. The problem is still real. The solution is overdue for replacement.
A folder of HTML files with embedded agents is what the replacement looks like. The format is the browser's native format. The editor is the file itself. The collaboration layer is the same as it has been for forty years: sending files. The new piece — the piece that makes the whole thing finally cohere — is that the document is a participant in its own use. You don't just open it. You ask it.
The web was supposed to be read/write. The office suite was the workaround for the part of the read/write web that didn't ship.
It just shipped.
Source and spec: github.com/ikangai/rewritable
The previous post: reWritable: Software that knows how to change itself
The direct ancestor: github.com/ikangai/clive
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.