The Heartbeat Is a Supervisory Program

Schedulers that carry intent instead of implementation stop needing new logic for every new job — because the code has moved below the prompt boundary.

Scott Farrell · LeverageAI · July 2026

Here are two half-hourly jobs. Same cadence. Completely different lifetimes.

Command-shaped scheduler

every 30 minutes:
  run script A
  check PID B
  restart service C
  invoke test D

Intent-shaped scheduler

every 30 minutes:
  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.

The first one is a miniature orchestration system. Change the job — a batch import becomes a multi-repo refactor becomes a long research run — and you rewrite the timer. The second one is a supervisory policy. Change the job and the same text still fits, because it never named the implementation.

So here is the question this piece answers: how do you write a scheduled prompt that keeps working as the job changes under it?

Not where the prompt lands — that is a different axis, and I have already argued it in The Prompt Is the Interrupt. This piece is about the payload: what the wake says once it has arrived.

The inversion: intent instead of implementation

A traditional scheduler has to know the implementation. That creates hard-coded orchestration. Every new kind of work requires new scheduler logic.

A prompt scheduler can instead state an intention: review the goal, judge whether progress is real, act inside known limits, finish only when the done criteria are met, and tear the timer down when they are. The agent translates that intention into whichever actions fit this wake — inspect a process, read a subagent's output, rerun a command, repair a file, change strategy, or decide the job has passed its gates.

The scheduler carries intent, not implementation.

Code has not disappeared. It has moved below the prompt boundary. The scheduler executes an intention. The agent decides which code, tools and actions realise it.

That boundary is familiar if you already treat the human-owned prompt package as source and generated code as intermediate representation at build time. The same line moves into scheduled execution: policy above, tool choice below. The durable thing is the supervisory paragraph — not the shell one-liner you would have hard-coded last Tuesday.

Public products already ship this shape. OpenAI documents scheduled tasks as work that runs from a prompt, optionally combined with skills, on a cadence you choose — instructions on a schedule, not a scheduled executable.¹ Their own guidance is blunt about what that prompt must be: make it durable; say what to do on each run, how to decide whether anything is worth reporting, and when to stop.¹ That is not a product tour. It is the vendor admitting the payload is the program.

What language carries that a bare wake cannot

A bare timer only says “you are awake again.” Language can carry a whole supervisory layer:

• Operational policy — how this class of job is supposed to behave when nobody is watching.
• Authority limits — what this wake may restart, fix, rewrite, or escalate.
• Current priorities — what matters first when several threads are alive.
• Recovery instructions — what to try when progress looks false, and when to stop trying.
• Completion criteria — what “done” means in checkable terms, not mood.
• Inspect subagents — do not trust the main narrative alone; look at delegated work.
• Change method — if progress is theatre, abandon the current approach inside your authority.
• Update the journal — leave a durable note a cold successor can read.
• Remove the timer — when the job is genuinely finished, delete the wake so success does not become eternal polling.

A wake signal without that content is a doorbell. A wake signal with that content is a supervisory program written in English.

I have already published the three-question field recipe — how are you going, are you actually finished, what is next — and the self-deleting heartbeat that asks them. Ask Yourself If You're Finished gives you the install. This piece is the reason that recipe travels: question-shaped payload generalises where command-shaped payload cannot.

The artefact: a heartbeat charter (illustrative)

Here is the shape worth copying. It is an illustrative example — a toy supervisory program for a generic long job — not a transcript of any live run, and not a real operations log.

# HEARTBEAT CHARTER — illustrative example only
# Job class: long-running batch / agent job under human definition of done

## Authority tier
You may, without asking:
  - re-run failed steps that already appear in the plan
  - restart a hung worker process up to twice
  - edit files inside the job worktree to clear blocked progress
  - update the job journal after each meaningful action

You may NOT, without escalating to a human:
  - change the definition of done
  - push to shared main / production
  - spend beyond the stated cost or time budget
  - delete data outside the job worktree

## Out of bounds
- No production deploys
- No credential or secret rotation
- No “done” claim based only on your own confidence

## Priorities (this wake)
1. Is the main goal still the active goal?
2. Is delegated work making real progress, or only producing text?
3. Clear stalls inside authority; otherwise escalate and stop.

## Recovery
If a step failed the same way twice: change method or escalate.
If a subagent report is vague: inspect its artefacts yourself.
If you cannot tell whether progress is real: write that uncertainty in the journal.

## Completion criteria
The job is finished only when:
  - every item on the written done-list is evidenced in files or logs, and
  - a verification command you name in the journal has passed.

## Self-removal
When completion criteria are met, remove this scheduled check.
If you are blocked outside your authority, pause work, journal the block, leave the timer
running only if a human may still clear the block; otherwise escalate and stop.

That is not a script for one workflow. It is a policy surface. The same surface can supervise different work because the methods live under it.

Same unedited prompt, three different jobs

Minimum proof for the idea is simple: one heartbeat text, three materially different job types, different actions on each wake — without editing the timer. The following is again illustrative, not a claim about a measured production corpus.

Nothing in the charter named pytest, a migration script, or a search tool. The agent chose those below the prompt boundary. That is the scheduler logic you get to delete: the per-job branch table that used to live in the timer.

Before — orchestration in the scheduler

if job == tests: run pytest; restart runner; ...
if job == migrate: run convert.py; check counts; ...
if job == research: run search; merge notes; ...

After — orchestration below the prompt

# one intent charter (priorities, authority, recovery, done, self-removal)
# agent selects tools per wake from the live situation

You did not remove engineering. You relocated it to the only place that can see the current process table, the current files, and the current subagents: the agent session the wake addresses.

Authority limits, recovery, and self-removal

Three clauses do most of the honesty work inside the payload.

Authority limits answer “what may this wake do alone?” Without them, intent collapses into either paralysis or free rein. Prose limits are weaker than a deterministic gate — say that out loud. For client work and regulated environments, promote the same limits into a graduated-authority charter with teeth, the artefact I describe in Handover Notes for Robots. The point here is smaller: even a short English fence belongs inside the heartbeat, not only in a wiki page nobody injects at wake time.

Recovery instructions answer “what if progress is false?” A command-shaped timer restarts the same PID. An intent-shaped timer can say: if the same failure repeats twice, change method; if a subagent is vague, inspect its artefacts; if you cannot tell, write the uncertainty down. That is how you stop the schedule from reinforcing a stuck approach.

Self-removal answers “what breaks without an end?” A timer that never dies turns finished work into eternal polling, burns budget, and teaches the system that completion is optional. The completion criteria and the delete clause are a pair. Done is not a vibe; done is a checkable gate plus the instruction to tear the wake down when the gate passes.

When intent is too vague

The failure case that keeps this honest: an intention too soft to act on.

# Too vague — illustrative anti-pattern
Keep things moving.
Make sure it's going okay.
Finish up when it feels done.

What does an agent do with that? It narrates. It confabulates progress. It treats “feels done” as permission. The payload did not supply a priority order, an authority fence, a recovery rule, or a completion test — so the agent invents them, inconsistently, every half hour.

The cut is the same as in north-star prompting. Hold each line and ask: if the model ignored this, would the result be wrong, or merely not how I pictured it? Keep the lines that define wrong. Cut the ones that only encode preference. What remains is a short fence — and a heartbeat that can supervise without micromanaging.

Read it, version it, critique it like a program

Once you see the heartbeat as a supervisory program, the review discipline writes itself.

• Diff it. Store the charter in git. When you widen authority or loosen completion, the diff is the change set — not a silent edit in a GUI field.
• Review it. Ask a second human (or a fresh-context agent that only sees the charter and the journal template) whether the fence is short enough and the done test is real.
• Critique it after a job. Did the agent need methods the charter forbade? Did it stop too early because completion was mushy? Promote those lessons into the next version of the paragraph — not into a new shell script per job type.

That is Markdown-as-operating-surface taken seriously at the timer: plain language that is greppable, diffable, and editable mid-operation. The intelligence is not encoded in the cron. The cron restores agency. The paragraph is what steers that agency without hard-coding the work.

What this piece is not

It is not the argument that delivery into a live session is the breakthrough — that is the destination axis in The Prompt Is the Interrupt. Payload and destination are independent: an instructions-plus-skills schedule can exist without a persistent live process; a hard-coded command injected into a live session has destination without this kind of payload.

It is not the argument that same-session supervision is trustworthy. A warm loop can preserve a wrong story as efficiently as a right one. That failure mode is a separate article.

It is not a vendor scorecard. OpenAI is named here only because public docs already define scheduled work as prompt-shaped instructions — the payload claim in product form.¹ Other coding agents that can schedule prompts into a live session make the same shape available; the writing discipline does not depend on a brand.

Write one

Take the next long job you would otherwise babysit. Do not write a per-step cron. Write a short supervisory program:

1. Priorities for each wake.
2. Authority limits — restart, fix, rewrite, escalate.
3. Recovery when progress is false.
4. Completion criteria that can be evidenced.
5. Journal instruction.
6. Self-removal when done.

Schedule that paragraph. Leave the method to the agent. When the job class changes, edit the paragraph — not a tree of scripts.

The heartbeat is a tiny, diffable, reviewable supervisory program. Read it, version it, and critique it like one.

That is how a scheduled prompt keeps working as the job changes under it: the timer stops carrying implementation, and starts carrying intent that stays true while the work below it moves.

Related: The Prompt Is the Interrupt (destination) · Cron as the Poor Man's Orchestrator (field recipe) · The North Star Prompt (tight intent / loose method) · Handover Notes for Robots (graduated authority).