Here are two scheduled jobs. Three lines each. Read them and look for the trick, because there isn’t one.

every 30 minutes:
  Check whether the main task and any delegated work are making real progress.
  Resolve stalls within your authority.
  Continue until the actual completion criteria are met.

Put that text in a crontab and nothing happens, because it is not a command. Deliver the same text into a running coding-agent session and it will inspect a hung process on one wake, read a subagent’s output on the next, and abandon a failing approach on the third — without a word of it ever being edited.

Nothing about the two jobs differs except where the words arrive.

So here is the question this book answers, and I want it on the table in the first hundred words rather than teased for six chapters:

Why does a three-line cron prompt make a coding agent seem to supervise itself, when a Unix cron job of the same size does nothing of the kind?

The artefact really is that small

It matters that the thing producing the behaviour is tiny, because the size is what makes the puzzle a puzzle. In the conversation that started this book, the whole supervisory instruction was described like this:

You can have a fairly simple prompt: just make sure you keep working and it hasn’t stopped.

That is not a system. It is a sentence. A sentence that short producing behaviour that adaptive is either magic or a mechanism nobody has named yet. It is the second one, and the rest of this book is the name.

Four explanations that are wrong

Before the right answer, clear the ground. Each of these is a position a serious person holds, and each of them fails for a specific reason rather than because it is silly.

What is left is the thing nobody looks at, because no scheduler asks you about it. Cron asks when. It asks what. It never asks where.

One of those jobs starts a process. The other reaches one.

The claim, stated once

The observation that started all of this was put plainly, before it had a name:

You can have a running session, a running conversation, doing some code, running some long-term tasks — and the cron wakes up inside that conversation, can see what the conversation’s been doing, and check on the work.

Compressed to its mechanism, that is:

A scheduler injects a prompt back into an addressable, already-running cognitive process.

I am going to call that Prompt-Interrupt Architecture, and Chapter 4 will explain why that name and not the plainer one that was also available. For now the only thing to hold is the shape of the claim: the power is in the destination, not the trigger.

Same timer, two destinations

The comparison is worth making concrete now, because everything in Part I is an elaboration of it.

What this book is not about

A book that answers every adjacent question answers none of them well, so let me fence three things off in the opening chapter and keep the fences up.

What is left is one question, and it is enough for a book: where does the prompt land?

How the argument runs

Chapter 2 establishes what is absent at a cold destination, taking cron seriously rather than mocking it — because cron is not broken, it is doing exactly what it was specified to do in 1979. Chapter 3 enumerates what is present at a live one, and names the single thing that is not. Chapter 4 supplies the operating-system vocabulary that makes both legible, and the artefact you will actually keep.

Then Chapter 7 attacks that artefact, because an analogy nobody audits is decoration. Part III builds for the destination: two kinds of persistence, a reconciliation with an architecture I published earlier that appears to contradict all of this, and one worked design. Part IV positions the doctrine against its own lineage — including a correction to one of my own books — and hands you two questions you can answer about your own scheduler in thirty seconds.

The short version, if you read nothing else: the intelligence was never in the cron.

In 1979, the Version 7 Unix manual described the sixth field of a crontab line as “a string that is executed by the Shell at the specified times.”¹

A string. Executed by the Shell. That has been the unit of scheduling for nearly fifty years, and in all that time it has never once been a message to something already running.

I want to be careful here, because the easy version of this chapter is a cheap shot at a fifty-year-old daemon, and the easy version is wrong. Cron is a correct solution to a different problem. It is small, it is reliable, it has outlived most of the things it was scheduling, and it does exactly what it was specified to do. The point is not that cron fails. The point is that its specification quietly decides what a scheduled job is allowed to be, and almost nobody has read the specification.

The environment is constructed, not inherited

POSIX is unambiguous about what a scheduled command receives. The values of the invoking user’s environment variables “shall not affect the default values provided when the scheduled command is run.”² The job gets a supplied default — a shell, a home directory, a login name, a path — and nothing else. In the common Linux implementation it is even narrower: “SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab´s owner.”³

There is a lovely piece of corroboration by exception. The cron daemon ships a flag, -P, whose entire documented purpose is: “Don’t set PATH. PATH is instead inherited from the environment.”⁴ A flag like that only exists if the default is a constructed environment rather than an inherited one. Someone had to add an option to make cron behave like the shell you were standing in.

And the only channel back is a letter. Unredirected output “shall be mailed, via an implementation-defined method, to the user.”² A report, after the fact, to a human. There is no address for a running job because there is no concept of one in the model.

The consequence: everything must be foreseeable

Because nothing is inherited, everything must be re-passed, re-derived or re-read. Which means the author of the cron line has to know the implementation in advance. A scheduled command can only ever do what was foreseeable at the moment somebody typed it:

run script A
check PID B
restart service C
invoke test D

That is a hardcoded orchestration system wearing a timer. Every new kind of work needs new scheduler logic, and the logic accumulates in a place that has no idea what is going on. This is the enemy of the book and I want it named precisely, because it is a tax rather than a bug:

The negative control

Take the exact three-line supervision job from Chapter 1 and hand it to a stateless invocation. Not a strawman — the same words, the same interval, a competent implementation. Here is what it cannot do, and the reason in each case is structural rather than a matter of effort.

The cleanest statement of the underlying problem is one I have made before, about loops rather than schedulers: a script that knows the steps still does not know how far you got. Fixed code holds structure, not position. Kill it at step seven of twelve and it restarts at step one — or worse, it restarts at step one and does not tell you.

The vendor’s own negative control

The most persuasive version of this argument is not mine. It is a concession in a documentation page, written by people who had every incentive to describe their cloud scheduler favourably.

Anthropic’s Routines run scheduled Claude Code sessions on managed infrastructure. The docs are candid about the cost of that destination: “Each repository you add is cloned on every run”, and “Each matching GitHub event starts a new session. Session reuse across events is not available for GitHub-triggered routines, so two PR updates produce two independent sessions.”⁵

And then the instruction that follows from it: “the routine runs autonomously, so the prompt must be self-contained and explicit about what to do and what success looks like.”⁵

Same vendor. Same timer. Cold destination — and the documentation tells you to write a different kind of prompt because of it. That is the whole thesis of this book, conceded in a docs page, by someone who was not arguing for it.

Suspended, not restarted

There is a word for the property the cold process gives up, and it comes from the place you would expect. Here is what an interrupt actually does to a running computer:

When an interrupt is received or an exception is detected, the currently running procedure or task is suspended while the processor executes an interrupt or exception handler. When execution of the handler is complete, the processor resumes execution of the interrupted procedure or task. The resumption of the interrupted procedure or task happens without loss of program continuity.

Suspended. Resumes. Without loss of program continuity. Nobody wrote that sentence about agents, which is exactly why it is worth borrowing. It is the precise technical description of what a scheduled prompt into a live session gets for free, and of what a cron-launched command throws away every single time it fires.

When the cold process is the right answer

I am going to be absolute about the destination argument for the next ten chapters, so let me be honest about its boundary here, before I have spent any credibility.

Which raises the obvious next question. If reconstruction is the cost, what exactly is it that a live session does not have to reconstruct?

“Context” is a noun that has been worn smooth. It gets used to mean the conversation, the prompt, the retrieved documents, the vibe. When people say a live session has more context than a fresh one, they are technically right and analytically useless, because the sentence does not tell you what changes as a result.

So freeze the frame. At the instant a scheduled prompt lands in a live agent session, what is actually in the room?

So what is actually in the room when the prompt lands?

Read it again as handles, not memories

The list looks like a description of what the session remembers. It isn’t, and the difference is the whole chapter. Go through it once more, slowly, asking what each item lets the agent do:

• A running process is not a memory of a process. It is a thing that can be inspected right now, whose exit code has not happened yet, whose CPU time is still climbing or has stopped climbing. You can look at it.
• A launched subagent is a correspondent, not a log line. It can be asked a question and it can answer one.
• A discovered error is a live priority that can displace the plan — not a note that an error occurred at 11:42.
• The definition of done is a test that can be run, not a sentence that was typed.

A transcript has the past. A process has the past and a grip on the present. That is the distinction people miss when they reduce this to “more context”.

The verb doing all the work in that sentence is interrogate. You cannot interrogate a log. You can read one, search it, summarise it, and be misled by it — but interrogation requires something on the other end that is still there and can be made to respond. A live session has counterparties. A fresh invocation has documents.

And this is the mechanism that Chapter 5 will cash in: nothing has to be reconstructed or passed in. Reconstruction is the hidden tax on every stateless design. It is paid every fire, it is invisible in the logs, and at a live destination it is zero.

What reconstruction actually costs

Nobody has published a clean number for what it costs an agent to rebuild its working state from artefacts. I looked, and I am not going to invent one. But the same problem has been measured carefully in human software work, and the shape transfers even though the magnitude does not.

Parnin and Rugaber instrumented interrupted programming tasks and measured how long it took developers to make their first edit after returning:

Their explanation is the part that generalises: “much knowledge used for the programming task is of a tacit and ephemeral nature — it is not explicitly written down anywhere, and it involves many temporary details that have not yet deeply taken root in the mind.”⁷ They also dispatch the obvious objection — write better notes — in one line: “a software program, unlike a novel or television series, does not have a simple linear structure — a recap or rescanning the last few paragraphs of text is not enough to allow the developer to resume work.”⁷

That is the tax the live destination does not pay.

Rich in state, poor in duration

Now the honest half, because a chapter that only lists advantages is a brochure.

There is one thing conspicuously missing from the working gestalt, and it is not a small thing. The live session cannot feel time pass. It sits politely on a hung child process. It loops the same subtask. It reports progress that has not moved since midnight. I have described the failure mode before and the defining symptom is not that it is stuck — things get stuck — it is that it doesn’t know it’s stuck.

So the gestalt is rich in state and poor in duration. It knows what is true. It does not know how long it has been true, and it has no wall clock to glance at.

Which is exactly why the interrupt has to come from outside

That asymmetry is not an awkward footnote. It is the reason the architecture exists at all, and it explains a design decision that otherwise looks like laziness: the scheduler is allowed to be the dumbest component in the stack.

It is allowed to be dumb because it is only supplying one faculty — the one the process cannot supply itself. It is not there to be clever. It is there to be outside.

Operating systems worked this out early, and for the same reason. The timer interrupt exists because a running program cannot be relied upon to yield:

The addition of a timer interrupt gives the OS the ability to run again on a CPU even if processes act in a non-cooperative fashion. Thus, this hardware feature is essential in helping the OS maintain control of the machine.

Non-cooperative is the operative word, and it is not an accusation. An agent absorbed in a subtask is non-cooperative in precisely the technical sense: it is not withholding a check-in out of stubbornness, it simply has no mechanism that would cause it to interrupt itself. Nothing inside the process is going to say “it has been three hours”, because nothing inside the process can tell.

Two chapters have now described the same event from opposite sides — what is missing at a cold destination, what is present at a live one. What is still missing is a vocabulary that makes both of them a single idea rather than two observations. That is the next chapter, and it is the one you will keep.

Analogies in this field are usually decoration. Somebody notices that agents are a bit like employees, or a bit like microservices, and the resemblance produces a diagram and no new questions. I want to justify this one before I draw it, and the justification is that the formal definition of an interrupt already contains the property the last two chapters have been arguing for. Not approximately. Exactly.

Interrupts and exceptions are events that indicate that a condition exists somewhere in the system, the processor, or within the currently executing program or task that requires the attention of a processor. They typically result in a forced transfer of execution from the currently running program or task to a special software routine or task called an interrupt handler.

A condition exists that requires attention. Execution transfers to a handler. The running task is suspended and later resumes. That is a description of hardware written decades before anyone scheduled a prompt, and every clause of it survives translation.

The mapping

I am not going to gloss thirteen rows. A full walk-through would turn the chapter into a glossary and most of the rows say what they say. Four of them do real work, and those are worth stopping on.

The handler row is the one that matters

In a computer, the interrupt handler is code somebody wrote in advance. That is the whole job: anticipate the condition, write the routine, register it in the vector table, and hope you anticipated correctly.

Here there is no handler to write.

Every other advantage in this book is downstream of that one substitution. You are not registering a routine for a condition you predicted; you are handing a general-purpose reasoner a live environment and a question. The handler is written at the moment it runs, by something that can see.

Executable: Markdown, and the spatial half of a metaphor

The executable row is not new to my writing. I have argued at length that an agent should run on plain-text instructions rather than compiled artefacts — your operating system runs on binaries; your AI agents should run on Markdown. What is new is that the executable now has something to be interrupted in. Chapter 11 comes back to this properly, because the relationship between those two books is the cleanest structural argument for why this one exists.

Journal: settled work, cited not re-taught

The append-only shift log converts a problem the model cannot solve into one it is excellent at. It cannot feel that three hours have passed with no forward progress; it can notice that its last three entries say the same thing. That mechanism is already documented and I am not going to re-derive it here — it is the journal row, and it is load-bearing.

Exit condition: where the table stops being an analogy

A verifiable definition of done is not a poetic mapping of “exit condition”. It is the same thing. My own earlier architecture work put it bluntly: not “feels done”, but objective, verifiable conditions — tests pass and lint clean and the description written. An agent with no exit condition does not terminate; it stops. Those are different events and only one of them is a result.

One row I am deliberately leaving alone: PID. It looks like the least interesting cell in the table and it is the precondition for every other one. Chapter 6.

The definition

Here is the canonical wording. It is long, and the length is deliberate: every clause in it is load-bearing, and dropping any one of them describes a different and weaker architecture.

Test it by deletion. Remove intention-bearing and you have a wake-up call, not a supervisor. Remove addressable and you have a fresh boot wearing a schedule. Remove inspect its current cognitive and execution environment and you have a chatbot being pinged. Remove durable state remains external and you have built something that loses a night’s work and looks fine while it does it — which is Chapter 8’s whole worry.

The name we didn’t use

Showing you the rejected option is not modesty. The rejection is the evidence of judgement: a name chosen against an alternative tells you what the choice was optimising for, and a name presented alone tells you nothing.

Before you object

Somebody reading this is already composing the reply that analogies are cheap, that any sufficiently determined author can map anything onto anything, and that a thirteen-row table is thirteen opportunities to be wrong.

Correct. So Chapter 7 audits it. Not defensively — three of those rows do not survive contact with the documentation, one of them inverts, and the inversion turns out to be more interesting than if the row had held. I would rather publish the failures than wait for somebody to find them.

What the table is for, in the meantime, is not the claim that agents are computers. It is that a set of questions becomes askable about your scheduler that were not askable before: what is the latency of your interrupt, can it be masked, what happens if one arrives while another is being handled, what privilege does it carry, and what does the handler cost you every time it runs. A vocabulary earns its place by generating questions. This one generates six, and two of the answers are uncomfortable.

The mapping table has a hole in it, and a good engineer finds it inside about four seconds. If the executable is a Markdown prompt, then what actually runs? Something still has to open the file, kill the process, rerun the test, read the log. English does not do any of that.

The answer is that the code did not disappear. It moved below the prompt boundary.

The scheduler executes an intention. The agent decides which code, tools and actions realise it.

Which is the polished version of a flatter observation from the conversation that started this book: if you want to run code, the prompt has to run it. Both sentences say the same thing, and the flat one is the more useful of the two when you are actually building, because it makes the obligation concrete. Nothing is exempt from execution. Something still has to do the work. The question is only who decides what the work is, and when.

Why this is a consequence of destination

This is the beat that keeps this chapter inside its own book, so I want to be exact about it. Plenty of people have observed that prompts can carry intent. What is less often noticed is that intent is only cheap where the situation is already present.

Take one phrase from the Chapter 1 prompt — resolve stalls within your authority — and evaluate it at both destinations, word by word.

Same eleven words. At one destination they are a wish. At the other they are an instruction. Nothing about the writing changed — the words got their meaning from the room they arrived in.

What the same prompt does on four consecutive wakes

The consequence is the behaviour that started this whole investigation. Here is the fuller version of the intent-carrying prompt:

Review the active goal and current work.

Check whether the main task and any delegated work are making real progress.
Inspect the relevant processes, files, logs and artefacts.
Resolve stalls within your authority.
Continue until the actual completion criteria are met.
Remove this scheduled check when the work is genuinely complete.

Fire that six-line block four times into a live session and you get four different behaviours. It inspects a process on the first wake because something is running and nothing has moved. It reads a subagent’s output on the second, because the subagent has finally reported and the report is thin. It reruns a command on the third, because the log shows a transient failure. It abandons the approach on the fourth, because two attempts have now failed the same way and the exit condition is no closer.

Nothing about the prompt changed. The situation changed — and the prompt was never about the actions in the first place.

What it costs

Now the part that gets left out of the enthusiastic version of this argument.

The same move, one clock earlier

None of this geometry is new to my writing, which I think makes it more credible rather than less. I have argued the identical structure at build time: the human-owned package — intent, design, prompts, worldview context, tests, decisions that regeneration must not re-guess — is the durable upstream source, and generated code is compiled output relative to it. Each stage of the cascade is source relative to the stage below it and compiled output relative to the stage above.

So:

Same geometry, different clock. I would rather point at the family resemblance than claim novelty, because a claim that fits an existing structure is a stronger claim than one that arrives alone. This is not a new idea about prompts. It is an old idea about compilers, applied to a moment in time rather than a stage in a build.

What this chapter is not about

Everything above argues that the destination makes intent writable. It says nothing about what you should actually write — the authority limits, the completion criteria, the instruction to update the journal, the instruction to remove the timer when the gates genuinely pass. Those are real design questions, they have real answers, and they belong to a different piece. I am fencing them off here rather than letting them leak in a paragraph at a time.

And let me refuse an overreach that this chapter invites. Nothing here says prompts should replace scripts everywhere. The claim is narrower and it survives better: a scheduler with a live destination is permitted to carry a question. Whether it should, and what the question should be, is a separate argument.

Code has not been abolished. It has been relocated. The scheduler used to sit above the implementation, which meant it had to contain it. Now it sits above the intention, and the implementation gets chosen at the moment it is needed by the only component in the system that can see the situation.

All of which depends on one unexamined word. Within.

“Within a session” is what separates an interrupt from a boot. Everything in the mapping table is downstream of those two words, and those two words are downstream of something so mundane that it is easy to skip: a process you cannot name is a process you cannot interrupt.

Operating systems have never been coy about this. “Each process has a name; in most systems, that name is a number known as a process ID (PID)”, and the reason it exists is entirely practical — the PID “is used to name the process if one wants to do something with the process”.¹⁰

There is even a fifty-year-old precedent for a liveness probe against an identifier. In kill(2): “If sig is 0, then no signal is sent, but existence and permission checks are still performed; this can be used to check for the existence of a process ID.”¹¹ Ask whether it is alive without disturbing it. Hold that thought until Chapter 10.

Can you name your session?

That is the question, and until you can answer it the rest of this book is a nice metaphor about somebody else’s system.

It exists, and it is documented

This is the chapter where the argument stops being architecture and becomes observation, so I have restricted myself to public product documentation, read outside-in on 27 July 2026, with the quotes carried into the references. No inside knowledge, no roadmap, no inference about anyone’s intent — only what shipped.

Claude Code documents scheduling tools whose stated purpose is “to run prompts repeatedly, poll for status, or set one-time reminders within a Claude Code session”, and is explicit about the consequence: “Tasks are session-scoped: they live in the current conversation and stop when you start a new one.”¹² The command that drives it, /loop, is described as running “a prompt repeatedly while the session stays open.”¹³

What makes that more than a feature note is the comparison table published beside it. Three ways to schedule work, and one row that is this entire book:

Requires open session: yes. That is the thesis of this book priced as a product trade-off, by an organisation with no interest in proving it. And notice the two rows underneath: /loop alone inherits its tools and its permissions from the session. It does not receive a configuration; it arrives somewhere that already has one.

The identity is real, not rhetorical

A session identifier that only exists in prose would make the PID row of the table decorative. It doesn’t. Sessions are addressed by name or UUID: --resume, -r will “Resume a specific session by ID or name”; --session-id takes a value that “must be a valid UUID”.¹⁴

claude --resume
claude --session-id "550e8400-e29b-41d4-a716-446655440000"
claude -r "auth-refactor" "Finish this PR"

And the identity survives disconnection: resuming with --resume or --continue “brings back any task that hasn’t expired”.¹² The process can be detached from and returned to, with its pending interrupts intact. That is not a metaphor for a process. That is a process.

A second vendor, and a correction

OpenAI has shipped the neighbouring primitive. Scheduled tasks in Codex and ChatGPT run on a schedule and can be combined with skills — “You can combine scheduled tasks with skills for more complex work” — and, decisively for this argument, they can be created inside an existing chat: “Schedule a task inside an existing chat when you want ChatGPT to return to that chat on a schedule. The scheduled task uses the chat’s existing context instead of starting from a new prompt each time.”¹⁵

One more piece of housekeeping in the same spirit. The conversation this book grew from included a claim that Codex can wake itself to continue long-term work across days or weeks. I could not confirm that in current public documentation at the time of writing, so it does not appear here in any form. It is cheaper to say that than to soften it into an impression.

Seven parts of a small cognitive operating system

Rather than describing one product, take the pieces as a checklist and run it against whatever you are building. A stack that has all seven has a process you can interrupt. A stack missing the first or the last has a transcript with a timer attached.

It is worth registering that this is a slightly startling list to be able to write about shipped software rather than about a design. The reaction in the original conversation was not analytical:

I can’t believe they’ve been able to build Claude Code to do this.

What to conclude, and what not to

Conclude that the primitive exists, is documented, has delivery semantics and a tool surface, and is observable rather than proposed. That is a meaningful thing to be able to say about an architectural argument, and it is the reason this book is a description rather than a proposal.

Do not conclude anything about what either vendor intends, plans, or will keep. I have quoted documentation and nothing else, deliberately. And the read that everyone reaches for — two independent vendors converging on the same primitive within months, and what the CLI-versus-app split says about where interfaces are going — is a genuinely interesting argument that is not this one. It gets its own piece.

That is Part I. The mechanism, the artefact, and the proof that the artefact describes something real. Which means it is time to attack it.

Here is the standard I would like applied to my frameworks, so I will apply it to this one first.

An analogy that has never been audited is decoration. If the person who proposed it cannot tell you where it fails, they have not finished thinking about it.

Four places where the mapping in Chapter 4 does not hold. Two of them are limitations you should know about before you build; two of them are inversions, where the agentic version runs backwards from the hardware version — and those are the ones worth the reading time, because an inversion tells you something a resemblance never can.

Break 1 — the handler row does not preempt

A hardware interrupt stops the processor mid-stream and runs the handler now. That immediacy is not a detail; it is the point of the mechanism.

A scheduled prompt does no such thing. From the documentation: “A scheduled prompt fires between your turns, not while Claude is mid-response. If Claude is busy when a task comes due, the prompt waits until the current turn ends.”¹²

So this is a cooperative, turn-boundary interrupt. It is much closer to a Unix signal than to a true interrupt service routine — and the comparison is exact, because signals work the same way: the kernel checks for a pending unblocked signal “whenever there is a transition from kernel-mode to user-mode execution”, which is to say at a safe boundary rather than mid-instruction.¹⁶

Break 2 — coalescing is a constraint here, not an optimisation

In hardware, coalescing is a deliberate choice with a known price. A device “waits for a bit before delivering the interrupt to the CPU. While waiting, other requests may soon complete, and thus multiple interrupts can be coalesced into a single interrupt delivery, thus lowering the overhead of interrupt processing. Of course, waiting too long will increase the latency of a request, a common trade-off in systems.”¹⁷

Here the same behaviour appears in the limitations section rather than the optimisations section: “No catch-up for missed fires. If a task’s scheduled time passes while Claude is busy on a long-running request, it fires once when Claude becomes idle, not once per missed interval.”¹²

Same observable behaviour, opposite intent. I am not going to claim the analogy predicted this, because it plainly did not — it predicted a deliberate optimisation and what shipped is an honest constraint. What the analogy does give you is the right response: you are getting coalescing whether you asked for it or not, so write a check-in that is idempotent and state-reading rather than incremental. Any prompt whose correctness depends on firing exactly n times is already wrong.

Break 3 — privilege inverts

This is the one that changed how I think about the whole architecture.

In hardware, an interrupt escalates. It enters the kernel. Vector numbers 0 through 31 are reserved by the architecture itself, and the non-maskable interrupt is deliberately beyond software’s reach: it “cannot be masked by the IF flag in the EFLAGS register.” The interrupt arrives with more authority than the code it interrupted. That is the design.

The agentic version does the opposite, explicitly and on purpose. A fired prompt “is not live user input and can’t act as approval or consent for actions during the run”, and any free text supplied with the fire “arrives wrapped in a <routine-fire-payload> block that labels it as untrusted data and tells Claude not to follow instructions inside it unless the routine’s own prompt says to.”⁵

That is not a bug in the analogy; it is a correct security decision that the analogy failed to anticipate, and the book is stronger for saying which way round that is. It also happens to be a principle I have been arguing from the other direction for some time. On the epistemic side: the wiki grounds action; it cannot authorise it — understanding is an epistemic achievement, permission is a governance achievement. And more bluntly: activation improves cognition, and it does not mint authority.

Delivery is a mechanism. Authority is a layer. Keeping them separate is what stops a scheduled prompt becoming a way to smuggle consent into a system at three in the morning when nobody is watching.

Break 4 — transparency inverts, and that is where the power comes from

The sharpest structural failure is also the most illuminating. Operating systems want traps to be invisible:

Typically whatever code was executing at the time of the trap will later need to resume, and shouldn’t need to be aware that anything special happened. That is, we often want traps to be transparent; this is particularly important for device interrupts, which the interrupted code typically doesn’t expect.

A prompt-interrupt is the exact opposite, and not marginally. Its entire value is that the agent notices it, reasons about it, and may abandon its current plan because of it. Transparency would not degrade the mechanism; it would destroy it.

So the analogy’s most fundamental design goal runs backwards. I think that is the single most useful thing in this chapter, because it tells you what the agentic version is actually for. Hardware interrupts exist to service a condition without disturbing the program. Prompt interrupts exist to disturb the program. They are the same mechanism aimed at opposite ends.

The rows that hold

Four of them, briskly, because a chapter of nothing but failures would be its own kind of dishonesty.

Interrupts are not automatically the right answer

The operating-systems literature is blunt about this in a way the agent literature is not, and it is worth quoting against my own thesis rather than around it: “if a device is fast, it may be best to poll; if it is slow, interrupts, which allow overlap, are best.” And the failure mode: “There are also cases where a flood of interrupts may overload a system and lead it to livelock; in such cases, polling provides more control to the OS in its scheduling and thus is again useful.”¹⁷

Timers, events, and why the thesis survives the next feature

One last distinction, because it protects the argument from obsolescence.

A timer-driven prompt is a timer interrupt: the process wakes on a clock and looks around. That is not the only kind of interrupt a computer has, and it is no longer the only kind an agent has either. Event-pushed delivery now exists, and the documentation describes it in language that could have been lifted from Chapter 3: “Unlike integrations that spawn a fresh cloud session or wait to be polled, the event arrives in the session you already have open”, so that a webhook from CI or an error tracker “arrives where Claude already has your files open and remembers what you were debugging.”¹⁸

The point for this book is a structural one: destination is orthogonal to trigger. A clock and a webhook can both land in the same live process, and both inherit the same advantage for the same reason. This is an argument about where, not when — which is why it should still hold after the next scheduling feature ships.

What survives

What the analogy is for is not the claim that agents are computers. It is that latency, masking, re-entrancy, privilege, coalescing and handler cost all became askable questions about your scheduler, and they were not askable before. That is the test of a vocabulary: does it generate questions, or only resemblance?

This one generated six. Two of the answers I did not like, and they are in the chapter.

Nothing in this book says keep everything in the conversation.

If that is what you have taken from it so far, you are about to build something that loses a night’s work and looks completely fine while it does. So let me put the correction in the first paragraph rather than the last: there are two loops here, not one, and they do different jobs. Confusing them is the failure mode that this chapter exists to prevent.

The warm cognitive loop

Same-session persistence retains a specific and rather short list: situational awareness, unresolved lines of reasoning, awareness of active subagents, knowledge of recently executed commands, and the narrative of why the current approach was chosen over the ones that were abandoned.

That last one is the item nobody writes down and everybody needs. Rejected options are the most expensive knowledge in any piece of work and the least likely to be documented, because at the moment you reject something it feels self-evidently wrong rather than usefully informative.

The durable operating loop

External state — Markdown, Git, the database, the wiki — survives a longer list: context compaction, session death, machine restart, model replacement, a fresh operator taking over, and one more that people forget to include:

corruption of the active conversation’s own self-assessment.

Notice what that last item does to the category. If durable state only survived crashes, it would be a backup. Because it also survives the conversation being confidently wrong about itself, it is something else: a check. Those are different design objects with different requirements, and only the second one is worth building carefully.

The conversation preserves the active gestalt; the files preserve the truth.

The transcript that looks durable

There is a specific way to get this wrong and it is common enough that it deserves its own warning. I have described it before, in the context of loops rather than schedulers, and the phrasing is the sharpest I have managed: a loop whose state lives in a chat transcript is rung one wearing rung three’s clothes. It looks external because it is on a screen and it is written down — and it dies with the session, or gets compacted into vagueness without anyone being told.

Which is why the sentence I keep returning to is not about conversations at all: the agent is not the system of record. The system of record is the thing still true after the session dies.

Warm is not automatically good

This is the point in the book where the external research is least convenient for my thesis, so it goes here rather than nowhere.

Long unattended runs derail, and they do not derail for the reason people assume. A benchmark of multi-million-token agent runs reports that models “have runs that derail, either through misinterpreting delivery schedules, forgetting orders, or descending into tangential ‘meltdown’ loops from which they rarely recover” — and then the finding that matters: “We find no clear correlation between failures and the point at which the model’s context window becomes full, suggesting that these breakdowns do not stem from memory limits.”²⁰

Multi-turn degradation has been measured directly, and the phrasing is unforgiving: “when LLMs take a wrong turn in a conversation, they get lost and do not recover”, with the drop decomposing into “a minor loss in aptitude and a significant increase in unreliability.”²¹

And a run can poison itself: per-step accuracy degrades as steps accumulate, and “models become more likely to make mistakes when the context contains their errors from prior turns.”²²

Read together, those three findings kill a version of this book’s argument — just not the version I am making. They kill “keep it warm and it will be fine.” They also kill the popular alternative, “give it a bigger window”, since the failures are not correlated with running out of one.

The interrupt has to point outward. That is the whole design consequence of the research, and it is worth more than any amount of enthusiasm about warm context.

The shape of the whole thing

So the architecture is not cron → live conversation. It is six rungs, and this book argues the top four.

The objection I am not going to answer

The division of labour, as a design rule

The cron wakes the first loop. The first loop must keep consulting and updating the second. Neither half is optional and neither half can be asked to do the other’s job: the conversation is excellent working memory and a terrible system of record, and the files are an excellent system of record and hopeless at holding an unresolved line of reasoning.

Which collapses to one testable rule:

Anyone selling you only the warm half is selling you a story about almost.

If you have read my earlier work on long-running agents, you have been holding an objection since about Chapter 3, and you are entitled to be slightly annoyed that it has taken this long to address. So let me put it in your words rather than mine:

You have spent this whole book arguing that a warm, accumulated session is the point. You previously argued that accumulated context is the enemy and that the whole trick is to make the workers stateless. Which is it?

The contradiction, at full strength

I am going to state the earlier position properly, because a reconciliation is only worth anything if the contradiction was real. Softening my own prior argument to make this chapter easier would be the cheapest trick in the book.

Here is what I wrote. Long-running agents need stateless workers with external state — the counter-intuitive claim being that each agent invocation starts fresh, with no memory of previous tasks in context. The architecture is a stateful Router or Kernel that tracks workflow progress, maintains the task queue, persists compressed learning and orchestrates; sitting above stateless Agent Workers that start fresh each time, receive only task context, execute a discrete step, return a result and terminate as their context evaporates.

And the reason given was blunt: stateful agents drown. Memory accumulates across tasks, context fills with historical cruft, signal gets buried under verbose history, and quality degrades predictably.

That is not a soft position, and this book appears to contradict every line of it.

The move

It doesn’t, and the resolution takes one sentence.

These are claims about different components. Nothing in this book argues for warm workers. The workers stay disposable, cold, single-purpose and forgettable, exactly as before. The thing being interrupted is the thing that holds the queue, the progress, the compressed learning and the definition of done — and that thing was specified as stateful in the original architecture. It is not an exception to the earlier design. It is the earlier design.

Why this completes the earlier architecture rather than reversing it

Read the two pieces side by side and there is a gap in the older one that I did not notice at the time. It specified a stateful kernel — what it holds, what it tracks, how it dispatches — and was entirely silent on one question:

How does anything outside reach it?

A kernel with no inbound channel can only be started, never redirected. You can boot it with a goal and you can read its output afterwards, and in between it is sealed. Every intervention has to be anticipated at launch, which is the same foreseeability tax Chapter 2 identified in cron, relocated one layer up.

The scheduled prompt is that channel. Read this way, Prompt-Interrupt Architecture is the missing input edge of an architecture I had already published — which is a smaller and more defensible claim than announcing a new one, and I would rather make the smaller claim.

What falls out of the reconciliation

Four consequences, and each is a design rule rather than a debating point.

Context hygiene still applies — now to the kernel

Everything the earlier work said about accumulation still holds, and it holds for the interrupted session. A kernel that hoards degrades exactly as predicted, and the effect is measurable: models “become more likely to make mistakes when the context contains their errors from prior turns.”²²

So the interrupt’s job is to push detail out to the journal, not to accumulate it in the conversation. A check-in that writes an entry and then lets go is doing it right. A check-in that summarises its findings back into the conversation for later reference is quietly rebuilding the failure mode the whole architecture exists to avoid — and it will feel helpful right up until hour six.

The exit condition is not a new idea

The mapping table’s exit-condition row is borrowed, not invented. It is the earlier work’s explicit completion criteria: not “feels done” but objective, verifiable conditions, because agents naturally want to stop — they reach a reasonable stopping point, feel done, and terminate, and breaking a long run requires infrastructure that says no, you are not done yet.

Subagents are the workers, and they stay cold

Nothing here argues for warm subagents. The architecture is one warm kernel and a stream of cold hands. If you find yourself keeping subagents alive so they retain context, you have applied this book to the wrong component and you will get the drowning failure the earlier work warned about, at a smaller scale and in more places.

Fragility is honest behaviour, not a defect

Session-scoped scheduling has a limitation that reads at first like a dealbreaker: “Tasks only fire while Claude Code is running and idle. Closing the terminal or letting the session exit stops them firing”, and “Starting a fresh conversation clears all session-scoped tasks.”¹²

Myth and reality

The corollary nobody likes

If the kernel is the thing being interrupted, then the quality of your kernel — not the quality of your prompt — sets the ceiling on what a scheduled prompt can achieve.

A session that has been kept clean, that knows its queue and its done-test, that has been pushing detail out to the journal all evening, converts three lines of English into supervision. A session that is a soup of half-finished threads, abandoned tangents and stale assumptions converts the identical three lines into noise — and then you go and tune the prompt, because the prompt is the thing you can see.

That is the diagnosis I would most like readers to take from this chapter. When the check-in stops producing useful behaviour, the prompt is almost never the problem.

Six artefacts, one running system, and a deliberate omission that I want to explain before I start rather than have you notice halfway through.

This chapter describes a design. It does not narrate a night, quote a live log, or report a failure. That is a choice, and the reasoning is short: a design you can hand someone is worth more than a confession they cannot act on. Incident stories are entertaining and they transfer almost nothing — the reader gets a feeling rather than a structure. Every log line below is constructed for the page and labelled as such. What is real is the shape.

The artefacts

Silence is failure, not success

The watchdog point deserves its own paragraph because the direction of the contract is the thing people get backwards. Here is how it works in the kernel:

A userspace daemon will notify the kernel watchdog driver via the /dev/watchdog special device file that userspace is still alive, at regular intervals… If userspace fails (RAM error, kernel bug, whatever), the notifications cease to occur, and the hardware watchdog will reset the system.

The supervised party must actively prove life. Nobody asks it how it is going; it has to keep saying so, and stopping is the signal. Build the agent version the other way round — alert when something reports a problem — and a dead session looks exactly like a quiet successful one until morning.

The shape of a shift-log entry

## 02:30 — check-in 7
State: step 4 of 6. Ingest running since 01:55, row count moving.
Next: verify the checksum job started; if not, restart it (charter: restart allowed).

Illustrative only. Three lines: a time, a state, a next action. Its job is to show the shape, and nothing here is drawn from a real run.

That is the entire format. It is deliberately unambitious, because the value is not in any single entry — it is in the comparison between consecutive ones. Three entries that say the same thing are visible in a way that three hours are not.

None of this is a novel data structure. Append-only execution history is the standard industry answer to the same class of problem: “By keeping a history of every step in your Workflow, it ensures that even if something goes wrong your Workflow can continue from the last successful point.”²³ The only thing that is different here is what gets journalled: an agent’s reasoning state rather than a workflow’s control flow.

What used to be discipline is now a tool

Here is the beat that makes this more than a tour of my own folder, and it is an observation rather than a claim about anybody’s intent.

Two of those six artefacts used to be habits you installed by hand and remembered to remove. They are now tools the agent holds. Scheduled tasks each carry “an 8-character ID you can pass to CronDelete”, with CronCreate and CronList alongside it; in self-paced mode “Claude can also end the loop on its own once the task is complete. Claude calls the ScheduleWakeup tool with stop: true, which cancels the pending wakeup immediately”; and a forgotten loop is bounded anyway, since recurring tasks expire after seven days — “The task fires one final time, then deletes itself.”¹²

I want to be careful about how much weight that carries. It says nothing about anyone’s plans and I am not going to pretend it does. What it is, is evidence that the pattern was real rather than a local habit — the kind of evidence you cannot manufacture by arguing.

The honest limit

None of this makes the run correct.

A charter does not stop the agent misjudging. An append-only journal does not stop it writing three confident entries about progress that is not happening. A dead-man’s switch only tells you that something stopped, not whether what happened before it stopped was any good. Everything in this chapter is machinery for one property, and it is worth naming precisely because it is smaller than what people hope for:

That is a modest claim and I would rather make it than a bigger one that does not survive a bad night.

In Ask Yourself If You’re Finished: Cron as the Poor Man’s Orchestrator, I laid out the implementation options for an overnight heartbeat and treated them as interchangeable: “a host cron that re-invokes the session, a scheduler the coding agent can write and later remove, a self-job that fires a structured ‘status / done? / next’ message into the same conversation.” And then the line that this entire book exists to correct:

The shape matters more than the brand of timer.

That is wrong. Those three options are not interchangeable. Two of them boot a stranger; one of them interrupts the process that already knows. The difference is not an implementation detail sitting underneath a shared shape — it is the whole difference, and everything in Chapters 2 to 7 is the argument for why.

Why the correction is fair rather than embarrassing

At the time, same-session delivery was a hypothetical. It was a thing you might rig up if your environment happened to allow it — one plausible way to get a timer to poke a session. Treating it as one option among three was a reasonable read of a landscape where none of it was documented.

It is now a documented primitive with delivery semantics, a tool surface, an expiry policy and a product-comparison row. The claim was defensible when it was made and it is not defensible now. That is what a correction is for, and a framework family that never publishes one is not being careful — it is being unfalsifiable.

The genealogy was always honest about which came first, as it happens. The practice was documented before the mechanism was understood: I’d already documented my shift cron. What I’m saying now is what made it work: it executes prompts and Markdown files instead of code. Practice first, mechanism second — and then the mechanism turns around and revises the practice. That order is normal. Pretending the earlier piece had meant this all along would not be.

The parent also left the door open

There is a second reason this book is not a rival to that one. The earlier piece fenced this territory off explicitly: “It is deliberately not a tour of orchestration-kernel design, and it is not a checkpoint-format standard. Those topics matter for larger systems; they are out of scope here on purpose.”

The architectural account was left unwritten on purpose. This is it. Not a replacement for the field recipe — go and install the field recipe, it works — but the chapter the parent declined to write, plus the correction that writing it forced.

The family, and the axis this one adds

Six pieces, one clause each. The links do the rest.

• Markdown as an Operating System explains what the agent executes: editable natural-language operating artefacts.
• Designing Loops, Not Prompts explains the trigger, and asks who holds the state machine.
• Cron as the Poor Man’s Orchestrator provides the external liveness mechanism.
• Handover Notes for Robots provides operational state, stuck detection and succession.
• Breaking the 1-Hour Barrier provides the stateless-worker, stateful-kernel architecture.
• Prompt-Interrupt Architecture now explains how the scheduler re-enters the agent’s cognition.

Space and time

Here is the structural claim, and it is the reason I think this belongs in the family rather than beside it.

Markdown OS makes an operating-system argument that is entirely spatial. An agent is a folder. AGENT.md, /specs/, /plans/, /state/, /runs/, /reports/ are all places. Git is the audit trail of what changed in those places. Every noun in that framework is a location, and the whole thing hangs off one inversion: your operating system runs on binaries; your AI agents should run on Markdown.

What it does not have — anywhere — is a process, a scheduler, or an interrupt. There is no time axis in it at all.

The missing edge

There is one more piece of the lineage, and it is the smallest contribution in the book, which is exactly why I trust it.

The cron piece split the world into three layers — Cognition (the ephemeral model session, its tools and subagents), Liveness (the external, self-deleting wake-up), and Memory (Git, Postgres, the wiki, the files the next session can open) — and observed, correctly, that people collapse the three into one and then wonder why orchestration got complicated.

What it never said is how Liveness reaches Cognition. The two layers sat next to each other on the page with nothing drawn between them.

Liveness is delivered as language into cognition.

That is an edge, not a layer. It adds nothing new to a diagram that was already correct; it names the line between two boxes that were already drawn. I think a framework family that grows by adding edges is healthier than one that grows by announcing a new layer every quarter, and I would rather this piece be judged as the former.

Two doors, and then the test

Two neighbours are worth naming without developing, because both of them sharpen something this book only gestured at. The first is the argument that the parent intent is the durable unit of work while the queries and probes underneath it are disposable — the same instinct as “the scheduler carries intent”, one layer down in the retrieval stack. The second is where the learning from a long run gets filed, so that a loop compounds rather than merely staying alive — an agent that survives the night without leaving anything behind has been kept alive, not made useful.

What a framework family should be is diffable. You should be able to see what each piece added, what it borrowed, and where a later piece corrected an earlier one — which is the same property this book demands of an agent’s shift log, applied to its author. Chapter 8 asks the machine to leave a trail clear enough that the next operator can see where it went wrong. It would be a strange doctrine that exempted the person writing it.

Doctrine that ends in agreement has failed. So here is the smallest possible thing to do with all of this, and it starts with two questions about a scheduler you already have running.

Five things, in dependency order

1. Make the session addressable, and record the identifier somewhere that is not the session. An ID that only exists inside the thing it identifies is not an ID.
2. Move the definition of done out of the prompt and into a file the next process can open. Until you do, only the conversation can tell you whether the conversation is finished.
3. Rewrite one scheduled command as a scheduled question. This is the step that produces the demonstration. Everything else on this list is scaffolding that makes it safe.
4. Put the journal outside the conversation before you trust the conversation. Append-only, one entry per wake, readable by something that is not the agent.
5. Give the timer a way to remove itself. A heartbeat with no exit is a new failure mode wearing the old one’s clothes.

Why sooner rather than later

There is a version of this you can defer until the next quarter, and there is evidence that deferring it is the wrong call.

A trajectory study of CLI coding agents annotated 1,794 complete execution trajectories — seven frontier models, three agent scaffolds, over 63,000 execution steps — specifically to treat failure as a temporal process rather than a final outcome. The finding:

coding-agent failures are predominantly driven by epistemic errors, typically begin within the first few execution steps, and often remain hidden until recovery is no longer possible, suggesting that improving coding-agent reliability requires earlier validation and intervention rather than relying solely on final-outcome evaluation.

That is close to a peer-reviewed restatement of this book’s thesis, from people with no stake in it. Be careful about how far you carry it — it is a finding about coding agents on a specific benchmark, and it is about when failures start rather than about scheduled prompts. But the consequence for design is unambiguous.

What you may conclude, and what you may not

You may conclude that the destination sets the ceiling on what a scheduled prompt can do. Everything above that ceiling is unavailable no matter how well the prompt is written, and everything below it is available with a prompt that is three lines long.

You may not conclude that the loop supervises itself. A warm session grading its own homework is an unresolved problem, and eleven chapters of honesty would be wasted by a triumphant ending. Chapter 8 named the shape of the answer and handed the argument on. Take it seriously before you leave one of these running unattended over something that matters.

Rediscovering Unix, again

None of the mechanism here is new. Operating systems solved this problem with exactly this move, decades ago:

A timer device can be programmed to raise an interrupt every so many milliseconds; when the interrupt is raised, the currently running process is halted, and a pre-configured interrupt handler in the OS runs. At this point, the OS has regained control of the CPU, and thus can do what it pleases.

And the reason it exists is the reason your agent needs one: the mechanism regains control “even if processes act in a non-cooperative fashion.”

An agent absorbed in a subtask is non-cooperative in precisely that technical sense — not stubborn, just lacking any mechanism that would cause it to stop and look up. It will not interrupt itself.

Which makes a line from the parent piece read less like a joke and more like a prediction: elaborate harnesses often rediscover Unix — a timer, a question, a file that still exists in the morning. This book’s only amendment is that one of those three turned out to be load-bearing in a way the other two are not, and it was the question — because of where it gets asked.

The deeper reason

In 1985, Peter Naur argued that the essential thing about a program is its theory, and that the theory “is something that could not conceivably be expressed, but is inextricably bound to human beings.” From which follows the line that has stayed with me longer than anything else in this book’s research:

The death of a program happens when the programmer team possessing its theory is dissolved.

Naur also dispatched the obvious rejoinder in advance. For a newcomer to acquire the theory, “it is insufficient that he or she has the opportunity to become familiar with the program text and other documentation.”²⁵ Better notes are not a solution to this problem; they are a mitigation of it, and the measurements in Chapter 3 are what the mitigation costs.

Every time you kill an agent session and let a scheduler start a fresh one against the same repository, you are staging that death and then asking a stranger to finish the work. The stranger is capable. The stranger has the files. The stranger does not have the theory, and no amount of handover writing will fully supply it — which is precisely why the warm session and the durable files are both required, and neither is sufficient alone.

The shape worth keeping

Which brings the book back to the puzzle it opened with. Two identical cron lines, three lines each, and only one of them appearing to supervise anything. Not because the surviving one was cleverer. Not because it was tuned, or scheduled better, or written by someone who understood prompting.

Because of where it landed.

The intelligence is not encoded in the cron. The cron merely restores the whole intelligent operating environment to agency at the right moment.