try emailingSOMEONEyour app

software became something you cAn't hand to anyOne

Seriously — try it. Not a link to your app, the app itself. What would you even attach? A modern application is a git repository, a node_modules folder with forty thousand files in it, a Dockerfile, six environment variables, a database living in somebody's datacenter in Virginia, and a deploy pipeline held together with YAML. There is no thing. Nothing you can copy, carry, send, or keep. The software exists only as a process — a relationship between a dozen services that all have to be standing at once.

Here's what makes that strange: computing already produced the perfect handable artifact, decades ago, and it's the most successful file format in history. An HTML file opens on any device made in the last twenty-five years. Any browser, any operating system, no installer, no app store, no account. It has carried the entire web, for generations of hardware, without breaking. We just never asked it to do more than hold a page.

A workbook asks it to do more.

the DEFINITION

The name is literal. A paper workbook is a textbook, your worked answers, and your notes in the margins — one binding, no loose pages. A workbook is that for software: the program, its data, and the record of its own making, travelling as one object.

That's the whole idea. Everything below is unpacking it.

open ONE up

A workbook doesn't hide what it is. Crack one open and every layer inside is a standard you've heard of — that's deliberate. No invented format, no proprietary container. The trick isn't a new ingredient; it's that nobody had put the existing ones in the same file.

Download a workbook — open one up for real hello-workbook.html · 11 KB · it explains itself the moment you open it — real WebAssembly, data, and memory, straight from your downloads folder

HTML, CSS, JavaScript — the part you know

The face of the file is an ordinary web page, which means it renders the same interface on every screen on earth. And CSS matters more than it gets credit for: it has quietly become the objective language of design — not just for apps, but for everything code touches now. We use code to make videos, write books, build brands, tell stories. All of it needs design, and CSS is how design gets said precisely.

WebAssembly — the part you didn't expect

You've probably never written WebAssembly, and that's normal — almost nobody writes it. You write C, Rust, Go, Python, and it compiles to WebAssembly. What it does for a workbook is make the file genuinely polyglot: real, assembly-level computation in nearly any language, running inside the page. And because WebAssembly was born in the browser — one of the most isolated, battle-tested environments ever shipped — all that computation is sandboxed by birthright. Keep that word, sandboxed; it comes back.

SQLite — a real database, in the file

SQLite is the most deployed database engine in the world, and the whole thing fits in a single binary. A workbook carries one. That gives every workbook a standard, queryable database — and something subtler: a virtual file system. Folders and files an agent or a program can read and write, living entirely inside the workbook. Images, video, documents, memory — all of it travels with the file.

gzip — the binding

A workbook is natively compressed, the way the web already compresses everything in transit. But it's compressed with its structure still legible — the file knows where its own parts are, so a tool (or an engine) can route to one layer without unpacking the world.

The org layer — the part you write

Threaded through the file is a plain-text layer of notes, tasks, and configuration that both people and agents read and write. It's the workbook's memory and intent — and it's interesting enough to get its own section below.

so is it a dOcument or an aPp?

Yes.

That's not a dodge — dissolving that line is the point. The same format carries:

• A report whose charts are live queries against the data riding in the file.
• A brand book that carries the fonts, palettes, and assets it describes.
• A store dashboard — inventory and orders in the SQLite, interface up front.
• A game, compute in WebAssembly, save-files in the database.
• An agent's workspace — its files, its memory, its tools, in one sendable object.

Today those live in five different systems — a doc tool, a design tool, a SaaS dashboard, an app store, an agent platform — each with its own accounts, exports, and silos. The workbook's bet is that they're all the same shape: interface + code + data, and one honest file can hold that shape.

"isn't this just a zIp file?"

Fair question — it's compressed and it has things inside. But a zip is storage. It's inert: unpack it or nothing happens, and the archive couldn't care less what it holds. A workbook is runnable — double-click it and it opens, renders, computes. The structure inside isn't cargo, it's anatomy.

"Okay — so it's a container image"

Closer, and this comparison is worth slowing down for. A container image also packages software with everything it needs. But an image is a build artifact for a Linux kernel: it needs a daemon installed, it behaves differently across operating systems, and if you've ever burned an afternoon getting Docker Desktop to reproduce a sandbox that worked fine on your coworker's machine, you know the tax. It's a format for infrastructure people, full stop. And you can't open one — there's nothing to see.

Here's the move that makes workbooks interesting: a workbook plays both roles. Opened in a browser, it's a document — readable, viewable, shareable. Docked into an engine, it behaves like a container image: its WebAssembly is the executable surface, its SQLite is the disk, and the engine isolates and runs it exactly the way a kernel runs an image. Same file, no conversion step.

The engine half of that story is the Nexus, and it gets its own page.

the WRITABLE layer

depth rung · skippable — skip to agents if you don't care how the sausage is authored

Every system that humans and AI build in together needs a layer both can write. The obvious candidate is Markdown, and Markdown is great at what it was built for — it's a blogging language. Prose goes in, prose comes out. But try to run a system on it: you can't validate Markdown, can't write a test suite for it, can't reliably parse a plan out of it. When an agent drifts — writes one file too many, contradicts itself across notes — Markdown has no way to even notice. The formats that can be validated, YAML and JSON, fail in the opposite direction: machines parse them fine, but nobody can think in them. There's no room for a paragraph of intent.

Workbooks use org — a plain-text format from the Emacs world with twenty years of history, sitting in the lineage of literate programming: the old idea that code should live inside the explanation of why it exists. Org reads like Markdown — headings, prose, lists — but underneath it's a parseable tree that natively understands tasks, states, dates, dependencies, and runnable blocks of code. You can validate it. You can test it. You can parse a project plan out of it without an AI in the loop.

And here's the practical kicker: those twenty years of documentation are in every model's training data. Agents don't have to be taught org — they arrived knowing it.

In a workbook, the org layer is where intent lives: the spec, the notes, the task states, the project's memory of itself. It's the layer that makes a workbook authored rather than just generated.

an agent can LIVE in here

depth rung · the advanced bit

Strip an agent's needs to the floor and the list is short: a file system to work in, processes to run, and a memory of what it's doing. That's the whole computer, as far as an agent is concerned.

Look back at the anatomy. A workbook has a file system (the SQLite virtual file system), processes (WebAssembly, any language), and memory with actual chronology (the org layer). Which means an agent doesn't need your operating system — your real files, your keychain, your environment variables. It can work entirely inside the file: read its data, run its code, write its notes, every bit of it sandboxed.

It's worth saying how unusual that is. The industry answer to "where do agents work?" is to rent isolation — a fresh micro virtual machine per agent, metered by the second, in someone's cloud. What's being recreated in each of those rented boxes is: a file system, some processes, a place for memory. The workbook carries that environment in the artifact itself — the workspace and the work product are the same object, and you can email it.

where a file alone falls sHort

Honesty section. A workbook on its own is still a file, and files have a hard limit: nothing happens while it's closed. It can't run a schedule overnight, can't keep an agent working after you walk away, can't serve itself to a thousand people, can't sync state between the copy on your laptop and the copy you sent.

That's not a flaw to apologize for — it's a boundary to know. The file is the artifact; for the living part you dock it into an engine you own. That engine is the Nexus, and it's what makes a workbook isolated, stateful, and agentic — without giving up the part where it's still just a file you can hand to anyone.