The Prompt Is the Interrupt

Prompt-Interrupt Architecture: why a three-line scheduled prompt can make a coding agent supervise itself, and the same three lines in Unix cron cannot. The difference is not the timer. It is where the prompt lands.

Scott Farrell · LeverageAI · July 2026

Here are two scheduled jobs. Same interval. Same words. Three lines each.

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 process on one wake, read a subagent's output on the next, and change strategy 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 piece answers: 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?

It is not the model. The same model, handed the same words in a fresh process, does nothing useful. It is not the cadence — thirty minutes is cost control, and I have written about that already.¹⁷ It is not prompt engineering; the prompt is three lines and never changes. And it is not a bigger harness, because the field fix here has always been smaller than a product roadmap, not larger.

It is the destination. One of those jobs starts a process. The other reaches one. That distinction does not appear as a field in any scheduler's configuration form, which is exactly why it stays invisible.

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

I want to name that mechanism, because it does not have a name yet, and because the name it deserves explains everything else about it: Prompt-Interrupt Architecture.

What the cold process cannot see

Start with cron, and give it credit. Cron is not broken. It is doing precisely what it was specified to do, and it has been doing it since 1979, when 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.

The environment that string lands in is constructed, not inherited. POSIX is explicit: the values of the caller's environment variables "shall not affect the default values provided when the scheduled command is run."¹⁰ The scheduled command gets a supplied default — a shell, a home directory, a login name, a path — and nothing else. The only channel back is mail to a human, after the fact.

Everything a cron job needs must therefore be re-passed, re-derived, or re-read from disk. Which means the person writing the cron line has to know the implementation in advance. A scheduled command can only ever do what was foreseeable at authoring time:

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. A scheduler that has to know the implementation is a scheduler you will be rewriting forever.

Now hand the supervision job to that cold process and list what it cannot do. It cannot inspect the subagent, because it never launched one and has no handle on it. It cannot rerun "the command", because it does not know which command. It cannot tell a slow step from a hung one, having no memory of how long the step has been slow. It cannot know that four of five approaches were already tried and abandoned. And it cannot evaluate "done", because its definition of done is whatever somebody typed in advance.

My own prior work has the cleanest statement of the underlying problem: 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, restarts at step one and does not tell you.

The most useful confirmation of this comes from a vendor documenting its own cloud-side alternative. Anthropic's Routines run scheduled Claude Code sessions on managed infrastructure, and the documentation is candid about what that costs: "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." Consequently, "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 argument, conceded in a docs page.

The working gestalt

Now the other side. What is actually present at the moment a prompt lands in a live session?

Not "context" as a vague noun. Eight inspectable things:

• the original goal;
• the conversation and decisions so far;
• commands it has run;
• files it has inspected or changed;
• processes currently running;
• subagents it launched;
• errors and discoveries;
• the intended definition of done.

Read that list again as a list of affordances rather than memories. A running process means the agent can inspect it. A launched subagent means it can question it. A discovered error means it can decide the error is now the priority. None of it has to be reconstructed or passed in. Reconstruction cost is the hidden tax on every stateless design, and here it is zero.

It can look at the current conversation, and the commands, and any subagents running. It can interrogate the whole environment.

Interrogate — not read. That is the difference between a transcript and a process.

There is one thing the live session conspicuously does not have, and it is worth being precise about it because it explains why the interrupt has to be external. The 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 called that temporal blindness, and the defining symptom is that it does not know it is stuck.¹⁸

So the division of labour is exact. The scheduler contributes time. The process contributes everything else. That is why the timer can be the dumbest component in the stack — it only has to supply the one faculty the process lacks.

The prompt is the interrupt

Once you see delivery-into-a-live-process as the mechanism, the operating-system vocabulary stops being a metaphor and starts being useful.

The row that does the most work is the handler. In a computer, an interrupt handler is a piece of code somebody wrote in advance. Here there is no handler to write: the agent's reasoning over its own current state is the handler. That is the entire reason a three-line prompt can behave differently on every fire.

And the analogy is stronger than it looks, because the formal definition of an interrupt already contains the property this piece is arguing for. Intel's own architecture manual: on an interrupt, "the currently running procedure or task is suspended while the processor executes an interrupt or exception handler", and afterwards "the processor resumes execution of the interrupted procedure or task ... without loss of program continuity."⁶

Suspended and resumed, not restarted. That is exactly the property a scheduled prompt into a live session has, and exactly the property a cron-launched command does not.

A plainer name was available — Scheduled Conversational Re-entry — and it is perfectly accurate. I rejected it because it describes the event and generates nothing else. "Prompt Interrupt" generates the whole table, and a name that keeps producing structure after you stop thinking about it is doing more work than a name that merely labels.

Where the code went

The table provokes an obvious objection. If the executable is a Markdown prompt, where did the code go?

It did not disappear. It moved below the prompt boundary.

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

And this is a consequence of destination, not a separate idea. Intent is only cheap where the situation is already present. Hand a cold process "resolve stalls within your authority" and it has no stalls, no authority, and no context in which either word means anything. Hand it to a process that launched the subagents and ran the commands, and every word resolves against something real.

This is the same geometry I have argued at build time, where the human-owned prompt package is the durable source and generated code is compiled output.²⁰ Build time: intent compiles to code. Schedule time: intent compiles to action. Same move, different clock — which makes the claim here smaller, and therefore more believable.

Addressability is the load-bearing primitive

The smallest word in the whole thesis is within. "Within a session" is what separates an interrupt from a boot, and it rests on something duller than any of it: the session needs a stable identity you can deliver to.

This is no longer theoretical. Claude Code documents "the cron scheduling tools to run prompts repeatedly ... within a Claude Code session", and is explicit that "Tasks are session-scoped: they live in the current conversation and stop when you start a new one."¹ The vendor's own comparison of its three scheduling options carries the thesis as a product row:

Requires open session: yes. That cell is the whole argument, priced as a product trade-off.¹

And the identity is real, not rhetorical. Sessions resume by name or UUID — --resume "Resume a specific session by ID or name", --session-id takes a valid UUID, and claude -r "auth-refactor" "Finish this PR" addresses a conversation the way kill addresses a PID.² Resumption even restores the unexpired scheduled tasks, which means process identity survives disconnection.

OpenAI has shipped the neighbouring primitive. Scheduled tasks in Codex/ChatGPT combine instructions with optional skills on a schedule, and can be created inside an existing chat: "The scheduled task uses the chat's existing context instead of starting from a new prompt each time."⁵

I want to correct something here rather than quietly widen a claim. The neat version of this argument says OpenAI has the payload without the live session. That is now too strong — a scheduled task can return to the same conversation. The sharper asymmetry is different, and it is in the same docs: web scheduled tasks "don't keep a local folder or worktree available between runs."⁵ Which strengthens the point rather than weakening it. The destination that matters is not a warm transcript. It is a live process, with files open and commands running.

Where the analogy breaks

An analogy that is never audited is decoration. So here are the places this one fails, named by the person proposing it.

The handler row breaks on preemption. A hardware interrupt stops the processor mid-stream and runs the handler now. A scheduled prompt does not: "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."¹ This is a cooperative, turn-boundary interrupt — closer to a signal delivered at a safe point than to a true ISR. It matters practically: the pathological case, an agent wedged inside one enormous tool call, is exactly the case the interrupt cannot reach.

Transparency inverts. In operating systems, traps are meant to be invisible: "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 precise opposite. Its entire value is that the agent notices it, reasons about it, and may change plan because of it. The mapping is stronger for admitting that the most important row runs backwards.

Privilege inverts too. A hardware interrupt escalates into the kernel. A scheduled prompt is deliberately demoted: a fired prompt "is not live user input and can't act as approval or consent for actions during the run", and free text supplied with a fire "arrives wrapped in a <routine-fire-payload> block that labels it as untrusted data."³ Waking a process is not the same as empowering it — which is the same boundary I have argued from the other direction: understanding is an epistemic achievement, permission is a governance achievement.²¹

And interrupts are not automatically the right answer. The operating-systems literature is blunt about it: "if a device is fast, it may be best to poll; if it is slow, interrupts, which allow overlap, are best", and "a flood of interrupts may overload a system and lead it to livelock."⁹ The agentic version of livelock is a session that spends all its time answering check-ins and none doing the work. Coalesce your check-ins; accept the latency you are buying.

What the analogy is for is not the claim that agents are computers. It is that latency, masking, re-entrancy, privilege and coalescing all become askable questions about your scheduler — and they were not askable before.

Warm is not the same as trustworthy

The obvious objection to all of this is that a warm session preserves its mistakes as faithfully as its insight, and the literature agrees. Multi-turn work degrades measurably: models "get lost" after an early wrong turn and "do not recover", with the degradation decomposing into "a minor loss in aptitude and a significant increase in unreliability."¹⁶ Long unattended runs derail in ways that are not context exhaustion — one benchmark of multi-million-token runs found "no clear correlation between failures and the point at which the model's context window becomes full."¹⁴

So the answer is not "keep everything in the conversation". It is two loops, not one:

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

The warm cognitive loop holds situational awareness, unresolved reasoning, knowledge of what is running and why this approach was chosen. The durable operating loop — the append-only journal, Git, the database, the wiki — survives compaction, session death, machine restart, model replacement, a fresh operator, and the conversation's own corrupted self-assessment. The agent is not the system of record. The system of record is the thing still true after the session dies.¹⁷

The failure mode to watch for is a loop whose state lives in a chat transcript. That is rung one wearing rung three's clothes: it looks external because it is written down on a screen, and it dies with the session.¹⁹

Whether a warm loop can be trusted to grade its own work is a genuine and separate question, with a known shape of answer — cheap warm check-ins, a rarer cold reviewer that reads only the journal, and a zero-AI watchdog on log staleness.¹⁸ I am not going to settle it here. It deserves its own piece, and this one is about where the prompt lands.

"But you argued for stateless workers"

A reader of my earlier work will have been holding an objection since the third section. I have argued that long-running agents need stateless workers with external state — a stateful router or kernel over disposable agents whose context evaporates on purpose.²² This piece appears to argue the opposite.

It does not, and the resolution is the most useful idea here. Those are claims about different components. The interrupt does not wake a worker. It wakes the kernel — and a kernel is supposed to be stateful. The workers stay disposable; the thing being interrupted is the thing that holds the queue, the progress and the compressed learning.

Read that way, Prompt-Interrupt Architecture completes the earlier architecture rather than reversing it. That piece specified a stateful kernel and never said how anything external reaches it. The scheduled prompt is the answer.

It also reframes what looks like fragility. Session-scoped scheduling stops when you close the terminal.¹ That is not a defect to route around; it is the honest behaviour of a process. Processes die. Which is why durable state lives outside them, and why resume-by-ID matters more than uptime.

The design, in artefacts

The pipeline that published this article runs the pattern, so let me describe the architecture — the shape of the artefacts, not the contents of any of them.

• A charter — one page stating what the unattended operator may restart, may debug and fix, and may rewrite. Graduated authority, written down before the night starts.¹⁸
• A run slate (RUN_SLATE.md) — the declared scope of the run and its definition of done. The executable row and the exit-condition row of the table, in one Markdown file the session interprets.
• An append-only shift log (SHIFT_LOG.md) — one entry per wake. This is the journal row, and it converts a capability the model lacks (feeling time pass) into one it excels at (comparing text): three entries that say the same thing are visible in a way that three hours are not.¹⁸
• A heartbeat — the scheduled prompt itself. The interrupt row.
• A dead-man's switch — a dumb external check on the log's modification time. Zero AI. Nothing watches the watcher unless you make it.¹⁸ Note the direction of the contract, which the Linux watchdog API gets right: the supervised party must actively prove life, and silence counts as failure.¹³
• A self-removing timer — the wake-up that cancels itself once the gates actually pass.¹⁷

Two of those used to be disciplines you installed by hand. They are now tools. The agent schedules and cancels its own wake-ups by ID (CronCreate, CronList, CronDelete); in self-paced mode it calls ScheduleWakeup with stop: true to end its own loop; and a seven-day expiry bounds a forgotten one.¹ The self-deleting heartbeat stopped being a recommendation and became an API — which is about the strongest evidence available that the pattern was real.

The design does not make the run correct. It makes the run inspectable, and inspectable is the precondition for everything else.

I was wrong about the brand of timer

This piece contradicts one of my own. In Cron as the Poor Man's Orchestrator I listed "a self-job that fires a structured status / done? / next message into the same conversation" as one implementation option among several, and concluded that "the shape matters more than the brand of timer."¹⁷

That is wrong, and I want to say so in print. Those options are not interchangeable. Two of them boot a stranger; one of them interrupts the process that already knows. The correction is fair rather than embarrassing, because at the time same-session delivery was a hypothetical implementation of a timer. It is now a documented primitive with delivery semantics, a tool surface and a product-comparison row. That same piece also fenced off the territory — "deliberately not a tour of orchestration-kernel design"¹⁷ — so the architectural account was left unwritten on purpose. This is it.

It also completes something. Markdown as an Operating System made an operating-system argument that was entirely spatial: an agent is a folder, every noun is a place, Git is the audit trail.²³ It has no process, no scheduler, no interrupt. This is the same metaphor along the time axis, which is why the family gains a component rather than a synonym. And it supplies a missing edge: I had already split the world into Cognition, Liveness and Memory¹⁷ without ever saying how liveness reaches cognition.

Liveness is delivered as language into cognition.

Two questions for your own scheduler

You can answer both in thirty seconds.

One: where does it land? When your scheduled job fires, does it start a process or reach one? If the answer involves a clone, a fresh environment, or a prompt that has to be self-contained, it starts one.

Two: can you name the destination? Does the session have an identity you can deliver to and resume by? If not, "within a session" is not available to you, and no amount of prompt craft substitutes for it.

Then, in order:

1. Make the session addressable, and record the identifier somewhere that is not the session.
2. Move the definition of done out of the prompt and into a file the next process can open.
3. Rewrite one scheduled command as a scheduled question.
4. Put the journal outside the conversation before you trust the conversation.
5. Give the timer a way to remove itself.

There is one more reason to do this sooner rather than later. A recent trajectory study of CLI coding agents found that failures "typically begin within the first few execution steps, and often remain hidden until recovery is no longer possible", concluding that reliability "requires earlier validation and intervention rather than relying solely on final-outcome evaluation."¹⁵ Mid-run interruption is not a convenience. It is the only place the intervention can still work.

And this is not a new discovery so much as a rediscovered one. Operating systems solved the same problem with the same move: "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." The reason given is the one that matters here — it lets the system "run again on a CPU even if processes act in a non-cooperative fashion."⁸ An agent absorbed in a subtask is non-cooperative in exactly that sense. It will not interrupt itself.

The shape worth keeping

Markdown is the executable. The conversation is the process. The scheduled prompt is the interrupt. Tools are the system calls. The shift log is the journal. Git and the wiki are durable memory. The closer is the kernel protection boundary.

Forty years ago Peter Naur argued that the essential thing about a program — its theory — "could not conceivably be expressed", and that "the death of a program happens when the programmer team possessing its theory is dissolved."¹² Every time you kill an agent session and let a cron job start a fresh one against the same repository, you are staging that death and then asking a stranger to finish the work. The documentation is never enough; Naur said so in 1985, and the empirical work agrees — in interrupted programming sessions, only about 10% resume editing within a minute, and roughly 30% take more than half an hour.²⁴

Which is the real reason the destination matters more than the timer. The intelligence is not encoded in the cron.

The cron merely restores the whole intelligent operating environment to agency at the right moment.

One thing to do: take a single scheduled command you already own and rewrite it as a scheduled question aimed at a session you can name. Then watch what it does differently on the second fire.