The previous post made the case that an HTML file with an embedded LLM is the right replacement for the office suite. That argument worked at the level of a single document. The interesting question is what happens when you have more than one. The office suite answered this thirty years ago. The answer was embedding: drop an Excel chart into a Word doc, and Word reaches into Excel to render it. OLE, then COM, then COM+, then DDE before all of them — a sequence of protocols for letting one document hold a piece of another. Every iteration solved real problems. Every iteration also broke in the same place: the connection assumed both applications were installed, both were the right version, and both were running on a machine the IT department had blessed. What I want to describe here is different in kind. Documents do not embed each other. They sit next to each other on a bus.
Embedding was vertical. The bus is horizontal.
OLE and its descendants were built around hierarchy. A container document held a child document. The container knew about the child; the child rendered into the container. If you opened the container without the child's application installed, you got a placeholder. The relationship was structural and asymmetric, and it travelled with the file.
The bus does not work that way. There is no container and no child. Each document is a peer. Documents announce themselves on a shared channel; documents subscribe to announcements they care about. A contract document does not contain the budget document. The contract publishes the fact that it exists, what it is, who it concerns. The budget, if it is open in the same browser context, hears the announcement and decides whether the information is useful. Neither document holds the other. Neither needs the other to render. They are co-resident, not nested.
This is a different protocol shape. Embedding answers how does Word display an Excel chart. The bus answers how does this contract know there is a budget for the same client open in another tab.
What the bus actually is
Concretely, the bus is the fact that two HTML files opened from the local filesystem share an origin. Browsers treat file://URLs as sharing the null origin, which means a BroadcastChannel opened in one document is reachable from another document opened the same way. There is no server in this picture. There is no protocol that needs to be deployed. The bus exists by virtue of the documents being open at the same time on the same machine.
Each document, on open, joins a named channel and publishes a small manifest. The manifest is a JSON object. It declares the document's kind — contract, budget, meeting-notes — and a handful of identifiers — the client name, an effective date, a reference number. It does not publish content. It publishes metadata. The content stays inside the document. Other documents on the channel receive the manifest. Their runtime stores it. When the user invokes ⌘K, the runtime injects relevant peer manifests into the system prompt. The LLM responding to the instruction now knows there is a contract for the same client open in another tab — not the contract's text, just the fact of the contract and its declared metadata.
This is a small piece of plumbing. It is also a different model of how documents relate.
What declarations look like
A document's manifest is data the document is willing to publish about itself. The runtime exposes an API for it; the document fills it in. A contract published from rwa might announce:
{
kind: "contract",
client: "Acme Inc.",
effective: "2026-01-01",
parties: ["Acme Inc.", "Generic Corp"],
reference: "INV-000/2026"
}
A budget for the same client published from another tab might announce:
{
kind: "budget",
client: "Acme Inc.",
period: "2026-Q1"
}
Each document is the authority on its own manifest. Neither document is making claims about the other. There is no contradiction problem because there is no shared belief. There is shared metadata, and the union of manifests is whatever happens to be on the channel right now.
A document subscribes by declaring what it cares about — tell me about contracts, tell me about anything for client X. The runtime filters the channel and surfaces matches. The matches feed into the next prompt as context. The user can ask the budget document what contracts exist for this client, and the document answers from the manifests it has heard, not from a database somewhere.
Why this is not what OLE was
OLE composed documents at the level of presentation. A chart appeared inside a doc because Word and Excel both ran, both spoke the protocol, and one rendered into the other's surface. The composition was visual, immediate, and tightly coupled.
The bus composes documents at the level of awareness. Documents do not render into each other. They know about each other. The composition is informational, asynchronous, and loose. A document on the bus continues to work if every other document is closed. Its layout does not change. Its content does not change. The only thing that changes is that the LLM, on the next ⌘K, has less peripheral context to draw on.
This is the opposite of OLE's failure mode. When the linked Excel file went missing, the Word doc rendered a broken placeholder. When a peer leaves the bus, the documents that were listening simply hear less. There is nothing to break because there is nothing being held.
The trust boundary moves
OLE-era embedding put trust in the application stack. If Word trusted Excel, it ran Excel macros to render the embedded chart. The trust boundary was at install time, at the OS level, mediated by the office suite's vendor.
The bus puts trust in the listener. Each document decides what it does with what it hears. A manifest arriving on the channel is data, not instruction. The document's runtime treats it as input to the LLM's context — which means the document has to be deliberate about what gets injected and how. A manifest that contains carefully crafted text could be a prompt-injection vector against any document that picks it up. The runtime treats peer manifests the way it treats any other untrusted input: structured, schema-checked, never executed, never shown to the user without provenance.
This is a real constraint, and one OLE never had to think about. OLE's trust problems were about whether the embedded application was malware. The bus's trust problems are about whether the published manifest is trying to manipulate the consuming document's LLM. The constraint shapes the protocol: small declarative manifests, fixed schema, no free-form text fields that flow into prompts unchecked.
Persistence ends with the session
A bus organised this way has no memory across sessions. Open three documents, the bus has three manifests. Close them, the bus is gone. Open one of the documents tomorrow, it announces itself to a bus that, today, has only itself on it. There is no persistent graph, no central index, nothing that survives the browser tabs being closed.
This is a deliberate choice. The format's whole pitch is that the file is the thing. A persistent cross-document store would mean the workspace lives somewhere — a database, a service, a hidden coordinating file. Every option is a step away from "send the document by email and the recipient has it." The bus stays session-scoped because the alternative compromises the thing that makes the format defensible.
The trade is real. A user with a hundred related documents does not get a knowledge graph. They get a knowledge graph among the documents they have open right now. For most use cases — I am working on this client's account today — that is exactly the right scope. For the use case of show me everything I have ever written about this client, the bus is not the answer. Search across files is the answer, and search across files is a different tool.
What this enables that embedding could not
Embedding let you put a chart in a doc. The bus lets a doc know there is a chart. These sound similar; they are not.
A document that knows about its peers can act on that knowledge through the LLM. The contract can answer do I match the budget that's open right now. The meeting notes can answer which decisions in this meeting affected open contracts. The budget can answer what assumptions are inherited from the contract. None of these queries require the documents to render into each other. They require only that the documents hear each other's manifests and that an LLM can reason over the union.
Embedding let documents share pixels. The bus lets documents share judgment. The chart-in-the-doc was a visual feature. A contract that knows it has a budget is an analytical one. The first composes outputs. The second composes meaning.
This is the move that embedding could not make, because embedding had no LLM in the picture. OLE was a protocol from a world where documents did not reason. A document on the bus reasons about every other document on the bus, in the user's own words, in the moment the user asks.
What the bus is not
The bus is not real-time collaboration. Two users with the same document open in different browsers are not on the same bus. The null-origin scope is this machine, this browser context. Nothing in this protocol crosses machines. Crossing machines would require a server, and a server is the thing the format is structurally trying to avoid.
The bus is not a database. Manifests are not records. There is no query language, no schema enforcement, no persistence. The runtime offers the LLM a list of here are the documents I have heard from, and the LLM does the rest. Asking the bus to behave like a database is asking it to be something else.
The bus is not a knowledge graph in the Notion or Roam sense. Those tools are centralised by design — one workspace, one source of truth, one engine indexing everything. The bus is the inverse: no centre, no source of truth, no indexer. Each document is the authority on itself, and the graph exists only when the documents are co-resident.
Where this leaves the format
The previous post argued that an HTML file with an embedded LLM is the unit of the new office suite. The bus is the answer to what is the workspace.
The workspace is a folder of HTML files. When you open them, they hear each other. When you close them, they go quiet. The folder on disk is the persistent layer; the bus in the browser is the active layer. A team's project is the folder. A user's session is whichever subset of the folder is open right now.
This is the same model that desktops have always used — files in folders, the user opens what they need — extended with a property files have never had before. Open files now know about the other open files. The knowledge does not travel with the document, does not pollute its content, does not survive the session. It exists for as long as it is useful and stops existing when it is not.
The office suite tried to solve cross-document composition through embedding. The integration was tight and the failure modes were brittle. The bus solves a smaller problem with a looser protocol: documents publish what they are, listen for what they care about, and reason over the rest. There is no application to install, no server to run, no central store to govern.
The documents are talking to each other. Nobody is in the middle.
Source and spec: github.com/ikangai/rewritable The previous post: The document is the application
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.