You set a long job running. Email into Postgres. Postgres into a wiki. A migration that should take the night. You tell the agent to be responsible for quality and to keep going until it is finished. You leave the room.

You come back to a terminal that thinks it is done — and it is not. Or a subagent that never came home. Or a shell script that hung while the parent session sat politely waiting for a process that would never speak again.

The failures are boring. That is the point. Nobody needs a novel failure mode to lose six hours of autonomous work. Premature “done” and stuck children will do it.

The industry response is often to reach for orchestration: graphs, kernels, platforms, frameworks with version numbers. Useful work exists in that territory — Breaking the 1-Hour Barrier is our own long-running-agents parent for multi-hour compound work — but the field fix for “this session went cold when it shouldn’t have” is smaller than a product roadmap.

It is three lines of discipline and one ugly Unix job.

The three-line field recipe

Strip the overnight agent job down to what actually moves work:

1. A goal command — a single north star for the run (scope, done-test, constraints). I learned the slash-goal shape from watching others; I was already doing the informal version: big outcome, then the steps that get you there.
2. Repeat until finished — an explicit loop instruction. Keep going. Own quality and completeness. Do not stop at the first plausible stopping place. (The “keep repeating until you’re finished” habit sits in the same family as the simple agent loops people have been rediscovering under various names.)
3. A 30-minute self-deleting heartbeat — external liveness that asks the session three questions and removes itself when the answer is truly done.

The first two live in the prompt. The third lives in the operating system. That split is the whole article.

The literal cron

Everyone builds the enterprise graph loop. The poor man’s version looks like this:

*/30 * * * * ask yourself if you're finished

That line is a joke and a design document. In practice you install whatever your agent environment can schedule — 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. The shape matters more than the brand of timer:

every 30 minutes:
  ask:
    How are you going?
    Are you actually finished?
    What's the next step?

  if finished:
    remove your own wake-up
  else:
    continue the goal

Self-delete is not optional decoration. Without it you invent a different failure mode: a finished project that keeps getting interrogated forever. The heartbeat is a temporary employee. When the job is done, fire it.

Don’t allow a long-running cognitive worker to go cold merely because it temporarily believes it has finished.

“Repeat until finished” already tries to prevent early exit. The cron exists because sessions still lie, stall, or hang on children. The loop instruction is optimistic. The heartbeat is the external truth serum.

Why thirty minutes is engineering

Half an hour is not a superstition. It is cache arithmetic.

Long agent sessions carry large prompt prefixes — tools, system instructions, the growing transcript. Providers cache those prefixes so re-sends are cheap. Anthropic’s prompt-caching docs put a default short lifetime on the cache (five minutes), refresh the entry on use at no extra cache-write charge, and offer an extended 1-hour duration when you need a longer window.¹ Cache reads are billed at a tenth of the base input rate — which is why a mid-window status poke is almost free relative to processing the same prefix cold.^1,2

The field intuition from running overnight Claude Code jobs is simple:

• Design as if a long warm window is on the order of ~1 hour.
• Ping at 30 minutes so you land well inside that window while the prefix is still warm.
• Ping at a full hour and you flirt with a cold re-read — the expensive mistake that looks like “just checking in.”

I would not claim every slice of every coding-agent context obeys one perfect sixty-minute timer. Defaults and product paths differ; some stacks still sit on short TTLs unless you opt into longer ones.¹ The engineering claim is narrower and more useful:

So the “extra” check is not extra in the way people fear. The expensive thing is letting the worker go cold and then paying again to remember who it was.

Externalised persistence

Here is the deeper pattern under the joke cron:

You externalised persistence.

The model does not need to be intrinsically persistent. Cron is persistent. The wiki is persistent. Postgres is persistent. Git is persistent. The model can remain relatively ephemeral — cheap, replaceable cognition acting over durable external state.

That one-line doctrine is the reuse hinge from Designing Loops Not Prompts: durability beats coordination. You do not make a long job reliable by teaching the model better manners about “being done.” You make it reliable by putting liveness and memory somewhere that survives a confident early exit.³

People collapse those three layers into one and then wonder why “orchestration” got complicated. Split them and the poor man’s stack is obvious: the model thinks, cron pokes, the database and the repo remember.

This is the personal, developer-scale version of a broader architectural point we have been making elsewhere: the organisational problem is not only which model you rent — it is where state and authority live.⁴ Overnight email→Postgres→wiki runs are the same pattern with dirt under the fingernails. The agent is not the system of record. The system of record is the thing still true after the session dies.

What this is — and is not

This piece is an extender. The parents already did the heavy conceptual lifting:

• Long-Running Agents / Breaking the 1-Hour Barrier — multi-hour work as an architecture problem, not a model-size complaint.⁵
• Designing Loops Not Prompts — who holds the state machine; durable external state; simple loops over theatrical promptcraft.³

What you are reading is the three-line field implementation plus the cache-aware cadence. 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. If you need the full architecture, read the parents. If you need a job to survive the night without babysitting, install the heartbeat.

Tonight’s install

1. Write the goal. One outcome, constraints, and a done-test the agent can check without asking you.
2. Say the loop out loud. Repeat until finished. Own quality. Do not declare victory at the first smoke test that “looks fine.”
3. Install the wake-up. Every 30 minutes: how going / actually finished / next step. Self-delete when finished.
4. Put work products outside the chat. Commits, tables, wiki pages, artefacts a cold successor could resume from. The heartbeat keeps the session honest; the durable media keep the project real.
5. Leave. The point of external liveness is that your attention is not the orchestrator.

If the job still dies, you have a different problem — permissions, tools, a done-test that is fuzzy, a subagent that cannot write its progress anywhere durable. The cron will not invent competence. It will only stop the specific, boring failure where a long worker goes quiet because nothing outside it asked the three questions.

The punchline worth keeping

Elaborate harnesses often rediscover Unix. A timer. A question. A file that still exists in the morning.

*/30 * * * * ask yourself if you're finished

Persistence belongs outside the model. Cadence belongs inside the cache window. Everything else is optional complexity you can add later — after the overnight job has actually finished.