The Process
Is Not the Work

There is something peculiar about the history of computing. Ideas rarely disappear because they have been conclusively disproved. More often, they disappear because another arrangement becomes sufficiently successful that the original questions cease to be asked.

The success of Unix is one example. The personal computer is another. The container, perhaps, is a third.

None of these technologies was inevitable. Each emerged from a particular understanding of what a computer was, who would operate it, and what sort of work it was expected to perform.

Once successful, those assumptions became increasingly difficult to see.

Today, an enormous amount of infrastructure is organized around processes, containers, virtual machines, and services. There are good reasons for this. They are remarkably effective ways of organizing computation.

Yet the arrival of autonomous software has begun to expose an interesting distinction.

A process is something that executes.

Work is something that must be accomplished.

For most of computing’s history, the distinction was easy enough to ignore, or at least to leave to the application.

It is becoming considerably harder to ignore now.

01. The container was never the beginning

The container is often presented as a natural stage in the evolution of computing. First came physical machines, then virtual machines, then containers, followed by orchestration.

It makes for a convenient history, although a rather misleading one.

The desire to separate a program from the physical machine on which it executes is much older than Docker. So is the desire to isolate programs from one another.

Unix introduced a particularly successful collection of abstractions for organizing processes and their relationships to resources. Virtualization developed along several different paths. Unix-like systems experimented with chroot, resource controls, jails, zones, namespaces, and different forms of process isolation.

These approaches were not simply steps toward the same destination.

They expressed different ideas about what ought to be separated from what.

A virtual machine constructs an environment in which an operating system can run. A container generally shares the host kernel while restricting the resources and namespaces visible to a collection of processes.

The distinction is important, but neither abstraction explains the purpose of the computation taking place inside it.

A container can tell something about the environment in which an operation occurred. It may provide useful evidence about which processes ran and which resources were available.

It does not necessarily explain why those processes existed, who authorized their actions, or whether the work they were performing has been completed.

Historically, these questions belonged elsewhere.

An application maintained its own state. A workflow system managed its tasks. An operator made decisions. Credentials supplied access to external systems.

The operating environment remained largely concerned with execution.

That division of responsibility was not unreasonable.

The question is whether it remains sufficient.

02. A sandbox has a door

Consider a software agent running in an isolated environment.

The isolation might be excellent. A dedicated virtual machine, a carefully restricted container, a hardened runtime, perhaps even hardware-assisted separation.

Then the agent is asked to do something useful.

It needs a repository, a compiler, documentation, network access, a database, and eventually access to some external service.

Perhaps the task involves deploying an application or investigating a production incident.

At this point, the agent must interact with the world outside its isolated environment.

There is no contradiction here. A sandbox is supposed to establish a boundary, not abolish all interaction with the outside world.

But the boundary creates an interesting problem.

An agent with permission to call a production API may perform a perfectly valid API request that produces a disastrous result.

The kernel might see nothing suspicious. The network policy might permit the connection. The authentication system might accept the credential.

Every technical boundary can behave exactly as designed.

And the operation can still be wrong.

This is not a failure of isolation. It is a category mistake to expect isolation to establish the legitimacy of an action merely because it can restrict the mechanisms through which the action is performed.

There is a difference between asking whether software may access a resource and asking whether a particular piece of work is authorized to produce a particular effect.

The former is familiar territory.

The latter becomes difficult when the work is carried out by autonomous software whose next action is not necessarily known in advance.

A sandbox has a door.

The interesting problems begin when something walks through it.

03. The old question of location

Long before the current enthusiasm for autonomous agents, computer scientists were already questioning another assumption: why should the place where a program executes determine the resources available to it?

Plan 9, developed at Bell Labs beginning in the late 1980s, approached the problem through namespaces.

A process could receive a particular view of resources, assembled from services that might exist on different machines.

The machine itself was no longer necessarily the natural boundary of the program’s environment.

Plan 9’s cpu command is especially interesting in this regard. Computation could take place on a remote CPU server while the user continued interacting through a familiar terminal environment.

The distinction between the place of interaction and the place of execution was deliberate.

MOSIX came from a different tradition.

Emerging from work on distributed operating systems in the 1970s and developed over subsequent decades, MOSIX explored process migration and resource sharing across machines.

Where Plan 9 reconsidered the organization of resources, MOSIX questioned the relationship between a running process and its physical location.

Both projects belonged to a period when the relationship between computers and networks remained unusually open to experimentation.

Neither became the dominant operating environment.

That fact alone says little about the value of their ideas.

The history of technology is full of successful implementations that narrowed the range of questions considered worth asking.

The distributed systems of today have inherited some of these ideas, abandoned others, and often reproduced their problems in different forms.

An agent running on a remote cluster while interacting with resources associated with a developer’s laptop is not an entirely new proposition.

It is an old problem appearing under different conditions.

But there is now an additional complication.

The thing that needs to move may no longer be a process.

04. What survives the process?

Suppose an agent is asked to perform a database migration.

It examines a schema, generates a migration, executes tests, and receives approval to apply the change.

The migration is submitted.

Then the process crashes.

Restarting the process is straightforward. So is starting another container, or restoring a virtual machine from a snapshot.

None of these actions answers the interesting question.

Did the database migration happen?

The request may have reached its destination. The database may have committed the change. Only the response may have disappeared.

Repeating the operation could produce another failure.

Restoring the process environment would not restore the database.

This is an old distributed-systems problem. Uncertain outcomes, retries, idempotency, and recovery have occupied computer science for decades. Durable workflow engines have developed serious machinery to address them.

Autonomous agents do not make these problems new.

They make them more visible, and introduce a different relationship between the executing program and the authority to act.

Imagine that the original agent is replaced by another model.

Perhaps that model runs on a different machine, uses a different execution environment, or belongs to a different provider.

Should it inherit the original agent’s credentials?

Should it be allowed to repeat the previous action?

How does it establish which parts of the work are complete?

And why should the ability to continue a task depend on possession of the original process state?

The process has disappeared.

The work has not.

05. The strange possibility of an Operation

This is where the idea of an Operation becomes interesting.

An Operation is not simply another name for a process, container, or workflow.

It is an attempt to represent work independently of the particular software performing it.

A process may execute part of an Operation. Another process may continue it. Several workers may perform separate parts of it.

The Operation retains an identity that does not disappear with any individual worker.

But continuity alone is insufficient.

A durable record of execution is useful, although not particularly novel. Event logs, checkpointing, and workflow histories already provide versions of that capability.

The more difficult question concerns authority.

The distinction is not that workflow engines cannot model authority. It is that authority and custody become explicit parts of the work’s runtime contract.

If the work continues, what happens to the permission to act on its behalf?

There is a peculiar habit in software systems of treating authority as something possessed by a process, account, token, or service identity.

That works reasonably well when the relationship between the software and its purpose is stable.

An autonomous agent complicates the arrangement.

Its process may have a broad collection of abilities, while the particular task requires only a very small subset.

A task involving one Kubernetes Deployment does not imply authority over the entire cluster.

A database migration does not imply permission to delete arbitrary tables.

And replacing the agent performing the task should not automatically create a new source of authority.

One possible answer is to attach bounded authority to the Operation and require a worker to establish custody before acting on its behalf.

Custody is distinct from merely knowing an identifier.

It must be proven.

When custody changes, the old worker must be prevented from committing new state at the runtime boundary. Credentials or short-lived proofs already issued to external systems have their own validity and enforcement rules; custody changes are not instant revocation everywhere. Delegated authority may become narrower, but should not silently become broader.

The resulting system begins to look rather different from a conventional execution environment.

It is concerned not merely with whether a process is running, but with whether that process is currently entitled to continue a particular piece of work.

06. The problem with remembering

There is another difficulty here.

Computer systems are exceptionally good at recording events. They are considerably less reliable at explaining what those events establish.

A log entry might say that an HTTP request was issued.

That does not prove the destination applied the requested change.

A process might report success.

That does not establish that the external system reached its intended state.

A signed record can establish something about the integrity and provenance of recorded information.

It does not transform an inaccurate observation into truth.

These distinctions become important when autonomous software begins making operational changes.

The record of what an agent intended, what it attempted, what was observed, and what can be verified should not be collapsed into one convenient narrative.

There may be gaps.

Some events may be inferred.

Some outcomes may remain unknown.

And sometimes the correct behavior is not to retry, but to wait until the uncertainty can be resolved.

This is one of the less glamorous aspects of durable execution.

It is also one of the most important.

The desire for a clean story about what happened is understandable.

Distributed systems are under no obligation to provide one.

07. Back to the computer on the desk

It is worth returning to something more ordinary.

A developer sits at a laptop and starts an agent.

The task requires a large build, several tests, and substantial computational resources.

Why should those resources have to live on the laptop?

A remote cluster may have more CPU, more memory, better caches, and access to the relevant infrastructure.

Yet remote development often requires the user to manage an entirely different environment.

Files must be transferred. Sessions must be maintained. State must be reconstructed. Credentials must be arranged. Results must somehow return.

The physical location of computation begins to dominate the experience of doing the work.

Plan 9 offered a different way of thinking about this relationship.

The environment presented to a process could be composed from resources distributed across machines.

MOSIX, in another way, explored the independence of execution from location.

A contemporary implementation need not reproduce either system.

Nor does it need to pretend that a remote filesystem is as fast as a local disk, or that a Linux process can transparently become a macOS process.

It may use snapshots, content-addressed artifacts, cached dependencies, remote execution hosts, and explicitly shared services.

The important quality is the continuity of the working environment.

The developer interacts with the Operation.

The computation takes place wherever suitable resources are available.

A disconnected laptop does not necessarily terminate the work.

A failed worker does not necessarily destroy its committed results.

And the location of execution does not become the source of authority.

What appears local to the person using the system may be distributed underneath.

That was already an interesting idea forty years ago.

It has become more interesting now.

08. An operating system for work?

There is an obvious danger in taking this argument too far.

Once a missing abstraction has been identified, the temptation is to declare the need for a new operating system.

That would be premature.

Linux is remarkably good at managing processes, memory, filesystems, scheduling, and access to hardware.

Virtual machines provide valuable isolation.

Containers provide useful packaging and execution boundaries.

Kubernetes offers a sophisticated model for operating workloads across machines.

None of these needs to disappear.

There is also no reason to rebuild every existing mechanism merely to accommodate a new conceptual model.

The more interesting possibility is a layer that uses these systems while giving work a separate identity and lifecycle.

A runtime that understands custody, bounded authority, durable state, and external effects.

An environment in which execution may be local or remote without changing the meaning of the work.

And a record that remains useful after the particular agent responsible for an action has disappeared.

This is part of the thinking behind Habitat, an experimental runtime under development at False Systems.

The implemented foundations include custody, generations, narrowing grants, durable journaling, retained results, and supported mediated HTTP effects.

The wider ambition, including the connected remote execution experience, richer resource namespaces, credential brokerage, and continuity across hosts, remains an engineering problem rather than a finished system.

There is no reason to hide that distinction.

A working prototype is not a new operating system.

And an interesting abstraction is not yet a successful product.

09. The missing abstraction

The history of computing is not a sequence of obsolete ideas replaced by superior ones.

It is a history of changing problems, shifting assumptions, and abstractions that remain useful long after their original circumstances have disappeared.

The process was an extraordinarily productive abstraction.

So was the virtual machine.

So was the container.

Autonomous software does not invalidate them.

It exposes something that none of them was primarily designed to represent.

The continuity of work across changing executors, machines, identities, and external systems.

The difficulty is not simply keeping an agent alive.

It is establishing what remains legitimate and true when the agent is gone.

Who may continue?

What authority remains?

Which actions have already occurred?

What can be recovered?

What is still unknown?

These are questions that increasingly belong to the infrastructure rather than to the individual agent.

Perhaps the process should continue to be the unit of execution.

Perhaps the Operation should become the unit of continuity and responsibility.

The distinction may turn out to be more useful than building another wall around a process.

After all, a container can be restarted, a virtual machine can be replaced, and a sandbox can be destroyed.

The work is not necessarily finished just because the machine has stopped.