One Computing Environment, Many Machines

October 17, 2026

I want to start something on my phone, work on it from my laptop, leave a server doing the expensive part, and come back to it from wherever I am. I want an agent to help with the same work, using the same resources, without making its chat window the place where everything lives.

The work should still make sense when I change devices. It should still make sense when the agent changes, a process exits, or the interface I started in disappears.

That’s the computing environment I want to build toward with phux. Several machines, several interfaces, several people or agents able to participate. One environment I can understand and control.

Three foundations

I see three independent foundations that need to fit together.

The first is a resource fabric: the things we can use. Terminals, browsers, sandboxes, files, and services should be addressable across hosts. I should be able to find a resource, see where it lives, and use it from the interface that fits the moment. An agent should be able to do the same within its permissions. The machine still matters for latency, capabilities, cost, and trust. It shouldn’t force every interaction through a separate application and a separate mental model.

The second is durable work: the thing we’re doing. A computation, conversation, or collaboration needs an identity and history that outlast the worker currently advancing it. A browser may be temporary. A sandbox may be disposable. An agent may finish its part and leave. The work needs to retain its purpose, results, open questions, and enough context for someone else to continue.

The third is authority: who may observe, act, delegate, and take responsibility. Being able to see a terminal doesn’t imply permission to type into it. Using a browser doesn’t make an agent its owner. Delegating a task doesn’t grant access to everything I can access. Those distinctions need to remain clear as work and resources move between participants.

These foundations can develop independently. A remote terminal is useful without a durable task around it. A long-running collaboration can wait without holding a machine open. Permission to observe can exist without permission to advance the work. Their value grows when they agree about identities, ownership, and the boundaries of each action.

Humans and agents share the environment

Humans and agents should be native peers in this environment. Both need to discover resources, understand work, contribute results, and hand things off. They can use different interfaces while participating in the same system.

Peerhood doesn’t give everyone the same powers. A person may own the work. An agent may have a narrow grant to inspect a repository. Another may be allowed to change it. The system needs to preserve who asked, who acted, and who remains responsible.

Coordination belongs to the work being coordinated. I might direct a task myself, ask an agent to organize it, or use a workflow designed for that job. A personal assistant such as dot could participate and coordinate work within its authority. It would be one peer among others. The environment should keep working when I choose a different coordinator or no coordinator at all.

That also changes what an interface is. A phone can be good for checking a result or answering a question. A terminal can be good for precise control. A desktop can show several activities together. Each should give me a useful way into the work, with continuity across them.

Work has a longer life than a worker

Suppose an agent starts an investigation on a server. It opens a browser, collects evidence, and asks me to make a decision. I should be able to inspect that browser from my laptop, take control where needed, and return the resource to the agent. Later, another worker might continue the investigation in a fresh sandbox.

That handoff needs more than a transcript. The next participant needs to know what the resource is, what happened, what remains to be done, and what authority comes with taking over. A temporary resource can disappear while the investigation and its evidence remain.

Durability also needs honest limits. Keeping the work doesn’t keep every process alive. A failed worker may need replacing; an interrupted action may have an unknown outcome that needs checking. Continuing a task on another machine may mean starting a new execution with retained context. The system should make those transitions understandable.

Pi Durable is an interesting piece of this direction. Its experimental harness persists conversations and tasks so interrupted work can resume from storage within that runtime. That illustrates one part of durability. A shared environment also needs agreement across runtimes about work identity, resources, handoff, and authority.

Where phux fits

phux starts from a useful place: terminals that people and agents can share, with execution separated from the interface showing it. The direction is to grow that substrate into a wider environment and connect it to a common durable-work contract.

Different runtimes should retain their own execution models, scheduling, and conversation machinery. The shared contract should give participants enough common ground to find work, understand its state, contribute, and pass it on. It should leave room for different experiences and different coordinators.

This is a direction, with substantial work still ahead. Today’s phux has terminal federation and agent-session support; it doesn’t yet provide the whole cross-device resource and durable-work model described here. The living vision keeps the current direction alongside links to what exists and what remains proposed.

The goal is an environment where I can return to what I’m doing, bring in the people or agents I need, and use the right machine for each part without losing the thread or control of the work.