Leaving the Laptop: A Runtime Crash Course
12 Concepts · From a loop that dies when the lid closes to a worker with a home of its own
Your system is finished, and it is trapped. The loop from three courses ago runs every morning at 9am. The harness blocks the dangerous actions. The eval suite gives the reviewer a number you can defend. You did everything right, and all of it stops the moment you close your laptop, lose your Wi-Fi, or board a flight. The most reliable worker you have ever built has one single point of failure left, and it is the machine on your desk.
This course answers the section's last open question: the runtime decision. Not what the agent does (three courses settled that) but where it lives and who keeps it alive: the place and the caretaker, not the behavior. That question sounds like an infrastructure detail. It is not. It is the question that decides whether you are an operator with a very good tool, or the owner of a worker that shows up whether or not you do. It is also the exact question you will answer again, at company scale, the day you build your first Digital FTE. Learn it here, at a size where you can see all the parts.
One promise before we start. This course does not turn you into a DevOps engineer. Every move it teaches uses things you already own: the config files from the agentic coding course, the headless commands from the evals course, the schedules from the loop course, and the suite that proves the move worked. The one genuinely new thing — a runtime someone else operates for you — is introduced honestly, with its price tag and its trade-offs in plain view.
You need this first: Trusting the Checker. That course gave you the eval suite, and this course depends on it heavily: a move to a new runtime is exactly the kind of change that must re-run the suite before it is trusted. It assumes the whole Stage 3 trilogy: Loop Engineering (beats, the spine, the human gate), Harness Engineering (the five verbs, the ratchet), and the evals course (the golden set, baselines, drift). If those words are new, do those courses first. This course moves the machinery they built.
New here? A 2-minute recap of what you should already know
- A beat: one full run of a scheduled loop. The morning-triage loop runs one beat per weekday.
- The harness: the layer that decides what the agent may do, what it must know, how its work is proven, and what happens when it goes wrong.
- The golden set: your folder of eval cases, built from real caught failures, re-run on every change.
- The baseline: the recorded pass rate you compare new runs against. A drop from baseline is the alarm.
- Drift: behavior changing with no change from you, usually because the model underneath was updated.
- The human gate: risky or failed work goes to a person. Nothing unattended reaches
main. - Headless mode: running the agent without an interactive session (
claude -pin Claude Code,opencode runin OpenCode) so a script or a schedule can drive it.
If any of these are new, read the three Stage 3 courses first. This course relocates the machinery those courses built and proved.
Key words in plain English
| Term | Plain-English meaning |
|---|---|
| Runtime | The computer, and the software around your agent, that actually executes it: starts it, feeds it, restarts it when it crashes. |
| Home | This course's word for a runtime choice: your session, a cloud schedule, a managed runtime, or your own process. |
| Control plane | The half of the runtime that operates the agent loop: sessions, scheduling, event streams, restarts. |
| Execution plane | The half where the work lands: the sandbox the tools run in, and the data they touch. The two planes can have different owners. |
| Custody | Who holds and controls the data: on whose machines it lives, and who can reach it. |
| Headless | Running the agent from a command, with no interactive session. The bridge every move crosses. |
| Schedule | Something that starts your loop at a set time without you: a Claude Code Routine, a Cowork Scheduled Task, or a scheduled GitHub Actions job. |
| Managed runtime | A service where you send the agent's definition and the vendor operates the control plane — and, by default but not necessarily, the sandbox too. |
| Agent definition | Everything that describes your agent without running it: the model, the system prompt, the tools, the rules, the guardrails. |
| Session (hosted) | One ongoing piece of work inside a managed runtime, with its own preserved state and event log. |
| Sandbox | The walled-off environment where the agent's actions actually execute. In some homes it sits next to the model; in others, apart from it. |
| Portability | How much of your system survives a move to a different home without being rebuilt. |
| Lock-in | The cost of leaving a home, measured in everything you would have to rebuild. Low portability is high lock-in. |
| Blast radius | What a bad night in a given home can reach. The harness course's budgeting question, asked about runtimes. |
| Pager | The alarm that wakes an engineer when a system breaks at night. "Carrying the pager" means being the person responsible for that. |
| Re-baseline | Recording a runtime-specific pass rate after the new home passes the existing acceptance bars, with the old baseline preserved for comparison and history. |
| Probation | A trial period: the new home is watched closely, with the old home still available, before it is fully trusted. |
Where this came from
For most of the industry's history, "deployment" was a developer's word: you wrote code, then you shipped it to servers. What changed in 2025 and 2026 is that operators (people who never wrote the agent, only configured and proved it) suddenly had something worth deploying. A configured loop with a measured track record is an asset, and an asset that only exists while your laptop is open is an asset badly stored. The vendors noticed. Anthropic shipped cloud execution for its consumer tools, then a hosted runtime for agent definitions; the open-source side standardized on CI schedulers as the low-cost alternative. The result is that the runtime decision — once a question only engineers faced, at the end of a project — now arrives much earlier, and reaches people who will never write a server. This course is for them. (Sources at the end.)
The mindset shift, in one picture
This course teaches two tools together, as the whole trilogy did. The judgment (which home, when to move, how to prove the move) is identical in both. The mechanics differ more here than in any earlier course, and the course is honest about why: one tool's vendor operates a cloud for it, and the other tool's "vendor" is you. That asymmetry is not a footnote. It is one of the things the runtime decision is about.
True in mid-July 2026. Everything in this course's mechanical layer (product names, endpoints, prices, flags) changes faster than any other course in this section. Before any move, run claude update or opencode upgrade, and check the live docs (code.claude.com/docs, docs.claude.com, opencode.ai/docs) before you trust a name or a number.
What this course covers
| Part | Topic | What you learn |
|---|---|---|
| 1 | The last dependency | Why a proven loop on a laptop is an asset badly stored, and the one question that sorts every option |
| 2 | Headless is the bridge | The invocation every home shares, and the first move: the cloud schedule |
| 3 | The managed runtime | Agent definitions, environments, and sessions: what you hand over, what you get back, what it costs |
| 4 | The move itself | What travels, what gets rebuilt, and why the track record must be re-earned in the new home |
| 5 | Choosing a home | The four questions, mixing homes on purpose, and one full move end to end |
| 6 | Staying honest | Lock-in, the ownership drift, what no home can fix, and the bridge to Mode 2 |
| Live | Dogfooding | Where this book's own loops live, and why |
| Practice | Projects | Eight moves, easy to hard |
Want to learn by doing? Read Part 5 first to watch one complete move. Then come back for the parts. First time? Parts 1–5 in order, skipping every note marked "Going deeper." That reading is about ninety minutes. Then do Projects 1–3, which take longer. After them, your loop runs on a schedule that does not need your laptop, and you can say — with a number — that it still works. Second read (after your first month of unattended nights): all of Part 6, the deeper notes, and Projects 4–8. Lock-in only makes full sense once you have something you would mind rebuilding. Reading in English as a second language? Every picture-word in this course has a plain version nearby. The "In simple terms" boxes and the glossary above carry the same meaning in short, literal sentences. If a sentence feels decorative, the box near it says the same thing simply. Two layers, aging differently. Remember the first. Look up the second.Two ways to read this course
What to remember, and what to look up
📚 Teaching Aid
View Full Presentation — Leaving the Laptop: A Runtime Crash Course
Part 1: The Last Dependency
1. A proven loop on a laptop is an asset badly stored
Count what you have built across three courses. A loop that triages the morning queue before you sit down. A harness that makes the dangerous mistakes impossible and turns every caught failure into a permanent rule. An eval suite that gives the reviewer at the center a defended number. Roughly speaking: a junior colleague, with a written job description, a supervisor, and a performance record.
Now count what it depends on. Your laptop being open. Your session being logged in. Your machine being awake at 9am, on power, on network. Miss any one, and the beat silently does not run — and the loop course taught you what a silently skipped beat costs: the queue grows, the escalations pile up, and Monday's you pays for Friday's closed lid.
There is a sharper way to say this. The trilogy taught you to remove single points of failure one by one: the maker–checker split removed the single unreviewed opinion; the harness removed the single unguarded action; the evals removed the single unchecked checker. One remains, and it is you — not your judgment, which the human gate rightly keeps, but your hardware. The system is more reliable than the machine it runs on. That is the signal that it has outgrown its home.
You trained a good worker and then required them to work only in your living room, only while you are home. The worker is fine. The arrangement is the problem.
2. One question sorts every option: who operates the loop, and where does the work execute?
The moment you look for a new home, the options multiply and the vocabulary gets loud: cloud sessions, hosted agents, managed runtimes, SDKs, serverless this, orchestrated that. Cut through all of it with one question. Notice it has two halves: who operates the agent loop, and where does its work execute?
The two halves have names worth learning now, because modern runtimes can split them. The control plane is the loop itself: the thing that starts sessions, feeds the model, streams the events, restarts what crashes at 3am. The execution plane is where the actions land: the sandbox the tools run in, and the data they touch. On your laptop the two planes are one machine, so you never had to tell them apart. The homes ahead can separate them — and the most interesting home separates them on purpose.
Every option is one of four homes, sorted by those two halves, and the picture above showed them:
- Home 1: your session. You own everything: the config, the runtime, the uptime. This is where the trilogy happened, and it remains the right home for building and proving. It is the wrong home for depending on.
- Home 2: the cloud schedule. You still own the config — the same rules file, skills, and subagents — but the clock moves to someone else's computer. A Routine in Claude Code runs your loop on Anthropic's cloud. A scheduled GitHub Actions job runs your OpenCode loop on GitHub's runners. It is the smallest move, with the biggest immediate payoff.
- Home 3: the managed runtime. You hand over the agent's definition (model, prompt, tools, guardrails) and a vendor's service operates the control plane: the loop, the sessions, the crash recovery. The execution plane is a choice: the vendor's cloud sandbox by default, or — where custody demands it — a sandbox on infrastructure you control. You stop operating the loop. You keep operating the business around it.
- Home 4: your own process. The harness becomes a library inside software you write and servers you run. You own all of it, and you carry all of the responsibility. This is the Agent SDK, and it is Mode 2's territory: this course shows you the door and does not walk through it.
The two-plane split, laid flat. Five rows, because home 3 is really two:
| Home | Control plane | Execution plane | Who is woken when it breaks |
|---|---|---|---|
| 1 · Your session | You | Your laptop | Yours |
| 2 · Cloud schedule | You, via a scheduler | A cloud runner | Shared |
| 3 · Managed, cloud sandbox | Vendor | Vendor | Infrastructure theirs; outcomes yours |
| 3 · Managed, self-hosted sandbox | Vendor | You | Split by plane |
| 4 · Your own process | You | You | Yours, on purpose |
Notice what the question is really about. It is not technical. It is the same question every business asks about every function: do we do this ourselves, or pay someone to do it? You already know how to think about that. The rest of this course is just that thinking, applied to the computer under your agent.
Four homes to choose between, not a ladder to climb: your laptop (own everything), a schedule (own the config), a managed runtime (own the definition; the sandbox sits on their cloud, or on yours where custody demands it), or your own servers (own it all again on purpose, at product scale). The rule this course keeps coming back to: own only what you must, not what you want. Most readers stay in the first three, and you will often run several at once, one per loop; the fourth home is where Mode 2 begins.
Ayesha in Lahore runs her freelance-invoicing loop from her own laptop. Load-shedding cuts her power most evenings, and she just landed a client who expects invoices to go out at 6pm her time, daily, without fail. Which home does she need first, and why is home 3 more than she needs today? Home 2, the cloud schedule. Her problem is exactly and only the clock: the loop is proven, the config works, but the machine it runs on cannot promise 6pm. Moving the schedule to a cloud runner removes the power cut from the critical path while changing nothing she would have to re-prove except the new home itself. One honesty note her client's words demand: most schedulers, including CI schedules, promise around a time, not at it. Under load they delay, and occasionally drop, a scheduled run. So "without fail" is not a scheduler feature; it is a kit (Part 2's minimum unattended kit): a missed-run detector, a retry that cannot send the same invoice twice, and an alarm when no successful run is recorded by 6:30. Home 3 solves problems she does not yet have — serving other users, session persistence across long jobs, operating at scale — and charges for them. The four questions in Part 5 will make this an explicit test: who is the user? Today, the user is Ayesha. Home 2, plus the kit, is enough.Show answer
Part 2: Headless Is the Bridge
3. Every home speaks headless
Here is the quiet fact that makes every move in this course possible: you already crossed the bridge, in the evals course, without being told it was a bridge. The eval runner called claude -p and opencode run — the agent as a command, not a conversation. No open window, no session to babysit: a prompt goes in, work happens, output comes out, the process ends.
That is headless mode, and it is the idea this entire course stands on. Anything that can run a command can now run your agent. A shell script can. A cron job can. A CI runner can. A cloud scheduler can. Every home from 2 onward is, underneath, just a different answer to "whose computer runs the headless command, and on whose clock."
The mechanics you already know from the evals course carry over unchanged: --output-format json for machine-readable output on the Claude Code side; the JSON event stream on the OpenCode side; the reviewer writing its verdict to a file so no one parses prose. One habit to add now that no human is watching: headless runs must fail loudly. In a session, you see the error. On a runner, an exit code nobody checks is a beat that silently did not happen, the exact failure Concept 1 warned about, rebuilt in the cloud. Every headless wrapper in this course checks the exit code and gets loud (raises a loud, visible alarm; the loop course's fifth verb) on failure. Silence must mean success, and that is a rule you enforce, not a default you inherit.
Interactive mode is you talking to the agent. Headless mode is anyone (a script, a schedule, a server) handing the agent a note and collecting the result. Once the agent takes notes, it can work anywhere notes can be delivered.
4. Home 2: the cloud schedule — the clock moves out first
The first move is deliberately the smallest one: keep everything you built, and relocate only the clock. Your config (the rules file, the skills, the subagents, the hooks) stays exactly what it is. What changes is who starts the beat.
The vendor path is the schedule the loop course promised, and it kept the name: a Routine. In Claude Code, the /schedule command (alias /routines) creates one by conversation. It saves a configuration that holds its prompt, repositories, connectors, and environment. That configuration runs on Anthropic-managed cloud infrastructure whether or not your laptop is open. Your repo-attached loop, "every weekday at 9am, run the morning triage skill, escalate anything above medium risk," becomes exactly this.
Three honesty notes from the live docs, each of which should sound familiar:
- Routines are in research preview. This is the most mechanical of mechanical layers, so verify before you rely.
- A scheduled run may start a few minutes after the hour, by design (the docs call this stagger). "Around 9am" is the real promise. That is this course's point about every scheduler, stated here by the vendor itself.
- A green run status only means the session exited without an infrastructure error. It does not mean your task succeeded. The loud-failure rule from Concept 3 stays yours to enforce, inside the prompt and the checks it runs.
One trap has a friendly name. Choosing Local in the desktop app creates a Desktop scheduled task instead, which runs on your machine. That is home 1 with a timer, not a move at all.
In Claude Cowork, the same idea for knowledge work is a Scheduled Task. You describe it once, and it runs remotely on its schedule with your connectors, skills, and plugins. The results wait for you when you look. One caveat comes from the same docs: a task that needs local files or desktop applications runs locally, which quietly makes your laptop necessary again. Pick by what the loop touches: repository work is a Claude Code Routine; connector-and-document work is a Cowork Scheduled Task. Either way, your laptop's only remaining job is to be the place you read the results.
Two honesty notes, both mechanical-layer. First, a cloud runner is not your machine. What it can reach (which repos, which connectors, which credentials) is configured, not inherited. So your first Routine run is partly a discovery of what the new home can and cannot see. Second, the harness travels as configured, but you must verify it did. The permission walls and hooks you rely on are files, and files only protect the runs that load them. Check the live docs for how Routines source your config, and treat the probation period (Concept 8) as non-negotiable.
For loops attached to a repository, there is a second, vendor-neutral version of home 2 that the loop course already built. It is a GitHub Actions workflow on a schedule: trigger. It runs claude -p headlessly on a CI runner, with your repo's config checked out alongside it. Same home, rented from a different company, with one honesty note GitHub itself publishes: scheduled workflows are best-effort. They can start late under load, are occasionally dropped, and run only from the default branch. For a morning loop, "around 9am" is the true contract; anything with a hard deadline needs the minimum unattended kit below, and possibly a stronger scheduler.
OpenCode itself has no first-party hosted control plane, and this course refuses to pretend otherwise, because the honest version is more instructive. With OpenCode, home 2 is a scheduler you choose. For repo-attached loops, use the GitHub Actions pattern from the loop course, running opencode run on a schedule: trigger with your .opencode/ config checked out. For everything else, use any machine that can run cron: a five-dollar cloud server, an always-on computer at home, a scheduled runner anywhere.
What you gain is exactly what the tool promised from the start: no vendor between you and your loop, your choice of model, your choice of provider. What you accept is that you are the vendor now: the runner's uptime, its credentials, and its updates are yours to manage. For a repo loop on Actions, that burden is small and mostly GitHub's. For a small computer under your desk, you have rebuilt home 1 with more work. That is why the Actions version is this course's default recommendation on this side.
The difference between the two tabs is the lesson, not a defect: an open tool gives you the whole runtime decision, with nothing hidden. You will meet this exact trade again in the Personal Agent Harnesses section, where owning the runtime is the entire point.
Whichever version you choose, the definition of success is the same and it is measurable: at least one full operating cycle and at least ten successful beats with your laptop closed, silence meaning baseline. Not "it ran once from the cloud" — the evals course taught you what one green run is worth — and not proof of long-term uptime either: call it initial operational evidence, and size it up for riskier or rarer loops. Scheduled beats, each one checked against the baseline, alarms tested once on purpose. That is home 2, moved into.
The minimum unattended kit. This course promised not to make you a DevOps engineer, and it keeps the promise with one table instead of a discipline. Six controls, none optional once no human watches the run. Every one is small, and every one exists because its absence has a famous failure story.
| Control | The rule | The failure it prevents |
|---|---|---|
| Idempotency | A retried beat must be safe to repeat | The invoice sent twice; the ticket filed twice |
| Missed-run detection | A second system notices when the first never started | A process that never ran cannot report its own absence |
| Concurrency lock | One beat at a time; the 9am run waits if the 8am run is still alive | Two agents editing the same files on one queue |
| Credential discipline | Scoped service credentials, least privilege, rotated, never your personal login | The cloud runner holding your whole identity |
| Time semantics | Timezone written down; daylight-saving and catch-up behavior decided in advance | The 6pm invoice that moves an hour twice a year |
| Cost and execution limits | Maximum duration, turns, retries, and spend per beat, with termination behavior | The wandering run that spends a month's budget overnight |
The kit is home 2's entrance fee (the price you pay before you may move in) and it travels: every later home asks for the same six, sometimes as service settings instead of your scripts. When Part 5's fourth question sets a speed limit, "the minimum safety gate" means this table.
The first move is the smallest one. You keep your whole setup and change only one thing: what starts the loop. Instead of you opening the laptop, a schedule in the cloud starts it, on a clock. Because no one is watching now, you add six small safety rules (the kit) so a run that fails cannot fail quietly.
Going deeper: the schedule moved, and the human gate did not
A subtle trap hides in the move. On your laptop, the human gate had a convenient property: you were there. The loop escalated, and the escalation landed in a window you were already looking at. In home 2, the loop runs whether or not you are anywhere near a screen, which means escalations can now pile up unseen, and an unseen escalation is a decision delayed, which is sometimes a decision made by default. So the move to home 2 forces an upgrade the laptop never demanded: the escalation channel must reach you, not your desk (a message, a mention, an issue with your name on it). And the loop course's "get loud" verb must be pointed somewhere you actually live. The gate did not move. The doorbell had to.
Your first cloud-scheduled beat runs green. A teammate says the migration is done. Using what the evals course taught about one run, and what this part added about silence, name the two things still missing before "done" is honest. First: one green beat is a fact about one run, not about the home — the migration is proven by a rate, which is why the success bar is a full operating cycle and at least ten beats compared against baseline, not a first night. Second: loud failure has not been tested. Until you plant one deliberate failure and watch the alarm reach you (the evals course's "test the alarm once" habit, relocated), silence is ambiguous — it could mean baseline, or it could mean the runner never started and nothing existed to complain. Done is: a week green, alarm tested, escalations arriving somewhere you actually look.Show answer
Part 3: The Managed Runtime
5. Home 3: you send a definition; a service runs a worker
Home 2 moved the clock. Home 3 moves the control plane, and, only if you choose it, the execution plane with it. A managed runtime is a service with a simple, radical contract: you describe your agent (the model, the system prompt, the tools and connectors, the guardrails) and the service operates it. The loop, the session state, the retries, the crash recovery at 3am: the control plane runs on the vendor's computers, operated by the vendor's engineers, and, by default, the sandbox does too. You stop operating the agent loop. What you keep operating is everything around it: the calling schedule, the credentials, the event consumption, the escalations, the spend limits, the incident when the outcome is wrong. You are the author of the definition, and still the owner of the business system.
As this course is written, the concrete instance is Claude Managed Agents, which entered public beta in April 2026. Its shape is worth learning even if the details shift, because the shape is the idea. You create three things:
- An agent: the definition: model, prompt, tools, guardrails. Your rules file and reviewer prompt, translated into a form a service can hold.
- An environment: the walled space where the agent's actions execute, the harness course's fences, as a service-side object rather than a local config file. This is the execution plane, and it is a choice: a cloud sandbox on the vendor's infrastructure by default, or a self-hosted sandbox on infrastructure you control, for work whose data must not leave your custody. Either way the fences are yours to set: the vendor's own production guidance is least-privilege networking with an explicit allowed-hosts list, which should sound exactly like the harness course.
- A session: one ongoing piece of work, with its own preserved state and an append-only event log — the loop course's beat, except it can pause, resume, and survive for days, because no laptop needs to stay open under it.
Your application (or, at this course's scale, your script) talks to these over an API and streams back events. The architectural detail that matters most: in this home, the two planes from Concept 2 become visible and separable. The model that thinks and the sandbox that acts are distinct pieces, connected by the service. You met the coupled version in every earlier course — the agent and its tools living in one process on one machine. The decoupled shape is what lets someone else operate the acting part at scale, and it is the shape production agent architectures are converging on. Remember that idea: it returns, as a design choice you make yourself, in Mode 2.
Two boundary facts, stated plainly because vendors state them quietly. A managed control plane is vendor-specific: this one runs Claude, operated by Anthropic. The sandbox may sit on your infrastructure, but the loop, the sessions, and the model path do not, and the OpenCode tab below is honest about what that means for the open-source side. And a managed runtime is not the SDK with hosting added: the Agent SDK and Managed Agents are separate products, and code written against one does not deploy onto the other. What carries across is not code. Part 4 is about what does.
The translation exercise, from what you own to what the service holds: your loop's job description becomes the agent's prompt. Your permission walls and deny rules become the environment's configuration. Each scheduled beat becomes a session your script opens headlessly, on the same schedule home 2 taught you to run. The endpoints, the SDK call shapes, and the beta headers are the most mechanical layer in this entire book. They are weeks old, and they move monthly. Take every one of them from the live docs at docs.claude.com, and treat any tutorial older than a season, including this one, as a shape, not a reference.
There is no first-party home 3 on this side, and this course will not fake one. But be precise about what is missing. OpenCode runs remotely just fine. opencode serve gives you a headless server process. Clients can attach to a remote instance, and the whole thing containerizes onto any managed compute you like. What no one offers is a first-party managed control plane (a vendor operating the loop, the sessions, and the recovery as a service). An open tool with interchangeable models has no single vendor to do it. So the honest equivalents here are a hardened home 2 (a scheduler plus the kit, you as the vendor) or a server process you write and operate. If you run it seriously, that server process is home 4's material and Mode 2's. What this side buys you instead is the thing no managed control plane can sell: nothing between you and the loop. Which trade is right is not a tool question. It is Part 5's question.
Homes 1 and 2: you employ the worker and also maintain the office they work in. Home 3: you write the job description and the office rules, and a building-services company runs the office: power, security, night shifts, repairs. You visit through reports, not through the front door.
6. What you get, what you give, what it costs
The managed contract, weighed honestly on both sides.
What you get. The operations you never wanted: sandboxing maintained by the people who built the harness, session state that survives crashes and days-long jobs, context management and prompt caching tuned to the current model by the vendor who ships the model, which reduces the model–runtime compatibility work the harness course made you do by hand. Be precise about what that buys: it does not solve behavioral drift, and coordinated model-plus-harness updates can make a regression harder to attribute, because two things moved at once; the scheduled baseline run from the evals course keeps its job in full. And the infrastructure pager is theirs (the pager: the alarm that wakes the responsible engineer at night). The 3am restart is, by contract, not your problem. The business-outcome pager remains yours: when the work is wrong, on time, on their machines, the escalation is still your responsibility.
What you give. Three things, from lightest to heaviest. Visibility: you read the event log the service emits, not the machine itself; depth-3 trace grading (checking not just the answer but the steps the agent took) now depends on what the log contains. Custody: your prompts, fixtures, and the work's inputs execute on infrastructure you do not control. For some data, in some professions, under some regulators, that one fact decides the question. No feature list changes the answer. Portability: your definition is written in this vendor's shapes, and the day you leave, the definition is rewritten, not moved. That is Part 6's subject.
What it costs. A new kind of bill, which matters more than the current numbers. Homes 1 and 2 cost tokens plus whatever the runner costs. Home 3 adds a meter (a counter of use, like an electricity meter) for runtime itself. As this is written, that is about eight cents per hour of active session work (idle time free), plus tokens, plus metered extras like web search. Two consequences follow from the shape. A session that thinks briefly and sleeps long is nearly free to keep, which is precisely what makes long-lived sessions affordable at all. And a loop that wanders (the depth-3 disease the evals course taught you to grade) now costs money as well as time, which makes your eval suite a cost control, not just a quality gate. The numbers will drift; check the live pricing page. The shape is the lesson.
A managed runtime is a trade. You get: the vendor handles the operations you never wanted (crashes, restarts, keeping the sandbox healthy). You give: some visibility, custody of your data, and easy portability. And it adds a new kind of bill. You pay for the runtime by the hour it is actively working (idle time is free), so a loop that wanders now wastes money, not just time.
Going deeper: vendor updates help and hurt at the same time
The drift story from the evals course had a fixed shape: the model moved under your unchanged harness, and the baseline caught the tilt. Home 3 changes the shape without removing it. Now the model and the harness move together, on the vendor's schedule, tuned by the vendor's engineers, which usually means fewer small problems than your hand-tuned config caught, and occasionally means a behavior you relied on changes without any file of yours changing. The defense does not change at all, and that is the point: the scheduled full-set run, the committed baseline, the loud alert on a drop. A managed runtime removes your operations burden. It does not remove your measurement burden. Nothing in this book ever removes that one.
A colleague argues: "Managed runtime sessions are metered by the hour, so it is obviously more expensive than running the loop on our own schedule." Name the two things this misses: one about the meter, one about what the meter replaced. The meter: it counts active runtime, and idle is free — a session that works minutes per beat and sleeps otherwise accrues almost nothing on the runtime line, so "per hour" is not "per hour of existing." What it replaced: home 2's price was never just tokens; it was tokens plus a runner plus your hours — configuring, updating, and being the one the failure wakes. The honest comparison is total cost including the operator, and it lands differently for a hobby loop (home 2 wins easily) than for ten loops serving a team (the pager has a price too). Which is why cost is the fourth input to Part 5's decision, not the first.Show answer
Part 4: The Move Itself
7. The suitcase test: discipline travels, mechanics do not
Every move between homes, this course reduces to one packing question: what goes in the suitcase, and what gets rebuilt on arrival?
What travels is everything the trilogy actually taught. The spec: what the job is and what "done" means. The rubric, with the anchors you worked hard on. The golden set, with every case's origin line, and the baselines beside them. The ratchet log (the running record of caught failures, each turned into a permanent test case). The maker–checker split, the category bars (the minimum pass rate each kind of case must clear), the human gate. Look at that list and notice what it has in common: none of it is software. It is decisions, written down. That is why it travels — a decision does not care which computer enforces it.
What does not travel is everything with a vendor's or a machine's name on it. Flags and output formats. File paths. Session state. Code written against one runtime's API — the SDK-versus-managed boundary from Concept 5 is this rule at its sharpest. And cost assumptions, which Concept 6 showed change shape between homes, not just size.
This is also, finally, the real answer to lock-in, so state it plainly: your portable asset is the discipline layer, and its portability is something you maintain, not something you have. Every time a rule lives only in a vendor-side setting instead of your repo, every eval case that exists only inside a service, every bar that was decided but never written down: that is weight moving out of the suitcase. The habit that keeps you movable costs one sentence: the repo holds the truth; every home is configured from it.
Moving house, you pack the things that are yours and leave the lamps that are fixed to the walls. Your spec, rubric, cases, and bars are yours: they go in the suitcase. The flags, paths, and API shapes are fixed to the old house: they stay behind. People who stay movable keep their valuables in the suitcase even while living in the house.
8. Trust is re-earned, not transferred
The last item on the figure's right-hand panel deserves its own concept, because it is the one movers most want to skip. Your 35/36 was a measurement of a system: this config, this harness, this model, this machine, this set of reachable tools. The move just changed several of those at once. Whatever runs in the new home is a close relative of what you measured — but the old number was measured on a system that no longer exists, so it cannot simply be inherited. It remains the comparison target: the standard the new home must meet, not a label the new home gets for free.
So the arrival protocol is the evals course, replayed deliberately, and it should feel familiar because a move is just the largest "change" your regression discipline has ever gated:
- Run the full golden set in the new home, first thing. Not the smoke set, but the full set. The runner is headless, and the new home speaks headless. This was always going to work, which is why Concept 3 called it the bridge.
- Read the misses by category before by count, exactly as Concept 10 of the evals course taught. A tone case down is a small problem. An injection case (one that checks the agent resists a malicious instruction hidden in its input) down, in a home with new reachable surfaces, is an emergency: a rubric or fence fix comes before anything else moves in.
- Hold the bars, then record a new baseline labeled with the home. The old baseline is not deleted: it is the comparison target, and the release bars it enforced do not move just because the location changed. The new home must pass the existing bars; every meaningful difference from the old rate gets investigated, not accepted. Only then record the runtime-specific baseline (the
recordeddate, the model, the rubric version, and now the runtime). Keep both numbers in history, with the explanation for any gap. The environment-specific baseline changes. The acceptance standard does not silently move. - Probation before dependence. Set a fixed period: at least one full operating cycle and at least ten successful beats, longer for riskier or rarer loops. During it, the old home stays available, and the new home's beats are checked daily against the new baseline. Call the result initial operational evidence, not proof of uptime: five quiet weekday runs establish very little. The move is complete when the new track record, not the old reputation, says so.
Your old score was measured on your old setup, and the move changed that setup, so the score does not come with you. In the new home you earn it again: run your full test set on day one, look at what failed and what kind of failure each one is, keep the same pass-bar you always used, write down a fresh score with the new home's name on it, and watch it for a trial period before you trust it.
One warning shaped like the harness course's bad night. The new home has new reach — a cloud runner sees different credentials than your laptop; a managed environment exposes different tools than your local config. Your injection and blast-radius cases were written against the old reach. Before probation ends, walk the golden set's hard cases and ask of each: does the failure this case guards against look different from here? Usually no. The time it is yes, that question just earned its place in every future move.
After moving to home 2, your first full-set run reads 33/36 against an old baseline of 35/36: one clean-fix case flaked (green on re-run), and both misses that remain are the same case — a fixture that reads a file by an absolute path from your old laptop. Sort the three misses using this concept and the suitcase test. The flake is noise, handled by the evals course's re-run policy: recorded, not gating. The repeated miss is not a regression of the agent at all. It is a suitcase error: an absolute file path is mechanics, and it traveled by accident inside a fixture. The fix is to repair the case (make the fixture path-relative), not the system. Then, per the evals course's own rule, re-baseline in the same commit, because the set changed. The bars themselves do not move, and the repair must be visible in history, so a genuine regression can never hide inside a "suite fix." Net honest reading: the new home is at baseline; the move surfaced a portability bug in the suite itself, which is exactly the kind of thing first-run-in-a-new-home exists to catch.Show answer
Part 5: Choosing a Home
9. The four questions
Everything the course has built compresses into four questions, asked in order. The first three pick the home. The fourth decides when it moves in.
Q1: Who is the user? If the honest answer is you, stop early: home 2 is almost always the ceiling of what you need, and this is most readers, most of the time, and nothing to apologize for. The moment the answer includes other people — a team consuming the output, a client, a customer — the loop must survive your absence, your vacation, and your login, and the question sharpens into Q2.
Q2: What must you own? Not what you want to own, but what you truly must own. The two planes make it a precise question with three answers. Nothing must be owned: a fully managed runtime fits, and letting a vendor carry the infrastructure pager is not a compromise; it is the correct use of money. Only the execution and data plane (the work and what it touches, but not the loop): home 3 with a self-hosted sandbox answers exactly that. You keep custody, and you rent the operations. The control plane too — the prompts, the sessions, the model path, or a product whose surface the agent lives inside: that must points past home 3 to the owned runtime, the SDK path, and Mode 2.
Q3: Does a person wait on the answer? Scheduled and background work — triage, reports, pipelines, everything this section has built — fits schedules and managed sessions comfortably. A human waiting on a screen changes the requirements, not automatically the owner. You now need a serving runtime with predictable startup, streaming, cancellation, and concurrency. A managed service may provide that better than a self-operated one, and owning the runtime does not buy it by itself, since no runtime can remove the model's own thinking time. Ownership still comes from Q2. What Q3 tells you is that serving is a different shape of work, and that shape is Mode 2's, and recognizing it is enough for now.
Q4: What does a bad night cost? The harness course's budgeting question, asked one last time. Low blast radius: pass the minimum unattended kit, move early, and harden the rest during probation. High blast radius: the new home passes the kit and the full suite, injection categories at all-of-them, before it takes a single unattended shift. Q4 never changes the destination. It sets the speed limit.
Four questions, asked in order. Who uses it: only you, or other people too? What must you own: nothing, just the work, or the whole loop? Does a person wait for the answer on a screen? And what does a bad night cost? The first three questions pick the home. The last one only sets how fast you move in.
10. One move, end to end — and homes are mixed on purpose
Watch the whole course run once, on the loop this section has carried since its second course: morning triage.
The questions. Q1: the user is you, plus, as of last month, two teammates who read the triage report. That "plus" is the trigger; the loop must survive your login. Q2: no must — the repo is on GitHub already; nothing in the queue is custody-restricted. Q3: nobody waits on a screen; the beat runs before anyone sits down. Verdict: home 2, GitHub Actions version, since the loop is repo-attached and the eval gate from the evals course already lives in the same CI. Q4: a bad night files bad triage labels and one wrong escalation: annoying, recoverable, low radius. Speed limit: kit passed, move now, probation two weeks — the loop runs weekdays, and ten beats is the floor.
The move. Monday: the workflow file (schedule: trigger, headless invocation, config checked out from the repo, exit code checked, failure wired to get loud in the channel you actually read) plus the kit's three cheapest controls: a concurrency lock, a missed-run heartbeat, and per-beat limits. The suitcase check: one fixture found holding a laptop path, repaired, set re-baselined in the same commit. First full-set run in the new home: all categories at bar. New baseline committed, labeled runtime: actions. The two weeks that follow: lid closed, beats on schedule, silence meaning baseline — one planted failure midway, because an alarm you have never heard is a rumor. Beat ten passes; probation ends; the laptop schedule is deleted. The system now has two track records, and the newer one is the one that counts.
The mix. And notice what the full system looks like now, because it is deliberately not one-home. The loop lives in home 2. The eval gate lives in the same CI, per the evals course. Heavy one-off jobs (the quarterly cleanup, the big refactor) still run in home 1, interactively, where you can watch. And if those teammates grow into a client, Q1 re-fires and home 3 enters the conversation for the serving path only. A home is not a permanent loyalty. It is a per-loop answer to the four questions, and a healthy system usually spans two or three of them. What keeps the mix from becoming a mess is the one sentence from Concept 7: the repo holds the truth, and every home is configured from it.
A home is not a place you settle for good. It is a choice you make for each loop, using the four questions. Most real setups use two or three homes at once: the daily loop on a schedule, and a heavy one-off job on your laptop where you can watch it. One rule keeps the mix from turning into a mess: the repo holds the truth, and every home is set up from it.
Re-run the four questions for a different loop from this book's world: Ayesha's invoicing loop, now serving five clients who receive the invoices directly, one of which is a bank that requires client data to remain on infrastructure Ayesha's firm controls. Where does each question land, and what is the uncomfortable honest conclusion? Q1: the users are clients: past home 1 and, for dependence, past "whenever her runner happens to work." Q2 is the deciding question, and the two planes make it precise: the bank's must is about execution and data: where the work runs and what it touches. A managed control plane with a self-hosted sandbox on the firm's infrastructure may satisfy exactly that, keeping the client's data in the firm's custody while the vendor operates the loop. Whether it does is the bank's call, not Ayesha's: if the must extends to the control plane too — the prompts, the sessions, the model path — only an owned runtime answers it. Q3: invoicing is scheduled background work, no latency pressure. Q4: wrong invoices to real clients is high radius: kit and full suite before any unattended shift. The honest conclusion: no single home fits, and the bank's path is either home 3 with an owned execution plane or, if the requirement reaches further, the SDK path. Either way Ayesha has hit the edge of what an operator can configure alone, and that edge has a name in this book: Mode 2. This is precisely the moment the book's fork exists for.Show answer
Part 6: Staying Honest
11. Lock-in is a rate, and ownership drifts
Two slow failures follow every home past the first, and neither announces itself.
Lock-in is a rate, not an event. Nobody signs away portability on day one. It leaks: a rule tweaked in a vendor-side setting and never mirrored to the repo; an eval case added inside a service console; a bar renegotiated in a dashboard with no commit behind it. Each is one item quietly moving from the suitcase to the fixtures. The measure of your lock-in at any moment is one direct question (if this home vanished this quarter, what would the move cost?) and the defense is the sentence you already have: the repo holds the truth. Audit it the way Part 6 of the evals course audits Goodhart (the trap where a number, once it becomes the target, stops measuring what you cared about): on a schedule, with a hold-out mindset (testing against a set you keep aside and never tune to). A quarterly practice run of "configure a fresh home from the repo alone" is the hold-out set of portability. If the fresh home cannot be completed, you have found the leak while it is still one item wide.
Ownership drifts even when nothing leaks. The subtler failure is in you, not the files. A home that runs quietly for months invites a small promotion in your head: from this system is measured to this system is fine. The evals course named the mechanical version — a judge's 95 changing meaning under a drifted model. The runtime version is human: baselines still green, schedule still silent, and you slowly stop reading the per-category report, stop replaying the calibration, stop asking Concept 8's new-reach question when the vendor ships a new capability into your environment. Nothing in the discipline has a step called "and then it maintains itself." The scheduled run watches the system. The calendar reminder to read it watches you.
Two slow problems creep up on you. First, leaving a home gets harder over time, one small setting at a time, unless you keep everything in your repo. Second, a home that runs quietly for months makes you stop checking it. The fix for both is the same: keep the repo as the single source of truth, and set a calendar reminder to actually read the reports.
12. What no home can fix, and where this goes
End the section the way every course in it has ended: at the honest boundary. A better home changes when your agent works, who keeps it alive, and what happens at 3am. It does not change one thing about how well the agent works. A weak spec is weak on Anthropic's cloud. An uncalibrated judge is uncalibrated at eight cents an hour. A missing eval case is missing on every runner on earth. The runtime decision is the last course in this section precisely because it is worthless as the first: everything it relocates had to be worth relocating. If any move in this course felt easy, that is why. The hard part was the trilogy. The move is just a suitcase.
A better home changes when your agent runs, who keeps it alive, and who fixes it at 3am. It does not make the agent any smarter or more correct. A weak plan is still weak in the cloud. Good work comes from the spec, the harness, and the tests you already built. The home only decides who keeps it running.
And now the section's arc is complete, so read it once at full length. You learned to drive a general agent, then to direct it with a spec, then to delegate the loop, harden the harness, and measure the checker, and now to house the whole system somewhere worthy of it. What you own at the end is the thing this book has been quietly assembling since its first page: a specified, guarded, measured, housed unit of work. Hold that phrase against the book's vocabulary and the next door opens by itself: that unit, built for other people and given an owned runtime, a product surface, and a price, has a name — a Digital FTE. You have been manufacturing one at operating scale all along.
Three doors leave this section, and the four questions already told you which is yours. The Personal Agent Harnesses section, next door, is for the reader whose Q2 answered must own on personal scale: your worker, your infrastructure, the whole runtime decision taken by hand. Mode 1 — Problem-Solving is for solving real problems now with the system you have, most readers' right next step. And Mode 2 — Manufacturing is where every promise this course previewed is completed: home 4 opens up through the Agent SDK, the decoupled architecture returns as a design choice you make rather than inherit, and the Eval-Driven Development course scales the suite that just supervised your move.
The closing thought, for the section. The loop gave your agent time. The harness gave it limits. The evals gave it a track record. This course gave it the last thing a worker needs: an address that is not yours. One literal sentence under the rhetoric, so nobody mistakes the finish line: an independent address is the final requirement of this section, not of production operations. A served product still needs an owner, an escalation path, a retention policy, continuity, and someone with the authority to switch it off, and Mode 2 teaches all of it. But show up, do the work, prove the work, live somewhere on its own: that was always the whole job description. For agents, and not only for agents.
A reader finishes this course and says: "So the endgame is home 3 — managed is where everything eventually goes." Using Q1–Q4, the mix from Concept 10, and the boundary above, write the two-sentence correction. There is no endgame home: the four questions are asked per loop, and a healthy system spans homes on purpose — build in 1, schedule in 2, serve from 3 or from an owned runtime when a must demands it. And no home is an upgrade to the agent itself: quality lives in the spec, the harness, and the suite, which travel; the home only decides who keeps the lights on (keeps it running).Show answer
Where this book's own loops live (dogfooding)
This course's decision ran on this book before the course existed. The book's review loop (reviewer rubric, the 95 bar, no merge below it) answers Q1 with "a team": authors, and readers who file issues. So its designed home is home 2 — CI on the book's repository, the exact GitHub Actions version this course teaches — because the loop is repo-attached and the eval gate belongs beside the merge gate. The heavy interactive work (a new course drafted, a figure pipeline run) still happens in home 1, where a person watches. And home 3 is, as of this writing, an open question the book treats exactly as Part 5 says to: no must own forces the serving path, no latency pressure exists, so the managed option waits until Q1's answer grows again. The repo holds the truth; the homes are details. You are reading the output of the arrangement right now.
🚀 Projects
Eight moves, easy to hard. Same two rules as always: throwaway repo, and plant the failure yourself — a home is only proven by the bad night it survives.
📁 Project 1 · 30–45 min · The headless wrapper. Difficulty: easy · Uses: Concept 3. Build. Wrap your loop's beat in a script: headless invocation, exit code checked, failure getting loud somewhere you actually look. Done when running it with the network cable pulled produces an alarm, not silence. Silence must mean success before anything else in this course is safe.
⏰ Project 2 · 1–2 hrs · The first scheduled beat. Difficulty: easy–medium · Uses: Concept 4.
Build. Put the wrapper on a schedule in home 2 (Routine, or Actions schedule: trigger) with config sourced from the repo.
Done when one beat has run with your laptop closed, and you can point at where the result landed. The kit's first three rows also exist in some form, however small: idempotency, missed-run detection, and a concurrency lock.
🧳 Project 3 · 45–60 min · The suitcase audit. Difficulty: medium · Uses: Concept 7. Build. Walk your config, cases, and fixtures with the two-panel figure open. List every item of mechanics hiding in the discipline layer: absolute paths, machine names, flags baked into prose. Done when the list is committed and the worst three are fixed. Expect to find at least one; the Part 4 story was not invented.
📏 Project 4 · 1–2 hrs · The arrival protocol. Difficulty: medium · Uses: Concept 8.
Build. Run the full golden set in the new home. Sort misses by category. Record a new baseline labeled with the runtime.
Done when baseline.json carries a runtime: field and every miss has a written verdict: noise, suite bug, or real, with the fix for the real ones shipped.
🌙 Project 5 · 1 hr, plus two weeks of nights · Probation. Difficulty: medium · Uses: Concepts 4 and 8. Build. At least one full operating cycle and at least ten scheduled beats in the new home, checked daily against the new baseline, old home kept available. Plant one failure midway. Done when ten beats are green, the planted alarm reached you, and the old schedule is deleted. That is the course's definition of "moved in." Write "initial operational evidence" at the top of the log, because that is all ten beats are.
🗺️ Project 6 · 45–60 min · The four questions, in writing. Difficulty: medium · Uses: Concepts 9 and 10. Build. For each loop you actually run, answer Q1–Q4 in one committed markdown file, ending each with a home and a speed limit. Done when a reader of that file alone could tell you where every loop lives and why. And at least one loop's answer surprised you enough to move it.
🏢 Project 7 · 2–3 hrs · One session in home 3. Difficulty: medium–hard · Uses: Concepts 5 and 6. (Claude Code track; OpenCode readers: harden Project 2's runner instead: credentials rotated, updates scheduled, uptime checked.) Build. From the live docs, create one managed agent, one environment, one session running a single graded case from your golden set. Read the event log end to end. Note the active-runtime meter before and after. Done when you can state, from your own run: what the log showed you, what it could not show you, and what the session cost. Three sentences, committed next to the Project 6 file.
🔥 Project 8 · 2 hrs, then a quarter of patience · The vanishing-home drill. Difficulty: capstone · Uses: Concept 11. Build. From the repo alone (no vendor console, no old machine), configure a fresh copy of your loop's home and bring it to baseline. Time it. Schedule the drill quarterly. Done when the fresh home passes the full suite, and the written time-cost is your measured lock-in. If the drill fails, you found the leak while it is one item wide, which is the entire point.
Sources & further reading
Inside this book
- Loop Engineering: the beats, the schedule, and the "get loud" verb this course relocates.
- Harness Engineering: the fences and the blast-radius budgeting that Q4 re-asks about runtimes.
- Trusting the Checker: the golden set, baselines, and drift discipline that every move in this course is gated by.
- Personal Agent Harnesses: the must own, personal-scale answer to Q2.
- Eval-Driven Development and Deploy the Agent Harness, in Mode 2: the same decisions at manufacturing size, with home 4 fully open.
The runtimes (official docs)
- Claude Code headless mode —
claude -p, output formats, scripting: https://code.claude.com/docs/en/headless - Claude Agent SDK overview — the library, and the SDK-versus-managed boundary stated plainly: https://code.claude.com/docs/en/agent-sdk/overview
- Claude Managed Agents quickstart — agents, environments, sessions: https://platform.claude.com/docs/en/managed-agents/quickstart (public beta as of April 2026; the fastest-moving docs referenced anywhere in this book)
- Managed Agents environments — cloud sandboxes, least-privilege networking, and the self-hosted sandbox option behind Concept 5's execution-plane choice: https://platform.claude.com/docs/en/managed-agents/environments
- Managed Agents pricing — the active session-hour meter: https://platform.claude.com/docs/en/about-claude/pricing
- Claude Code Routines —
/schedule, triggers, environments, stagger, and the green-status caveat: https://code.claude.com/docs/en/routines (research preview) - Claude Cowork Scheduled Tasks — the knowledge-work version of home 2, and the local-files caveat: https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork
- OpenCode CLI and server modes —
opencode run,opencode serve, remote attach: https://opencode.ai/docs/cli/ - GitHub Actions
schedule:triggers, and GitHub's own delay-and-drop caveats: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule and https://docs.github.com/en/actions/how-tos/troubleshoot-workflows
All links current as of mid-July 2026. This course's mechanical layer ages faster than any other in the section; confirm every name, endpoint, and price against the live docs before you rely on it.
The one-line summary
Who operates the loop, and where the work executes, is the question; headless is the bridge; the discipline travels, the mechanics get rebuilt, and the trust is re-measured on arrival. Four questions pick the home, blast radius sets the speed, homes are mixed per loop on purpose, and the repo holds the truth so you can always leave. A worker is finished when it has an address that is not yours.