The Typewriter Moment for AI, Local LLMs, and the Protocol Stack
The history of transformative technology is not always a story of more power, more infrastructure, more complexity. Sometimes the transformative moment is the opposite — a simplification so radical it opens the technology to everyone, and in doing so, changes who gets to use it and what gets built.
The typewriter was not the most powerful writing machine of its era. The linotype could do more. But the typewriter required no factory, no operator guild, no specialized installation. It was portable, personal, and cheap enough to be owned. That shift — from institutional to individual — changed what got written, who wrote it, and ultimately what organizations could become.
Local Models like Gemma 4 are becoming the democratizing moment for AI.
Section 01
Capsules.Run makes a straightforward wager: there will be a world in which local frontier models — models capable of reasoning, calling tools, and executing skills — are powerful enough to run meaningful AI workflows without any SaaS or PaaS infrastructure underneath them.
No API subscriptions. No cloud dependency. No vendor in the middle.
A .capsule file dropped into a capable local model is a complete, self-contained unit of work. The model reads the capsule's handoff document, understands the participants, validates the event history, and continues the work from exactly where it was left off. The infrastructure is the protocol. The runtime is the model.
This is not a niche edge case. It is the floor of what the capsule format supports — and the floor is shockingly accessible.
Section 02
The dominant architecture of the last twenty years has been the SaaS stack: specialized applications, each owning their slice of the workflow, integrated through a proliferating web of APIs, webhooks, and authentication tokens. The complexity is real and the cost is real — not just financially, but cognitively. Every new tool is a new silo. Every integration is a new liability.
Capsules propose a different architecture. Not a platform. A protocol.
The analogy is the early internet. TCP/IP, SMTP, HTTP — these are not products. Nobody owns them. They are shared agreements about how things move. The applications built on top of them are enormously varied, but the underlying transport is common and open. What made the web powerful was not that one company built everything — it is that anyone who spoke the protocol could participate.
Capsules make a similar bet for AI work artifacts. The .capsule format is a portable container — a ZIP archive carrying content, a machine-readable state snapshot, and an append-only event ledger. Any model that can call tools or skills can open it, validate it, continue it, and hand it off. The format is the agreement. The model is the runtime. Nothing else is required.
Section 03
One of the more interesting properties of this architecture is how far the range extends in both directions.
At the low end, a capsule can travel as an email attachment. A .capsule file sent to a colleague is an artifact that carries its own history, context, and next steps. The recipient opens it with whatever capable model they have available — locally or otherwise. No shared platform, no login, no subscription required. This is, in a meaningful sense, pre-SaaS simplicity. It looks more like file exchange than software. And for many use cases, that is entirely sufficient.
At the high end, capsules compose into multi-party, multi-organization workflows with cryptographic provenance, encrypted state, MCP-native tool access, and execution rulesets that govern what each actor may and may not do. An enterprise deploying capsules at this level is not avoiding infrastructure — they are choosing a protocol-native architecture rather than a vendor-native one.
The same format, the same protocol, the same event ledger runs at both ends. Low maturity does not mean a broken version of high maturity. It means the protocol works without the infrastructure.
Section 04
While the low-tech thesis is compelling for individuals and small teams, the genuinely novel enterprise applications emerge at the intersection of the protocol and cross-organizational context transfer.
The limitation of current enterprise AI tooling is not compute. It is context. When work moves between organizations — a vendor and a client, a regulator and a regulated entity, a healthcare provider and an insurer — the context that makes that work meaningful is almost always lost in translation. It gets re-entered, re-explained, re-summarized. Every handoff is a loss function.
Capsules are designed to carry context across that boundary intact. The event ledger proves provenance. The state snapshot preserves the machine-readable context. The handoff document preserves the human-readable narrative. An AI actor on the receiving end can pick up the work with full fidelity to what came before.
Industries where this becomes interesting — and where clever teams are likely to find novel solutions — include anywhere that multi-party, high-stakes context transfer is the norm: compliance workflows, healthcare coordination, legal discovery, financial audit trails, supply chain documentation, investigative journalism.
These are not primarily AI problems. They are coordination problems. Capsules offer a protocol-native solution to a coordination problem that SaaS has not solved and is not well-positioned to solve.
Section 05
What the typewriter made possible was not just faster writing. It made possible the solo practitioner, the small office, the distributed organization. It decentralized the means of producing formal written work.
The local LLM running a capsule makes possible something structurally similar: the capable individual, the small team, the organization that cannot or will not build out an AI infrastructure stack, participating in the same AI-native workflows as the enterprises that can.
That decentralization is not the whole story of where capsules go. But it is the ground the protocol is built on. And it is worth naming clearly.
The infrastructure story of AI does not have to be centralized. The protocol can be open. The runtime can be local. The context can travel.