If you want a picture of the future, imagine a boot [strapping with] a human face—forever. (George Orwell, 1984)
Urbit is a new clean-slate system software stack. (Curtis Yarvin et al., “Urbit: A Solid-State Interpreter”)
Urbit's thesis is that personal computing should be a self-sovereign, persistent experience amenable to being reasoned about and intentionally used. Urbit's essential architecture consists of a persistent identity layer (a key into a 128-bit address space) and a deterministic ACID state machine based on the Nock ISA running on a virtual machine runtime. Atop the state machine, a variety of system services (“vanes” keyed into the runtime) and userspace apps (nominally “agents” but the term is overloaded and we here reserve that for LLM agents) provide useful capabilities for the end user.
But since Urbit's inception in the early 2010s, the landscape of computing has changed significantly. Besides the rise of containerization (prefigured by Urbit's virtualization and %aqua pattern) and cloud computing (working primarily on a remote instance), LLM agent-driven computing has become a significant vector and may soon become the dominant form factor of personal computing. You've heard of the dead Internet: what we want instead is a platform for the live player. Urbit's supporters have pointed out many of its desirable features for security and legibility 0 1, but more work can be done to facilitate a human-directed agent-driven personal computing paradigm. In particular, many aspects of Urbit build around human social patterns, e.g. paths and channels and marks as MIME types for content negotiation, rather than RPC and typed streams with versioned schemas.
F1. If it's not deterministic, it isn't real. (Urbit Precepts)
Urbit's core primitives (the Nock ISA plus a deterministic event log over a frozen state machine) are the right basis for agent-oriented reasoning patterns, very possibly the best one that exists. Every action is a pure transition; crashes replay; snapshotting, audit, and verifiable execution come along for free. These properties are solid gold for agents that need to be trusted to act on someone's behalf.
Indeed, agents have principals or the word is void. The human interface can shrink to near-zero; in fact, certainly much smaller than our shell-shocked cypherpunks have had to demand to date. But identity, attestation, and capability semantics (correctly) assume there is a human in the loop at some point guiding and owning the work.
Another often-neglected angle—because it is obvious to the Urbiter and illegible to the outsider—is that Nock execution is verifiable. Nockchain, for instance, leans into this. An agent OS in which any agent's trace can be cryptographically attested (prove what the agent did or didn't do) is offered by no other agent platform. Legible determinism is the moat, and the answer to the question of why not just run Python agents on Linux. Everyone else is swimming in the mud: Tlon's blue ocean beckons.
Nock's purity means that effects are declared, not performed. The Nock operating model enables, nay encourages atomic upgrades: the state is not a separate database entry from the code, but lives durably with the agent in the userspace harness.
A couple of other valuable features that fall out from the event log state machine model (altho not often used in practice today):
Every serious agent platform is sooner or later going to need deterministic replay, auditing, atomic upgrades, and crash recovery. In a parody of Greenspun's tenth rule, they are liable to do this by pasting Erlang-shaped fragments into Python-shaped runtimes, discovering a decade later that they've merely built an inferior Urbit.
(To be clear, this isn't free: replay-from-zero gets slow as the log grows, which is why snapshots exist. Determinism furthermore forbids agents from doing certain obvious things directly, such as reading the clock, calling rand, hitting an API: every such action becomes an effect, which is a good discipline but more verbose than equivalents. And of course the semantics of serial events means a slow agent can stall the ship.)
The Ames end-to-end messaging pattern and its deliver-once guarantees are likewise strong for agents. By pushing deduplication into the protocol and tying it to persistent identity, Ames handles many of the issues that plague distributed systems.
So far, Urbit comes in strong.
Clearly Urbit as an “operating function” brings much to the table. However, Urbit as it is today overfits to human interaction patterns in several regards. (It is, after all, “an operating system for the 90s”!) Other aspects can be rethought and better formed for an agent-driven workflow and API.
Azimuth assumes scarce, blockchain-rooted, human-owned identity. Agents need that sometimes, notably when acting accountably for a principal, but otherwise need cheap, ephemeral keys, attenuated sub-identities, and capability handoffs. (Moons gesture in this direction but have been underutilized and may be too heavy for ephemera.)
Ames thus needs to be augmented with ephemeral and attenuated identities, since agent sessions are typically lightweight and do not need persistence. (There is some question of what exactly-once delivery means across an ephemeral boundary, but it is not fundamentally alien to a PKI that permits breaches.) Groundwire's comet messaging scheme perhaps has some reasonable answers here.
Ames's transport semantics are correct but its identity semantics are too rigid for agents. One fix is to layer ocap on top with optional protocol-level support for ephemerals, while preserving the structural properties that make exactly-once actually work.
Urbit's system of paths, wires, and ducts is fundamentally oriented towards human programmer pattern recognition. Paths are hierarchical for human navigation, but for agents they are arbitrary tokens. Agents don't browse namespaces because they are typically told endpoints or using capability-based addressing. Likewise, agents are interested in userspace apps not by human labels or titles but by verifiable capability advertisement.
Gall subscriptions, for instance, are RSS-like: long-lived, persistent, fanout-from-publisher-to-subscribers, no built-in backpressure, and rebroadcast semantics for missed updates. This more like a blog or a chat channel. Inter-agent communications are more like RPC: request, response, deadline, completion. Streams are another common pattern: long-lived, ordered, with backpressure to slow down rather than drop messages. The pub/sub model should be a userspace facility built on streams rather than baked into the kernel.
Ducts are Urbit's solution to call stack spaghetti, but concurrent agent work wants to fan out. This calls for typed RPC with explicit response handles rather than duct stacks; every return path is a value in the program, more like futures or promises.
Routing in Urbit currently encodes the assumption that the principal actor is a human navigating a tree of resources via paths, with one causal chain per event, and HTTP serves as the (default) external transport. An agent-first redesign treats the principal actor as a program holding capabilities and managing many concurrent response handles, with the physical transport as a peripheral adapter. The structural change is from paths to capabilities, names to capabilities, ducts to explicit handles, and vane-level HTTP to userspace adapter, altogether leading to a dramatically smaller kernel surface.
Related to this, the instrumentation interface for Urbit has become scattered and multifarious in ways that undercut the Urbit thesis.
Driver proliferation has taken place because of one-off pain points with sedimentary solutions. Between Khan, Lick, Dill, and other drivers, the API is simply too complex. The aggregate is unjustifiable as a designed system, essentially five doors with unique key shapes all leading into the same building.
Single-threaded computing is solid but fragile in a particular way: Urbit can be DOSed accidentally with slow handlers or runaway effect cascades. Eyre is a visible symptom because HTTP has a low time-to-pain for the user, but it's simply the loudest customer. What we need here is a runtime-enforced computation budget, similar to the %jinx hint. (One possibility is a %fuel primitive for certain cause injections. %jinx is wall-clock and therefore non-deterministic across hardware, so it rolls back events; %fuel would be step-counted in some sense and preserve determinism.)
Related, Urbit doesn't have much in the way of an interrupt or out-of-band control channel. (Ctrl+C typically works but has occasionally been clobbered.) Most non-remote-scry interactions with a ship have to go through the same event queue that may be wedged. The runtime needs to surface a privileged control surface for diagnostics: state dumps, event log inspections, force-kills of events, dispatch pauses, forced snapshotting, replay from event number n.
What these point towards is a new system featuring a powerful runtime control surface with overrides; an agent RPC surface with capability addressing and streaming, which collapses transporters like Khan and Lick; and convenience tooling in userspace atop all of this, like the Urbit MCP server. (You could imagine this latter as a Dojo++.)
The cypherpunk dividend is that an explicit privileged control socket with a capability requirement affords better security than the current model. Preserve the capabilities but kill the separate surfaces, or a single API with adapters.
The Clay filesystem and code-building vane represents some of the oldest and most baroque code in Urbit. Clay consists of several (muscular and capable) goblins wearing one trenchcoat, but the trenchcoat was sized for a use case that mostly doesn't exist for agents. It bundles six different concerns:
For historical and architectural reasons, these have been bundled together, and it has even been proposed to unify the Gall agent model into Clay (Hume). There is a user story for it that works well: Clay validates incoming files via marks, Ford builds them, Gall hot-loads them, the app's own +on-load migrates the state, any failure rolls back the whole thing atomically. But for an agent, this is already frequently too much: an agent wants a capability-signed Nock noun that does a specific job for a specific principal, more like a pill or jam.
An agent-first refactoring of Clay could look like this:
We retain, in this model, atomic commits with rollback semantics. (Now, there are several possible paths forward that retain Clay: it could become primarily a source-building vane, or it could become a full-powered Git-style.) But the short critique is that today's Clay solves an outdated problem for agents at the wrong later. Like Ford Fusion, there is a much simpler obsidian shape lying underneath Clay's cooling lava.
Nock ISA's unpacking into jet-accelerated code has long been the Achilles of Urbit: a powerful unlock with a bedeviling flaw. Jet authorship and jet matching are both painstaking. Worse, the current %fast jet registration model is somewhat stateful, belying Nock's claims of purity. A model incorporating jet codesign, provability, and faster iteration will be better for (and enabled by) agents. Coherent contracts for noun–jet behavior will improve the situation as well.
Differential testing as a kernel feature should be table stakes. The current model is tests exist if/as the author wrote them, with per-jet ad-hoc assertions. What is needed is a development mode in which every jet call runs both the jet and the Nock formula, compares the products, and crashes loudly on divergence—expensive, paid only in development (but always in jet development), turned off in production. And revive %wild.
Regardless, jetting is less of a concern specifically for agents (vs. simply the efficiency story).
Ultimately, a world in which primitives become simpler and more legible—and more secure—over time is a world in which reasoning over those primitives compounds to become ever more powerful. (This was, as you may recall, one of the original fulcrums by which Unix lifted the earth.)
Urbit is a “personal server”, but the word “server” is semantic pollution, as is “service provider”. Urbit is better described as “agent substrate”, the field of play or laboratory from within which agent-driven processes command the world.
An Urbit specialized for the agent-driven computational universe has a kernel reduced to about ten verbs, vanes reworked into capability-bearing agents, typed RPC primitives, content-addressed noun storage, and runtime control sockets. That point lies closer to Mars than it does to any other operating system on the planet.