The runtime is a subsystem, not your laptop.

Open-ended work needs a real computer #

Company work doesn't fit neatly into a list of functions. Building software might mean installing a tool, poking around a repo, running a server, opening a browser, rendering something and keeping half-finished state across several attempts. Research might mix local documents, public sources, scripts and a final report. Building a custom API for every step turns the harness into the bottleneck.

Linux is a strong building block because models and human engineers already know how to use it. Files compose. Processes can outlive a single model call. Git can record meaningful checkpoints. Browsers show web work the way it really looks. Existing tools bring decades of behaviour without needing a new protocol for each task.

The important decision isn't "agents need shells". It's that the work in progress belongs to a company-level computer with a clear owner and lifecycle. The company computer is where the company produces things. It's not where permissions, the company's identity or what happened in the outside world get edited.

Your machine is the wrong blast radius #

Giving an agent direct access to your machine collapses a bunch of boundaries at once. A command can see unrelated repos, your personal files, sockets, credentials and processes unless each one is carefully hidden. An install can change the machine for every future task. A runaway build can eat your disk or memory. A cleanup command can hit a bigger folder than intended.

An attentive expert can manage those risks. It's hard to turn that into a product. A company computer gives you a smaller trust zone. It gets the repos, storage, tools and resources the company needs. It doesn't get the Docker socket, your host filesystem, cloud instance metadata or admin credentials for the host.

That doesn't give you perfect isolation between workers. The first version of Restless deliberately treats each company computer as one fairly open internal trust zone. The hard wall is between the company and the part that holds authority, not between every pair of workers inside. Stronger per-worker isolation can come when a real workload shows the security is worth the extra coordination.

Persistence has to be on purpose #

A throwaway sandbox is tempting because cleanup is easy: delete the container after each turn. But it's a rubbish workplace. Tools have to be reinstalled. Browser and build state vanish. Long-running processes die. Workers spend their time rebuilding the environment instead of moving the work forward.

Restless uses a persistent company computer. Repos, documents, installed tools, browser profiles, project services and ongoing experiments can survive across sessions and restarts. The company can keep working without pretending every task starts in a spotless new world.

Persistence comes with responsibility. The container's root filesystem isn't treated as the source of truth. Important work belongs on persistent storage or in repos. Temporary caches should stay disposable. A service that's meant to outlive a turn needs a proper supervisor setup. Otherwise it becomes a leak that quietly eats resources for days.

You can restore the computer. You can't rewind the company #

Snapshots make it possible to recover the workspace. A broken dependency upgrade or a destructive edit can be rolled back. But restoring the files doesn't unsend an email, reverse a payment or take back a promise to a customer. The outside world and the organisation's learning run on different clocks from the computer.

So Restless keeps the authority side and OrgIntel outside the writable computer. Restoring the computer keeps the current permissions, receipts, responsibilities and decisions. Before retrying anything uncertain, the system checks with the outside provider. It repairs forward rather than deleting newer truth to make the restored machine look consistent.

That's the real test of whether the computer is a proper subsystem. If restoring the work machine can rewrite the history of who was allowed to do what, the boundary is just decoration. If losing the computer destroys the organisation, the company was only ever a container.

A narrow bridge keeps things flexible #

OrgIntel needs to start work, hand over focused context, keep an eye on attempts and receive results or handoffs. It doesn't need to model every shell command. The bridge between them is just plumbing between the organisation's responsibilities and the Linux computer.

That keeps the actual work ordinary. Agents can use files, Git, browsers, package managers and the project's own tools without translating each operation into some universal command language. The bridge carries identity, which Work and Attempt this is, context and final results. The computer is free to be used as a computer.

Being narrow also makes the computer replaceable. Docker is how it's done today, not what the company computer is. A full system container or a virtual machine could replace it if desktop behaviour, persistent packages or whole-machine snapshots keep coming up. The organisation and authority side wouldn't need to change.

• OrgIntel sends responsibility and context, not shell commands for each step.
• The computer sends back results, evidence and the facts that matter at the end.
• Actions that need a credential happen where the credential lives, outside the company container.
• What the computer runs on can change without redefining the company or its work.

Resource limits are part of the product #

An autonomous company that can max out the shared machine isn't just inefficient. It can stop other companies from working and make unrelated failures look random. CPU, memory, number of processes, disk space, build cache and long-running services are all part of the deal.

We learned this the hard way. The first disk-full incident came from huge Rust build folders that could have been regenerated. A later one had a different cause: dozens of forgotten test companies, containers, volumes, Docker cache and one leaked long-running process. A disk-only check said everything was fine while CPU and swap were already maxed out.

The fix wasn't a universal cleanup daemon allowed to delete anything. We added exact resource limits, ownership rules, a reaper that only touches test companies explicitly marked as disposable, and checks that can tell busy from leaked. Real owner companies stay out of automatic deletion. Safety came from a precise lifecycle, not from broad permission to clean up.

Security gets more controllable, not magically solved #

A container isn't a complete security model. Workers inside one company computer can still affect shared files and processes. Network access can bring in untrusted content. Browser sessions can hold sensitive state. The underlying platform can still have vulnerabilities.

The win is control. The system can decide what goes into the environment, which host features are missing on purpose, which network or credential abilities go through a broker and how many resources the company can use. It can replace the computer while keeping authority and organisational truth. It can inspect and stop one company's processes without digging through your laptop.

At bigger scale, these become requirements. Hosting lots of companies shouldn't mean adding a company ID column to one shared, writable machine. Each company needs its own blast radius. Account-level credentials should stay where actions get carried out. Whatever manages the fleet of machines should manage their lifecycle without ever holding company secrets.

The trade-off is real infrastructure #

Making the computer a proper subsystem creates work. Images need building and upgrading. Storage needs ownership and a backup plan. Processes need supervising. Browser and desktop state need handling. Bridges can break. Local development has to avoid mixing up a developer's test computer with the stable one.

For a personal coding assistant, this might all be overkill. Direct access to your machine is more convenient with less infrastructure. The subsystem pays for itself when work has to survive sessions, companies need isolation, unattended processes matter, recovery has to be explainable, or the owner isn't an expert who can safely supervise an agent roaming around their machine.

Restless goes with the subsystem because the product isn't one agent helping one developer for one turn. It's a company that should keep working, stay controllable and bring back accountable results as workers, models, machines and hosting change.

The operating system is part of the organisation #

A company computer isn't passive infrastructure. It shapes what workers can see, which tools fit together naturally, how results are kept and whether work can be picked back up. Treating it as a first-class part of the system makes those choices visible.

The goal isn't to invent a new operating system for agents. It's to put a mature one behind the right boundaries. Linux supplies the way of working. Restless supplies company ownership, lifecycle, context, resource limits, keeping authority separate, and recovery.

It's heavier than opening a shell on a laptop. But once agents become ordinary workers rather than supervised demos, that weight buys something you really need: a real place to work that isn't thrown away every turn, and isn't the same machine as the person who owns it.