When you run 6 sites and an app business alone, the bottleneck is not "what the work is" but "when, and who, runs it." The more work you hand to autonomous agents, the more that task collisions, resource contention, and — from the outside — unnatural behavior surface as problems before quality ever does. When I recently slotted a one-off job, applying to 11 AdMob server-side bidding partners, in between the standing operations, I felt anew that scheduling design is the substance of parallel operation.
I have built apps solo since 2014, and today I run 4 technical blogs (the Claude / Gemini / Antigravity / Rork Labs) and 2 reading-oriented blogs via autonomous-agent scheduled tasks. On top of 16+ article-generation tasks a day, AdMob floor tuning, report pulls, and site integrity checks run daily. Here is the timetable I built to run all of this without breaking, and the judgment behind it.
First, map the "peak hours"
The starting point of scheduling was not features but mapping "the hours to avoid." Run agents while readers are concentrated, and cache purges and rebuilds hit the reading experience directly. Pile every task into the dead of night, and multiple tasks fire at the same moment and fight over resources.
The peak windows I decided to avoid are morning 7–9 (commute), midday 12–13, and evening into night 18–23 (prime time). On top of that, I wrote the times of existing automated jobs onto the map as collision points (reading-blog posting at 2:30, wallpaper-app data updates at 3:30 and 15:30, cache clears at 11:48 and 23:40). New tasks go only into the "open time" left after blacking those out.
Stagger 4 sites × 4 types in 45-minute steps
The actual timetable places 4 types per site (premium / hands-on review / troubleshooting / standard article) staggered by 45 minutes to an hour, per site and per type.
# Off-peak distribution of autonomous tasks (JST, excerpt)
02:00 Claude Lab premium
02:45 Gemini Lab premium
04:00 Antigravity premium
04:45 Rork Lab premium
05:30 Claude Lab hands-on review
...
11:00 Claude Lab troubleshooting
14:00 Antigravity troubleshooting
15:00 Claude Lab standard article
17:00 Rork Lab standard article
The 45-minute step exists because generating one article — plus two languages, plus the quality gates, plus push — finishes in around 30 minutes at most. I keep enough margin that a task running a bit long does not bleed into the next, while packing in as much as the open time allows. Making "processing time + buffer" the unit of one slot makes the timetable far easier to assemble.
From an agent-design standpoint, the key is to make each task fully independent. If tasks share state, one's delay drags the other in. I complete each site's repository operations in a separate working directory and keep zero state passed between tasks. A parallel-operation schedule only makes collisions vanish "just by staggering times" once independence is guaranteed.
Set a per-site daily generation cap
What is easy to overlook in parallel operation is the generation pace as seen from the outside. Google treats "scaled content abuse" as a quality-policy violation. Running multiple sites with autonomous agents, you can technically generate 10 or 20 articles a day — and that reliably raises the risk of a spam classification.
So I set an absolute cap of 5 articles per site per day, and currently operate at 4/day. This is not a limit of the agent's capability; it is a deliberately imposed ceiling. When I add or resume a single scheduled task, I make it a rule to count "that site's total for the day" before configuring it.
Recently I have taken this one step further: keeping the total task count fixed while lowering the share of brand-new generation. On sites where the index signals stall, I cut the slots that add new URLs and reallocate them to improving existing articles. The number of tasks per day stays the same; only the site's externally visible "pace of new pages" quietly drops. Changing the allocation, rather than halting generation outright, keeps the operational rhythm intact.
In operations automation, "I could run more" and "I should run more" are different things. The higher the agent's throughput, the more it matters that the human explicitly holds the cap. Alongside task independence from the previous section, I consider this one of the two pillars of fleet design.
Slotting one-off tasks into the standing fleet
When the standing operations fill the timetable, the question becomes where to slot a one-off job like applying to 11 AdMob bidding partners. Two design calls settled it.
One: do not collide a one-off task with the standing tasks' peak (the late-night-to-morning generation cluster). Application work is mostly browser operation and network waits — a different resource profile from article generation — so I shifted it to afternoon slots where generation tasks are sparse.
Two: put one-off tasks through the same completion condition and verification gate as standing tasks. For the bidding-partner applications, I did not call it done at "it got enabled" — I set the completion condition at "real impressions appeared in the report." Same philosophy as standing generation tasks always passing three quality gates before push (article quality, redirect integrity, frontmatter integrity). The more a one-off job cuts into the fleet, the more failing to apply the same verification discipline leaves a hole — "only that job skipped verification" — later.
Never stop on errors — design around autonomous recovery
Finally, the design that helped most in parallel operation is "do not bounce errors back to the human." With 16+ tasks running daily, transient network failures and git rebase conflicts happen routinely. If a human had to catch each one, autonomous operation would be pointless.
I build an automatic recovery procedure into each task from the start. If push fails, re-push after git pull --rebase; if that still fails, recreate the repository and push from a fresh clone. Only truly unrecoverable cases are logged and the task exits, with notifications to the human kept minimal. Writing "when in doubt, exercise your own judgment and take the action that seems best" as each task's behavioral principle prevents the accident of an agent stalling on a confirmation prompt and collapsing the whole timetable.
Check the fleet's health in one minute each morning
Since 16+ tasks run unattended, without a way to grasp "did everything succeed" in one minute each morning, silent failures pile up. I designed each task to append one line to an update log (a per-day text file) on completion, and in the morning I check only that log's line count and the per-site match of JA/EN article counts.
I check just two things. One: whether each site's Japanese and English article counts match. If only one side generates, language switching 404s, so a difference in counts is the fastest indicator of an unattended-run failure. Two: whether the day's generation count stays within the cap. Here the human re-grips whether duplicate firing or re-runs pushed it over.
Monitoring works more realistically in parallel operation by narrowing to "the one or two metrics that will definitely alert you when something breaks" than by "watching every metric." Designing the morning check to finish in one minute is itself a condition for keeping the fleet running long-term.
Parallel-operation scheduling, taken to its core, comes down to how you build "a state that keeps running without human intervention." Make tasks independent, hold the generation cap, put one-off jobs through the same verification, and never stop on errors. Satisfy these four, and running 6 sites keeps humming along astonishingly quietly.
Start by writing your own operations tasks onto a single timetable and blacking out the peak hours. The moment the open time and collision points become visible, it becomes clear what you can hand to autonomous agents.