The runtime is a subsystem, not your laptop.

Open-ended work needs an operating environment

Company work does not fit neatly into a catalogue of functions. Building software may require installing a tool, inspecting a repository, running a server, opening a browser, rendering an artifact, and keeping intermediate state across several attempts. Research may combine local documents, public sources, scripts, and a final report. A bespoke API for each step turns the harness into the bottleneck.

A Linux environment is a strong primitive because models and human engineers already know how to use it. Files are composable. Processes can outlive one model call. Git can record meaningful checkpoints. Browsers expose the native surface of web work. Existing tools bring decades of behaviour without a new protocol for every task.

The important decision is not “agents need shells.” It is that productive state belongs to a company-level environment with an explicit owner and lifecycle. The Runtime is where the company creates economic output; it is not where authority, organisational identity, or external truth become mutable.

The host machine is the wrong blast radius

Direct host access collapses several boundaries. A command can see unrelated repositories, user files, sockets, credentials, and processes unless each is carefully hidden. An installation can alter the machine for future tasks. A runaway build can consume the owner's disk or memory. A cleanup instruction can target a broader directory than intended.

These risks are manageable for an attentive expert and difficult to productise. A company runtime provides a narrower trust domain. It receives the repositories, volumes, tools, and resources the company needs. It does not receive the Docker socket, host filesystem, cloud instance metadata, or host administrative credentials.

This does not provide perfect per-worker isolation. Restless V0 deliberately treats the company runtime as one permissive internal trust domain. The hard boundary is between the company and the Authority Plane, not between every pair of internal workers. Stronger per-actor isolation can be added when a real workload demonstrates that its security value repays the coordination cost.

Persistence must be deliberate

A disposable sandbox is attractive because cleanup is easy: destroy the container after each turn. It is poor at being a workplace. Tools must be reinstalled. Browser and build state disappear. Long-running processes die. Workers spend time reconstructing an environment instead of advancing the outcome.

Restless uses a persistent company computer. Repositories, documents, installed tools, browser profiles, project services, and active experiments can survive across sessions and restarts. The company can continue work without pretending every task begins from a pristine world.

Persistence creates responsibility. The container root filesystem is not treated as the ultimate durable source. Important work belongs on persistent volumes or in repositories. Temporary caches should remain disposable. A service intended to outlive a turn needs an explicit supervisor contract; otherwise it becomes a leak that silently consumes resources for days.

The runtime can be restored; the company cannot be rewound

Snapshots make productive recovery possible. A broken dependency upgrade or destructive local edit can be rolled back. But restoring the filesystem does not unsend an email, reverse a payment, or erase a promise already made to a customer. External history and organisational learning move on different clocks from runtime state.

Restless therefore keeps the Authority Plane and OrgIntel outside the writable runtime. A runtime restore preserves current grants, receipts, work responsibility, and accepted decisions. Before retrying an ambiguous effect, the system reconciles with the external provider. It repairs forward rather than deleting newer truth to make the restored machine appear consistent.

This separation is the test of whether runtime is truly a subsystem. If restoring the work machine can rewrite authority history, the boundary is cosmetic. If losing the runtime destroys the organisation, the company was only a container.

A narrow bridge preserves flexibility

OrgIntel needs to launch work, deliver focused context, observe attempts, and receive artifact or handoff facts. It does not need to model every shell command. The Runtime Bridge is transport and process plumbing between organisational responsibility and the Linux environment.

This keeps productive work ordinary. Agents can use files, Git, browsers, package managers, and project-native tools without exporting each operation into a universal command protocol. The bridge carries identity, Work and Attempt references, context, and terminal facts. The runtime remains free to use the operating system as an operating system.

The same narrowness aids replacement. Docker is one current implementation, not the definition of the company computer. A mutable system container or virtual machine could replace it if desktop behaviour, persistent packages, or whole-machine snapshots become recurring needs. The organisational and authority contracts need not change with the substrate.

• OrgIntel sends responsibility and context, not shell commands for every step.
• The runtime returns artifacts, evidence, and material terminal facts.
• Authority executes where the credential lives, outside the company container.
• The substrate may change without redefining company identity or work.

Resource control is product behaviour

An autonomous company that can exhaust the shared host is not merely inefficient. It can prevent other companies from working and make unrelated failures appear random. CPU, memory, process count, disk headroom, build cache, and long-lived services are part of the runtime contract.

Restless learned this through incidents. Disk exhaustion first came from enormous regenerable Rust build trees. A later incident had a different cause: dozens of orphaned test companies, containers, volumes, Docker cache, and a leaked long-running process. A disk-only check reported health while CPU and swap were already exhausted.

The response was not a universal cleanup daemon with permission to delete everything. Restless added exact resource bounds, ownership rules, a reaper limited to explicitly disposable test companies, and checks that distinguish busy resources from leaked ones. Persistent owner companies remain outside automated deletion. Safety came from a precise lifecycle, not broad cleanup authority.

Security becomes more controllable, not automatically solved

A container is not a complete security model. Workers inside one company runtime can still affect shared company files and processes. Network access can carry untrusted content. Browser sessions can hold sensitive state. Vulnerabilities in the substrate remain possible.

The benefit is controllability. The system can define what enters the environment, what host surfaces are absent, which network or credential capabilities are brokered, and what resources the company may consume. It can replace the runtime while preserving authority and organisational truth. It can inspect and stop one company's processes without searching the owner's laptop.

At larger scale, these properties become prerequisites. Multi-tenant deployment should not be built by adding company IDs to one shared writable machine. Each company needs a blast radius. Account-level credentials should remain where effects are executed. Fleet control should manage lifecycle without acquiring company secrets.

The trade-off is real operational machinery

Making runtime a subsystem creates work. Images must be built and upgraded. Volumes need ownership and backup policy. Processes need supervision. Browser and desktop state need handling. Bridges can fail. Local development must avoid confusing a developer's runtime with the stable appliance.

For a personal coding assistant, this may be unnecessary. Direct host access can deliver more convenience with less infrastructure. The subsystem pays for itself when work must survive sessions, companies need isolation, unattended processes matter, recovery must be explainable, or non-expert owners cannot safely supervise ambient machine access.

Restless chooses the subsystem because its product is not one agent helping one developer for one turn. It is a company that should keep working, remain controllable, and return accountable results as workers, models, machines, and deployment environments change.

The operating system is part of the organisation

A company computer is not passive infrastructure. It shapes what workers can observe, which tools compose naturally, how artifacts persist, and whether work can be resumed. Treating it as a first-class subsystem makes those choices visible.

The goal is not to invent a new operating system for agents. It is to put a mature one behind the right boundaries. Linux supplies the productive grammar. Restless supplies company ownership, lifecycle, context, resource limits, authority separation, and recovery.

That architecture is heavier than opening a shell on a laptop. At the point where agents become ordinary economic actors rather than supervised demonstrations, the weight buys something essential: a real place to work that is neither disposable on every turn nor indistinguishable from the machine of the person who owns it.