Run the agent on its own

An agent runs on its own when a scheduler starts it, with a written routine, at a fixed time. That part is easy. What makes it safe to leave alone is three habits: the routine checks every tool it needs before doing anything, it proposes instead of publishing, and something outside the routine checks that it actually ran. Without the third one, a routine that died last month looks exactly like a routine with nothing to report.

The scheduler itself matters less than people think. A cron job on a server, a scheduled task in your agent client, or a Make or n8n scenario that triggers the agent all do the job; the tools chapter covers which fits which case. What follows applies to all of them.

Pick what deserves a schedule

Not every agent task should run unattended. A routine earns its schedule when the input arrives on its own rhythm and the output can wait for a person.

Good fit	Poor fit
Weekly review of search data with proposed pages to fix	Anything that sends to a customer or prospect
Daily draft of a post from a brief written in advance	Tasks where the input is a conversation
Monday digest of replies to last week’s outbound	One-off analyses you will run twice a year
Nightly check that product facts and published pages agree	Anything where a wrong output cannot be undone

The routines behind Derrick’s marketing follow that split (I co-founded Derrick). They read, analyse and draft on a schedule; publishing and sending stay with a person or with a narrow, written exception.

Write the routine as a numbered prompt with a step 0

A routine is a prompt that a scheduler sends to the agent with no one watching. Write it as numbered steps, each with a clear output, and start with a step that does no work at all.

ROUTINE weekly-seo-review   (Monday 07:00)

STEP 0. Check tools. Call each one once with a harmless read:
  - analytics: last 7 days, 1 row
  - pages sheet: read 1 row
  - drafts folder: list files
  If any call fails or the tool is missing:
    write "BLOCKED weekly-seo-review: <tool> <error>" to the alerts channel and STOP.
  Do not use another tool in its place. Do not estimate the missing data.

STEP 1. Pull last week's clicks and impressions per page. Compare with the
        previous 4 weeks. Keep pages that dropped by more than 30%.
STEP 2. For each kept page, read it and write one proposed fix with the reason.
STEP 3. Save proposals to drafts/seo-review-<date>.md. Do not edit any live page.
STEP 4. Append a run record to runs.jsonl:
        {"routine", "started_at", "finished_at", "status", "items_in", "items_out", "blockers"}

Step 0 exists because of what an agent does when a tool is missing: it improvises. It finds another way to get something that looks like the data, or it fills the gap from memory, and the report reads as normal. A routine that stops and says “blocked” costs you one alert. A routine that improvised costs you a week of decisions on numbers nobody measured.

Two more rules sit in the prompt itself. “Do not use another tool in its place” closes the fallback door explicitly, because the model will otherwise treat it as helpful. And step 4 writes a record even on success, which is what makes monitoring possible later.

Propose, never publish, unless a written exception says so

A scheduled agent has the same permissions at 7 a.m. on a Sunday as it has when you are watching, and none of your judgement. So by default a routine writes to a drafts folder, a branch, a pull request or a review queue, and a person decides.

Exceptions exist, and they should be written down where the routine reads them, not agreed in a chat.

routine: weekly-seo-review
may_do_alone:
  - read analytics and pages
  - write files in drafts/
needs_a_person:
  - publish or edit a live page
  - send any email or message
  - delete anything
  - spend credits above the run budget
exceptions:
  - action: fix an internal link that returns 404
    scope: pages listed in pages sheet only
    approved_by: owner
    review_after: 4 weeks

Every exception has a scope and a review date. When the review comes, either it has held up and stays, or it goes. The security chapter covers the permissions side: which keys the routine holds, and what it must never touch at all.

Run every new routine once by hand

Before you schedule anything, start the routine yourself, in the same environment the scheduler will use, and watch it from step 0 to the run record. Many agent clients ask for permission the first time a tool is called. On a schedule, that prompt appears on a screen nobody is looking at, and the routine sits there, blocked, never reaching the step that would have reported it. It never errors, so nothing alerts.

The manual run also shows you what the routine actually reads and writes, which is often a little different from what you wrote. Fix the prompt, run it again, and only then put it on the schedule.

Check that routines are alive, from outside

A routine cannot report that it did not start. So the check has to live somewhere else: a small script, itself scheduled, that reads the run records and compares them with what should have happened.

import json, time

EXPECTED_HOURS = {"weekly-seo-review": 7 * 24, "daily-post-draft": 24}

last = {}
for line in open("runs.jsonl", encoding="utf-8"):
    run = json.loads(line)
    last[run["routine"]] = run

now = time.time()
for name, hours in EXPECTED_HOURS.items():
    run = last.get(name)
    if run is None or now - run["finished_at"] > hours * 3600 * 1.5:
        print(f"STALE {name}: no finished run in the expected window")
    elif run["status"] != "ok":
        print(f"FAILED {name}: {run['status']} {run.get('blockers')}")

I run a script like this because a frozen routine and a resting one look the same from the outside. Both produce nothing new.

The same reasoning applies to the services a routine depends on. In November 2026, a data service behind one of my agents passed its health check while every real query failed: the check pinged the service but never touched the database, and the cloud project was on a free tier that deletes tables after 60 days. A health check must exercise the real path, so make it run one real query and compare the answer with something you know.

The last weak point is the setup itself: the same week, the whole agent organisation still existed in one copy on one laptop, a case the security chapter covers.

The checklist before a routine goes on a schedule

Check	Done when
Step 0 lists every tool	Removing any one tool makes the routine stop with a clear alert
Fallback is forbidden in writing	The prompt says what not to do when a tool is missing
Output goes to a reviewable place	Drafts, branch, queue, never live by default
Exceptions are written with scope and review date	The routine reads them from a file
One manual run completed	Run record written, no pending permission prompt
Vitality check covers it	The routine is in the expected list with its interval
Output passes the same gates as manual work	Lint and judge from the quality chapter

Your next step: take the agent task you already run by hand every week, write it as a routine with a step 0 and a run record, run it once yourself, and add it to a vitality check before you give it a schedule.