4.9 Isn't the missing permanent machine a gap?
- Approved by
- Panaversity ·
By now a fair question has formed. Chapter 1 showed that a delegated task in Claude keeps no machine. Every run gets a fresh sandbox,1 and between a routine's runs there is no machine at all.2 A human worker has a desk that stays. Surely an AI Worker needs one too?
In everyday life. A hospital runs on twelve-hour shifts. The nurse who cared for a patient this morning goes home, and a different nurse takes over tonight. Care continues anyway, not because any nurse stays, but because the chart stays. Every observation, every dose, every decision is in the record, and the next nurse starts from it. A hospital where continuity lived in one nurse's head would not be safer. It would be one sick day away from losing the patient's history.

Figure 4.6. The chart stays.
That is the design choice behind the disposable sandbox. The worker was never the machine. The worker is its records, tied together by the Role Contract (4.1). Look at the picture again: no standing computer appears in it, because everything a permanent machine would keep already has a home the company governs.
- What the worker knows lives in the KSoR.
- What has happened so far, every run, every decision, every handoff, lives in the SSoR, in each matter's case file.
- What it may change, and what it has changed, lives in the DSoR.
- What wakes it is not a machine idling overnight. It is a trigger: when a job is due, it starts a fresh machine, which reads the pending work from the case files (Chapter 9).
A fresh run reads them in a fixed order: the Role Contract, then the pending work from the case files, then the record for each question the work raises.
A worker built this way can be audited, because every run's inputs, steps and evidence are in its records. It can be handed to a new owner, improved or replaced, because nothing about it is trapped in one machine's state. And it is harder to attack, because nothing worth stealing lives on a machine nobody governs.

Figure 4.7. A worker is its records, not its machine. If the machine were destroyed tonight, what would be lost?
A standing machine, by contrast, is where state goes to become ungoverned. Files pile up on it. Context exists only inside it. When it drifts or dies, the worker's history drifts or dies with it. That is the quiet risk in Chapter 1's standing workers: a dot,3 Duet4 or OpenClaw.5 The risk is not that the machine persists, but that whatever lives only on it answers to nobody's records. The same question applies to any harness that keeps a session's files and history on the server between interactions, whichever AI vendor runs it (4.8).
Be honest about the price, though, because there is one. A fresh machine must rebuild its working context from the records every run, reading what the run needs and not the whole record, which costs tokens and startup time. That bill is why Chapter 34 exists. No worker is running between runs. The inbox fills and the scheduler counts, so the worker reacts only as fast as its triggers fire, which is why the Role Contract states a tolerance (4.8). And a job longer than one session must save its progress to the records and resume, which has to be designed. Part III shows how. These are real engineering costs. They are the price of a worker whose memory answers to governance instead of to a hard drive. This book's position is that for a Digital FTE, with a named owner and real authority, that price is the bargain of the century.
Check yourself
Question 1 / 8
0 answered
Why does the architecture picture show no standing computer?
Sources
- Owner
- Panaversity