The file you end up holding — Learning Center

A whole working tool — its screen, its data, its history — as one file you can hold and hand to anyone, standing on an engine you own.

You just built something. Before we go further, let's name the thing you're actually holding — because it's smaller and more portable than almost anything else we call “an app,” and understanding what it is (and isn't) changes how you'll think about everything else.

Try, for a second, to email someone your software. Not a link to it — the actual thing, the way you'd send a photo or a song. For almost everything we call an app, you can't. There's nothing to attach. A modern app isn't a thing; it's an arrangement — code on one company's computers, a database in a data center, a dozen accounts, a web address pointing at all of it. Pull one piece out and it becomes a 404 page.

What you built is different. You can hold it. So let's look at what's in your hands.

the corE unit Is a woRkbook

The thing you walk away with is called a workbook, and it's the core unit of everything here. At first glance it looks like a web page — an .html file, the same humble format the entire internet is built from. That's deliberate. An HTML file opens on any phone, any laptop, any tablet made in the last twenty-five years, with no installation and no permission. We just usually ask it to be a page you read. A workbook asks it to be a thing that works.

But here's the first correction to make, because it's where most people get the mental model wrong: a workbook is not only a single HTML file. When it travels, it travels as a small bundle — and the bundle is the unit you actually own and send.

what's InsidE the bUndle

If you take a workbook that's ready to ship and crack it open, you'll find four pieces sitting together. They're four well-known standards, bound into one object:

workbook.html — the face. The screen you see and touch: the layout, the buttons, the HTML, CSS, and JavaScript. This is the part that renders the same on every browser on earth.
vfs.sqlite — the disk. A real SQLite database and a little virtual file system, riding inside the bundle. This is what the workbook remembers — your notes, your numbers, your save file, even images and binary files.
workbook.org — the why. A plain-text layer holding the intent, the tasks, and the memory — the part you and agents actually write and read. (There's a whole separate lesson on this layer; it's written in a grammar called org.)
manifest.json — one tiny line that says “this is a workbook bundle.” That's the whole trick. Something like {"format":"wbundle/1"}.

And the container? It's a plain zip. A .wbundle is just a zip file with a familiar extension — you can open it with the same unzip that's shipped on every computer for decades. No invented format, no proprietary archive. When a workbook is sent as a single .html file, those same parts are gzip-bound inside it; the bundle is just the same thing, unfolded so you can see the seams.

So the honest picture is: four standards — HTML, SQLite, org, and a one-line manifest — bound into one portable object. Not “one HTML file that magically contains everything.” A small, boring, openable bundle. The boring part is the point: boring formats don't stop opening when a company loses interest.

what you InheriT by beiNg a file

Because the thing you hold is genuinely a file, it quietly inherits everything we already know about files — and each of those is something other software spends enormous effort fighting.

You own it. It's on your computer, in your hands. No subscription revokes it; no company going out of business takes it away. The thing you have today is the thing you'll have in ten years.

You can send it to anyone. No “create an account to view.” If they can receive an email, they can have your software — with its data, exactly as you had it.

You can read the whole thing. The face, the disk, and the why are all right there, in formats you can open. For software that increasingly makes decisions for us, “you can see all of it” is not a small property.

It carries its own story — when you keep one. This is where we have to be careful, because it's easy to over-promise. The history of what was decided and why lives in the org layer — but only because something writes it there. It is not a magic undo that file-ness gives you for free. You (or an agent) record intent, tasks, and changes in the org layer; that's what makes the story travel inside the bundle. It's a discipline the format enables, not a guarantee the file performs on its own.

the part thE file can't Do alone: tHe runtime

Now the bigger correction, and the real reframe of this lesson. It is tempting to say “a workbook is self-contained, so there's no server.” That's the claim to retire. A single workbook can absolutely open and run on its own, in a browser, with nothing else — that part is true and lovely. But the moment you want the interesting things — an agent living inside it, doing real work, running other languages, scaling to many users — the workbook stands on a runtime.

The workbook is the core unit. The runtime is the ground it stands on. It's a single server (written almost entirely in Elixir, a language built for running enormous numbers of isolated things at once) that knows how to take a workbook and run it the way a Linux host runs a Docker image — but isolated, lighter, and the same on every platform. A workbook is both the artifact you deliver and the thing the runtime can pick up and run as its own little sandboxed world.

Think of it this way: the file is what you hold and hand to someone. The runtime is what gives it somewhere to come alive when you want more than a single person opening a single page. One is the unit; the other is the ecosystem it belongs to.

So “no server” was the over-claim. The truer statement is: the thing you own and send is a file; the heavy machinery hides behind a runtime instead of being scattered across a dozen companies. You still get ownership and portability of the unit. The runtime is one place, that you can run, rather than someone else's pile of services you rent and never see.

where thiS is today, And where It's going

Most of what's above ships today: the bundle is real, it's a plain zip, you can unzip it right now and see the four parts. Single workbooks open and run on their own. The runtime runs workbooks and hosts agents inside them.

The honest edges: a workbook is a file, and files are happiest shareable-sized — megabytes, not the entire archive of a streaming service. When a project needs a mountain of data or thousands of simultaneous users, it leans on the runtime for the heavy parts. And the more autonomous ideas — a system that watches itself run and edits its own configuration to improve — are real directions being built, not finished guarantees. We'll be clear, lesson by lesson, about which is which.

So that's the thing in your hands, named accurately. A workbook is the core unit of an ecosystem: a small bundle — HTML for the face, SQLite for the disk, org for the why, a one-line manifest to bind them, all zipped into one object you can hold, own, and send. It runs on its own when that's all you need, and stands on a runtime when you want it to do more. Hold that picture clearly and the rest of the Learning Center is just discovering what such a portable, legible little unit can become.