01
Named approvers
Which actions need a person, and which person, set per workspace rather than per prompt.
Plan 03 · the mechanics of a long run
Nothing here is a bigger model.
A model answers. A run survives. The difference is state that persists, a machine of its own, a checkpoint every time something is achieved, and a rule about when to stop and ask.
T+00:00The sequence
T+00:00:00
The brief is read and turned into a plan
Outcome, boundaries, systems of record, acceptance check. The plan is written down before any step runs, and it is the thing the run is measured against later.
T+00:00:11
A machine is provisioned
Filesystem, shell, browser, credentials scoped to the boundary you set. The run does not borrow your laptop and does not stop when you close it.
T+00:02:47
Connections are opened, read-only first
It reads the systems before it writes to any of them, and states what it found. Where two sources disagree it says so rather than picking one quietly.
T+00:14:03
Work begins, and is checkpointed as it goes
Every completed unit of work is persisted with the inputs that produced it. The run can be stopped at any point and resumed without repeating what it already did.
T+03:41:52
A step fails
An API times out, a page changes shape, a credential expires. The run retries from the last checkpoint, then tries a different route, then escalates. It does not lose the previous three hours.
T+06:20:09
Something risky comes up
A payment, an external email, a production write. The run pauses that branch, asks the named human, and keeps working on everything that does not depend on the answer.
T+31:00:00
It finishes, and hands over
The output, the acceptance check it ran against itself, the list of what it could not do, and the full log. A run you did not watch is still a run you can audit.
T+03:41:52The failure that matters
Long runs die
of small
failures.
Not of hard problems. Of a rate limit at hour nine, with no memory of hours one to eight. Persistence is the feature.
T+12:00:00The model underneath
Swap the engine,
keep the work.
The model is a setting, not the architecture. Frontier models from Anthropic, OpenAI and Google, or open-weight models you host yourself, and the change does not rewrite what you built on top. Different steps in one run can use different models, because a classification and a migration are not the same problem.
This is also the answer to the question everyone asks second: what happens when a better model ships next quarter. You point at it.
| Family | Runs where |
|---|---|
| Frontier, hosted | Provider API |
| Frontier, your key | Your account |
| Open weight | Your GPUs |
| Mixed, per step | Both |
On dedicated hardware the open-weight route is not metered by the token. You are paying for the machine, and the run is as long as it needs to be.
T+18:44:31Autonomy with a brake
02
Scoped credentials
The run holds the access you granted it and nothing adjacent. Read-only stays read-only.
03
A readable log
Every step, every input, every tool call, in order, kept after the run ends.
04
Your data stays yours
On the paid tiers you can keep your work out of model training, and in your own deployment it never leaves the boundary at all.