Seven AI Agents Run Our Nights: Scheduled Agents Beyond Coding, With the Prompts

On 23 September, a user named Rob wrote on our public backlog: "would love to get examples of how you guys are doing stuff beyond coding". Fair question. Everything on this site is about coding agents, and the thing we actually run every evening is mostly not coding.

Since 28 August, seven agents start on a Mac mini at 20:00. They read the day's commits, the Search Console, the admin dashboards, the backlog, the feedback people sent, the last night's reports. They fix bugs, correct the website, write and translate a blog article every three days, post on three social networks, update a product knowledge base, and at 22:00 the seventh one reads what the six others left and sends a 25-line email. Nobody watches. The founder reads the email on his phone the next morning.

This article is the answer to Rob. What runs, how it is wired, how the agents hand work to each other without ever talking, which model does which job and why, the four rules their prompts had to learn the hard way, and the prompts themselves, condensed into blocks you can copy. Every number below comes from the repository: the reports are committed there, night after night.

What 33 nights produced

The reports folder in the repository has 33 dated directories, from 28 August to 30 September. Reading them gives this:

• 31 morning emails sent by the reporter.
• 51 bugs fixed by the fixer, each with a commit link in its report line. Several were reported by users on the public backlog and got a reply on the next release.
• 7 blog articles written by the SEO team since 10 September, one every three days, each in English and French first, then in 18 more languages the same night.
• 29 days of social media journal: three networks and five Facebook groups per evening, plus a thank-you comment under every post where a user shared AgentsRoom.
• A product knowledge base of about a hundred fact sheets, kept in sync with the day's commits, which the in-app assistant reads and the site serves as llms-full.txt.

None of this required a human after 20:00. Some of it required a human at 08:00, which is the point of the last agent.

The roster: who runs at 20:00

Every agent is a Scheduled Task in AgentsRoom: a prompt, an agent (role, CLI, model), a machine, and a time. All seven run Claude Code. Two of them are not single agents but two-step teams, and we will come back to why.

The .md files in the last column all live in reports/night/<date>/, committed and pushed. That folder is the whole coordination system, and the next section is about why.

How they are wired

Each of the seven is a Scheduled Task with the same shape:

• Fires daily at 20:00 (22:00 for the reporter). No cron expression; the frequency is picked in the editor.
• Pinned to one machine. The project is open on several computers, and a trigger fires on every machine that has it unless you restrict it. Ours are restricted to the Mac mini, so a laptop opened at 20:05 does not start a second CEO.
• Wakes the machine. The Mac mini sleeps. The task has a "wake the machine" option, which schedules a wake with the operating system's own tool (pmset on macOS, Task Scheduler with wake-to-run on Windows, rtcwake on Linux) a few seconds before the run. Without it, a sleeping machine simply misses the run.
• Catch-up on or off, per task. If the machine was off at 20:00, a task with catch-up on fires at the next launch. The CEO, PM and reporter have it on. The SEO, fixer, social and documentation tasks have it off: a run that starts at 11:00 the next morning would collide with the day's work in the same checkout.
• Permission mode set on the task, not on the provider. An unattended run cannot stop at an approval prompt at 3 AM, so the task runs without them, while the agents the founder drives by hand on the same CLI still ask first.
• The console closes after 60 minutes idle. A finished agent does not sit in the sidebar until someone closes it.
• The prompt is the first message. The text of each prompt is stored in the Prompt Library and is the same text as the trigger's prompt field, so editing one means editing both. The prompts are in French, because the founder reads the reports in French. Everything else, from commit messages to the knowledge base, is in English.

One more piece is shared by all seven: a skill called "night agents, common rules". Each prompt starts with "load this skill and apply it", and the skill holds everything that is true for all of them: who owns what, the one-night-one-run guard, git rights, the report format, the backlog rules, and the email format for the reporter. When a rule changes, it changes in one place.

How they hand work to each other without talking

The seven agents never message each other. They could, AgentsRoom has an agent mailbox, but a message is invisible the next morning and cannot be grepped. Everything goes through three things that survive the night:

The repository. Every agent writes reports/night/<date>/<agent>.md, opens it in the first minute of its run, rewrites it after every finished piece of work, commits and pushes it. The report has four fixed sections: "In two words" (a bullet list, one bullet per thing done), "To decide" (only what the prompt reserves for the human), "To check" (a local URL or a screen to open), "Details" (as long as needed). It ends with a run marker: the last commit the agent saw.

The backlog. An agent that finds work for another one does not do that work. It opens a ticket with a tag: ceo-fix for a verified, small bug the fixer will take; ceo-seo for a content job with its target query; ceo-decision for anything that needs the human (database, billing, auth, encryption, prices, a URL that is indexed, a default behaviour). The documentation keeper, reading the commits, finds a feature with no page on the site: it files a ceo-seo ticket, and the SEO takes it the next night. The CEO, reading the error logs, finds a bug with its cause in the code: ceo-fix, and the fixer takes it the next night.

Yesterday's report. Before opening any job, each agent reads its own report of the night before, plus the list of tickets closed during the day. What it flagged yesterday has often been fixed during the day. A subject already handled is not raised again; a ticket already open is not recreated.

The loop closes with the human. The reporter's email ends with one line: to answer the product manager, add a "## Decisions" section at the end of rapport.md (P1 OK / P2 NO: reason / P3 LATER), commit, push. The PM reads the pushed version the next evening and executes what was approved: creates the ticket, merges the duplicates, parks the rest with the reason. A decision that gets no answer for three nights is a decision: the proposal leaves the email and stays as a ticket.

Which model does which job, and why

The table above shows two models. This is the current configuration, not a benchmark, and it moves. But the split is deliberate.

Fable where the job is judgement. The CEO decides whether a thumbs-down on an oracle is a real error or a preference. The fixer decides whether a bug report is a bug or a machine-specific setup, then finds the cause in the code. The SEO step 1 decides which sentence on the site became false with today's commit, which article to write, and which page to leave alone. The social step 1 picks the evening's subject and writes for an audience that spots generated text in three lines. These prompts are long (the SEO one is about 4,000 words) and full of "you decide, you do not ask" rules with short lists of exceptions. That is where the strongest model earns its cost.

Opus with a 1M context where the job is volume. Translating an article into 18 languages with sub-agents, three locales each, then checking the merge against the French reference, is reading and writing, a lot of it, with the same rules applied 18 times. The documentation keeper reads a day of diffs against a hundred fact sheets. The PM reads an 8 MB export of exit conversations. The reporter reads five reports and copies, it does not think. A large context and a lower cost per token matter more than judgement there.

Two of the seven are therefore teams of two steps, each step an agent with its own model. Step 1 on Fable ends by writing a "Handoff" section in the shared report: the exact list of files and keys the translator must deliver, or the exact posts the publisher must publish. Step 2 on Opus reads that section and does only what it lists. The team's graph is linear, one cycle, and the report keeps its "run in progress" line until step 2 removes it. From the outside, at 22:00, a report still marked "in progress" means either a cut run or a team between its two steps, and the reporter says which.

The four rules the prompts had to learn

The first prompts were job descriptions. The current ones are mostly rules, and each rule has a date, because each one was written after a night went wrong.

1. A run marker, read from yesterday's report. The first version of the SEO agent read "the commits of the last 24 hours". Two problems: a run at 20:00 and a run at 20:10 the next day do not see the same 24 hours, and a night the agent did not run is a day of commits nobody looks at. Now every report ends with Last commit seen: <sha>, and the next run starts from that commit, whatever the clock says. No marker (first night, missing report): two days back, and the report says so.

2. The history is on disk, so grep it before raising anything. The complaint that came back most often in the first two weeks: "you already told me that, I fixed it yesterday". The fix is a rule with a command in it: before flagging a subject or opening a job, grep -ril "<the subject>" reports/night/ and git log --since="30 days ago" -- <the file>. A match means read that report first. Three cases, and only three, allow talking about a treated subject again: the fix did not work and you just verified it; the fix is partial and you name what remains; the subject changed nature. Two corollaries came with it. One night, one run: if tonight's report exists, contains "In two words" and no longer says "run in progress", the agent stops. And a proposal with no answer for three nights leaves the report; the ticket remains.

3. The report is opened before the work starts. A run cut at 21:30 used to leave nothing. Now the first thing an agent does after loading the skill is mkdir -p reports/night/$(date +%F) and write the report skeleton with its four section titles and a line run in progress, started at 20:01. It rewrites the whole file after every finished job. A cut run leaves a partial report the reporter can copy, which is much better than an agent that "did not run".

4. Commit as you go, never at the end. Measured on 9 September: two agents were stopped at the same minute. The one that committed after every job lost nothing. The other left 45 modified, unpushed, unattributable files that the founder picked up by hand the next morning, and its report did not exist. Since then the rule is one commit per finished job, files named one by one, a last commit for the report, and at least one push during the run. A commit is also a dated trace, which is what rule 2 greps.

A fifth rule is not about memory but about courage, and it is the one that changed the output most. The SEO prompt says: "You are not an auditor who reports findings: at night, the site is yours. A run that ends with six leads to validate is a failed run." Then it lists the six cases, and only six, where the agent must ask instead of act: deleting or renaming a URL, changing the title of a page that ranks, legal text, a price or a quota, a claim about privacy or encryption, a change touching more than five pages. Everything else, it does, and the founder removes what he does not like the next morning. The fixer has the same rule with three cases. Before that rule, the reports were lists of suggestions. After it, they are lists of commits.

The prompts

The originals are in French and long. What follows is the part that transfers, in English, with our project-specific paths and names removed. Three blocks: the shared rules every agent loads, the reporter, and the two "decide, do not ask" sections.

Block 1: the shared rules (loaded by all seven as a skill)

# Night agents: common rules
They take precedence over your own prompt if the two disagree.

## One night, one run
DAY=$(date +%F); F=reports/night/$DAY/<you>.md
If F exists, contains "In two words" and no longer contains "run in progress":
stop. Write nothing, send nothing, end with a one-line message.
If it still says "run in progress": it is your own run, cut a few minutes ago.
Resume where it stopped, do not start over.

## What you may do
- Git: add <named files>, commit, push of YOUR work, as you go.
  Never: add -A, commit -a, push --force, stash, reset, checkout, clean, new branch.
- Build: typecheck, lint, check scripts, a local build to verify.
  Never: any script that deploys or publishes.
- Backlog: create a ticket, append to a ticket, close a ticket you fixed.
  Never: reply to a user (that sends an email), delete a ticket, overwrite a description.
- Never a made-up number. Source unavailable: say so and move on.
- Before any git write: git status --short. The tree is shared with other agents.

## Catch up, and know what was ALREADY done
git fetch && git status -sb
Behind and clean: git pull --ff-only. Behind and dirty: do not pull, say so at the top of your report.
Your run marker: the line "Last commit seen: <sha>" at the end of yesterday's report.
No marker: --since="2 days ago", and say so.
Three mandatory readings before any analysis:
1. git log --no-merges --format='%h %s' <sha>..HEAD and git diff --stat <sha>..HEAD
2. the tickets closed since yesterday, and the tickets a human put on hold
3. your own report of yesterday: "In two words" and "To decide"

## The reports folder IS your history
Before raising a finding or opening a job:
grep -ril "<subject>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <the file>
A match: read that report before deciding anything.
Two nights in a row on the same subject: the second one is wasted.
A page or text you touched is not touched again for three weeks,
except to fix something that became false.

## Never raise the same thing twice
A finding already handled that comes back the next day is a fault.
Only three cases allow it:
1. the fix did not work, and you just verified it: "fixed on <date> by <commit>, still broken: <proof>"
2. the fix is partial: name exactly what remains
3. the subject changed nature: new cause, new measure, new scope
Do not recount a stock. Report the variation, never the stock.

## A proposal with no answer dies after three nights
Nights 1 to 3: the line carries its counter and first date ("2nd night, raised 07/09").
From the 4th: it leaves "To decide". The ticket remains; one line in "Details" at most.
If the decision is within your scope, decide on the 3rd night and say so.

## Commit and push as you go
First commit as soon as the first job is finished and verified. Then one per job.
Last commit for your report. Push at least once during the run and once at the end.
Push refused (remote moved): git pull --ff-only, then push. Still refused: do not force,
do not rebase, write it in the report.

## Your report: opened at the start, never written only at the end
reports/night/<YYYY-MM-DD>/<you>.md, created BEFORE the work, with:
  # <Agent> - <date>
  _run in progress - started at <HH:MM>_   (removed at the end)
  ## In two words      (3 to 5 lines, or a bullet list: one bullet per thing done)
  ## To decide         (only what your prompt reserves for the human; else "Nothing")
  ## To check          (- [ ] what : where : what one should see; else "Nothing")
  ## Details           (as long as needed: proofs, files, commands)
  ## Run marker
  Last commit seen: <git rev-parse HEAD after your last commit>
Rewrite the whole file after every finished job.
The reader is on a phone, for two minutes: short sentences, no file paths,
no SHA, no function names in the first section. A number only if it changes a decision.

Block 2: the reporter (22:00)

You are the reporter. You run two hours after the others.
Your only job: read what they left and send ONE email the founder reads
in one minute on a phone, and understands without opening anything else.
You analyse nothing, fix nothing, propose nothing. You gather and clarify.

The night you report is read from disk, not from the clock:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only if the tree is clean: reports are committed.
2. ls reports/night/$DAY: wait for the five files (ceo, seo, pm, fixer, social).
   Missing: sleep 9 minutes and recount, 6 rounds max. Then send anyway, naming who is missing.
3. A report that still says "run in progress" is a cut run, not an absent one.
   Copy what it contains and write in "What did not work" that this agent was cut.
4. From each report take three sections only: "In two words", "To decide", "To check".
   Never quote "Details".
5. The fixer's fixed bugs are bullets in three parts separated by " > ":
   what the user suffered > the cause in one sentence > the commit URL.
   Copy them character for character, link included, into "Bugs fixed".
6. git status -sb and git log --oneline --since="4 hours ago": a report that claims
   work with no commit, modified files nobody claims, or unpushed commits: first line of the email.

Write reports/night/$DAY/report.md. 25 lines of text maximum
(section titles and "Bugs fixed" lines do not count).
Six rules, applied line by line:
1. One bullet = one complete sentence that stands alone. Never "as reported yesterday".
2. A subject appears in ONE section only.
3. Zero jargon: no path, no SHA, no key name, no internal abbreviation.
   One exception: the full GitHub URL of a commit, mandatory on each "Bugs fixed" line.
4. A number only if it changes a decision, and it is a variation, never a stock.
5. Two lines maximum per bullet. The detail is in the agent's report.
6. Bad news before good news, and the first line says whether something is broken.

Sections, in order: To decide / To check / Bugs fixed / What was done /
Social networks (3 lines max, links included) / CLIs and models (1 line) /
What did not work. An empty section is one word: "Nothing".
Never cut: "To decide", "Bugs fixed" with links, the post links, the SEO article.
Send. Check the HTTP code. Append "Sent to ... - HTTP <code>" at the bottom.
Commit and push report.md. Never send twice: if today's report.md already has
a "Sent to" line, stop.

Block 3: the "decide, do not ask" sections

The SEO agent, section 0 of its prompt:

# 0. You decide, you do not ask
This is the most important rule of this prompt and it wins over your reflex of caution.
You are not an auditor who reports findings: at night, the site is yours.
A run that ends with "here are 6 leads, to validate" is a failed run.
When you hesitate, put yourself in the founder's place and decide with four references:
- what the product really does, read in the repository and the published version, never in the existing copy;
- what the site already says: its angle, its tone, its promises. You extend, you do not reinvent;
- what Search Console says: which pages live, which intents really exist;
- the audience: developers searching Google, and the AI assistants that recommend tools.
  What counts for them: a verifiable, datable claim; a page that answers one precise question;
  an up-to-date llms.txt consistent with the pages; honest comparisons.
The founder reads your report the next morning and will tell you to remove what he does not like.
One correction too many costs five minutes; a night without output is lost forever.

You ask for his opinion in these six cases only:
1. deleting or renaming an existing URL;
2. changing the title or meta description of a page that ranks, when it is not false;
3. legal text (terms, privacy, licence);
4. a price, a commercial quota, an offer;
5. a claim about privacy, encryption or where data runs;
6. a change that would touch more than five pages at once.
In those six cases: a ticket tagged for a decision, one line in "To decide", and you move on.
Everything else, you do tonight. If "To decide" contains anything else,
you delegated a decision that was yours.

The fixer, section 0 of its prompt:

# 0. You fix, you do not classify
A bug reported by a user is a promise. Someone took the time to write, they are waiting,
and nobody else will handle it tonight. A run that returns "5 bugs analysed, 1 fixed,
4 documented" is a failed run. Your goal is the empty queue: users' bugs first,
oldest first, then the rest, until there are none left.
When you hesitate on a fix, decide with three references:
- what the code does today, read, not assumed;
- what the user obviously expected when writing the report;
- the least risk: the narrowest fix that settles the cause, not the most elegant.
A debatable fix costs five minutes to undo; a bug left one more month costs a user.

You may leave a reported bug without a fix in three cases only, proven in the ticket:
1. you did not find the cause after a real investigation: write what you eliminated,
   not just "not reproducible";
2. it is not a bug, it is a decision: database, billing, auth, encryption, privacy,
   an indexed URL, a default behaviour. Ticket for a decision, with your recommendation;
3. a gate refuses your fix and you cannot repair it.
"It is big", "it touches several files", "I would rather ask" are not reasons.
One bug = one commit. Then the ticket goes to done, and if a user reported it,
a two-sentence message is queued for the next release. Never "pending": that column
belongs to humans.
Your report line for each fixed bug, copied verbatim into the morning email:
- <what the user suffered> > <the cause, one simple sentence> > <commit URL>

The other four prompts (CEO, PM, documentation keeper, SEO step 2) follow the same skeleton: load the skill, name the files you may write, list the readings in order, say what goes in the ticket and what goes in the report, end with the run marker.

What did not work, and still does not

Some nights are in the "What did not work" section of the email, and they are worth listing because they are what you will hit.

• Five agents pushing to the same branch at the same minute. A push is refused because the remote moved. The rule is git pull --ff-only then push, never force, and if it fails twice the report says so and the human pushes in the morning. It happens about once a week.
• A commit that swept another agent's staged file. On 29 September the SEO's first commit carried a deletion the documentation keeper had staged in the shared checkout. Nothing was lost (the deletion was intended), but the commit is attributed to the wrong agent. Since then every commit uses explicit pathspecs, and the rule "files named one by one" is not a style preference.
• A disk that hit zero bytes free at 20:10, two evenings in a row. External to the agents, recovered on its own at 20:25, no file lost. But the reports say it, because a night with a full disk looks exactly like a night where an agent did nothing.
• The reporter waiting 54 minutes for a report that will not come. Six rounds of nine minutes is the cap. A team between its two steps at 22:00 looks like a cut run, and the email says "had not finished", which is honest and slightly alarming to read.
• The first weeks of repeated findings. Rule 2 above did not exist until the founder wrote "you told me this three days ago" for the fourth time.

How to set this up yourself

You do not need seven agents. You need one that writes a report you will read, and a reporter is only useful from the third agent on. In AgentsRoom:

1. Write the prompt in the Prompt Library. Start with block 1 above as a skill, and a short prompt that says what this agent owns and which files it may write.
2. Create a Scheduled Task on the project: daily at the hour you want, the agent's role, CLI and model, the prompt, and in the advanced block the permission mode for an unattended run. Pin it to the machine that will run it, and turn on "wake the machine" if that machine sleeps.
3. Create the reports/night/ folder in the repository and commit it. That is the whole coordination layer.
4. Add a second agent the day the first one starts producing tickets for someone else: a ceo-fix tag only means something when a fixer reads it the next night.
5. When one job splits into judgement and volume, make it a team of two steps with two models, and make step 1 write a handoff section that step 2 reads.

The Scheduled Tasks page describes the fields, and the article on putting coding agents on the night shift is the reasoning that came before the roster. If your agents share a machine, read what happens when ten of them run the same command first: it happened here, at night, and the fix is a small shared lock.

Rob, that is what we do beyond coding. The prompts are the product.

Frequently asked questions

Do you need AgentsRoom to run agents on a schedule like this?

No. A cron line and claude -p will start a Claude Code session at 20:00 on any machine. What you write yourself then is the rest: waking a sleeping computer, catching up a run the machine missed, keeping one run per night when the project is open on two computers, passing a report from one agent to a second one on a different model, and seeing on your phone that the run is stuck on a question. AgentsRoom's Scheduled Tasks carry those pieces, and the seven agents in this article use every one of them. The prompts and the rules transfer as they are, whatever starts the session.

What does a night of seven agents cost?

They run as Claude Code sessions on a Claude subscription, like any agent you start in AgentsRoom, so there is no per-token invoice for them, and we have not published a cost per night. The rule that keeps it bounded is the one-night-one-run guard: a trigger that fires twice, or a run cut and restarted, does not repeat the work, because the first thing each agent does is check whether tonight's report already exists and is closed.

Is it safe to let agents commit and push while nobody is watching?

It is safe because of what they are not allowed to do, not because of what they are told to want. The shared rules forbid git add -A, commit -a, force pushes, stash, reset, checkout, clean, creating a branch, and any script that deploys. Every commit names its files one by one, the tree is inspected with git status before any write, and a push refused because the remote moved is resolved with a fast-forward pull or left to the human. The morning review is the commit list of the night, and anything wrong is a five-minute revert.

Why do the agents write Markdown reports into the repository instead of a dashboard?

Because the report is also the memory. Each agent starts by reading its own report of the night before, finds its run marker there (the last commit it saw), and greps the whole reports folder before raising anything, so a subject treated last week is not raised again. A dashboard would show the same numbers and remember nothing. Committing the report also dates it, which is what lets the next night know exactly what the previous one touched.

Why are two of the seven agents teams with two steps on two different models?

Because the two halves of the job are not the same job. The SEO step that reads Search Console, decides what is false on the site and writes the article in English and French needs judgement, and runs on Fable. Translating that article into 18 other languages, running the i18n gates and the build is volume, and runs on Opus with a 1M context. The first step writes an explicit handoff section in the shared report, the second step does only what that section lists. Same split for the social team: writing and the visual on Fable, publishing in Chrome and thanking people on Opus.

What happens when a run is cut in the middle?

The report exists from the first minute of the run, with a line that says run in progress, and every finished piece of work is committed on the spot. So a run cut at 21:40 leaves a partial report, its commits, and no untracked files. The reporter copies the partial report and writes that the agent was cut. We learned this the hard way on 9 September: two agents stopped at the same minute, the one that committed as it went lost nothing, the other left 45 modified files that nobody could attribute.