Autoresearch: effective all-day bot loops
2026-08 synthesis of how practitioners and products keep an agent looping unattended all day: durable queue + one isolated unit per wake, not one immortal session.
Autoresearch: effective all-day bot loops
Generated by
/autoresearchon 2026-08-18. Synthesized across 3 rounds from 8 web pages, anchored by the GrokipediaAgentic_workflowentry. See Provenance. Treat as raw material — review before promoting into a project or thread. Context: vault/threads/artificial-intelligence Research prompt (from the queue question): what is the best way to build an effective loop to keep your bot working autonomously throughout the day?
Summary
There is no single product that sources name as "the best all-day bot loop." What 2026 practitioner writeups and vendor docs do converge on is an operational pattern: wake on a clock or event, read a small durable state file, do one atomic unit of work in a fresh isolated session, write the result back to files/git, then exit. The scheduler (cron, OpenClaw heartbeat, Claude Code cloud routines, Cursor Cloud Agents) is interchangeable; the loop that fails is the one that tries to keep one session alive all day and remember everything in context. Official Anthropic guidance still prefers the simplest control path that can do the job — a coded workflow around a queue — and reserves a full agent only for the open-ended unit of work inside each wake (Building effective agents). The question therefore narrows to "which scheduler + what belongs in durable state," not to one stack to buy.
This thread already covers interactive fleet-tending (parallel-claude-workflow / Boris Cherny, April 2026). This pass is about the complementary unattended pattern: keep the bot working when nobody is jumping between tabs.
Findings
The loop is wake–read–act–write–sleep, not one immortal session
Grokipedia's Agentic_workflow primer defines the inner cycle as a perception–reasoning–action loop that persists until a termination condition, with short-term working memory and longer-term storage split so the agent does not reload everything every turn (Agentic workflow). That encyclopedia layer is the inner loop (one task). All-day autonomy is an outer loop around it.
Practitioner writeups in 2026 make the outer loop mechanical:
- A DEV Community walkthrough of an unattended Claude Code agent uses three pieces: a script that runs
claude -p, astate.mdthe agent reads and writes, and a scheduler (cron / launchd / systemd). The author reports running it for more than a week at a 15-minute cadence (How to Run Claude Code as an Autonomous Agent). - A SitePoint guide for 13-day coding-agent runs decomposes work into atomic file-scoped task files, keeps architectural rules and do-not-touch zones in a committed
CLAUDE.md, feeds tasks sequentially to isolated CLI sessions, gates each completion with tests, and commits after every task so rollback is onegit revert(Running AI Coding Agents for 13 Days Straight). - Sam French's April 2026 unsupervised coding loop is the same idea with a real queue: SQS long-poll → isolated
claude -p --dangerously-skip-permissions(or Codex / local Ollama) → git push if there are commits → email → delete the message. Whenautonomous.enabledis on, the runner readsTODO.md, picks the next item, then queues itself again (How I Let AI Agents Write Code While I Sleep).
The shared claim: state lives on disk (or in a queue), not in the context window. The DEV writeup is explicit that state.md must stay small (under 4 KB) because it is injected every iteration; historical journal and learned facts go in cold files the agent reads on demand (DEV Community). French's lesson after a week: without TODO.md the agent "spins in circles, re-doing work it already did"; "no git push = nothing happened" (Sam French).
Official products productize that outer loop (they do not replace it)
Claude Code Routines (research preview, announced 2026-04-14) are a saved prompt + repo(s) + connectors that run on Anthropic-managed cloud (or a self-hosted environment), so the laptop can be closed. Triggers are schedule (minimum one hour), API POST, and GitHub events; a run is a full autonomous cloud session with no permission prompts. Each scheduled/API/GitHub fire starts a new session that clones the default branch; Claude pushes to claude/-prefixed branches (Anthropic blog; Claude Code routines docs). Daily run-count caps sit on top of ordinary subscription usage: Pro 5/day, Max 15/day, Team/Enterprise 25/day; extra runs need usage credits. One-off runs do not count against the daily routine cap (routines docs).
The product therefore matches the practitioner pattern: fresh isolated session per wake, durable work in the repo, human review of the resulting PR. It is not an always-on process. The docs also distinguish local alternatives that require the machine to stay on: Desktop scheduled tasks, and in-session /loop (routines docs).
Cursor Cloud Agents run the same agent fundamentals in isolated cloud VMs with a real environment (clone, deps, secrets, network). Official best-practices put environment setup first, then secrets/OIDC, egress allowlists, agents.md + skills for a "smart but low-context" developer, and tools shaped so the model can actually use them (Cursor Cloud Agent best practices). That is the inner reliability story (can this one PR close?). All-day coverage still needs an outer trigger — a human, a cron, a GitHub event, or another bot — to start those isolated runs.
OpenClaw (formerly Clawdbot; Peter Steinberger) is the always-on personal-agent variant. Community docs describe a Gateway heartbeat: every N minutes the agent reads HEARTBEAT.md, checks pending work, and usually replies HEARTBEAT_OK (cheap no-op). Cost is the binding constraint: default Opus + 30-minute interval is estimated at ~$15/day; Haiku + 60-minute + quiet hours drops that to ~$0.60/day. Keep HEARTBEAT.md short because every token is loaded every cycle (OpenClaw heartbeat docs). Steinberger's 2026-08-15 X post reports the OpenClaw team now builds OpenClaw with OpenClaw and treats shared session URLs as the coordination surface (X post by @steipete, 2026-08-15).
Linear announced a team-level "Loops" product for scheduled/event-driven Linear Agent work on 2026-07-20; both linear.app/now/introducing-loops and linear.app/docs/loops timed out this pass, so no load-bearing claims are taken from it. See Provenance.
What Anthropic's own team is doing (August 2026)
Boris Cherny (creator of Claude Code) described a mid-August 2026 experiment: a Slack channel proj-claude-maintains-apps where Claude Tag runs daily routines across iOS, Android, Desktop, web, CLI, and Agent SDK — crash fuzzer, duplicate-abstraction unifier, dead-code remover, "abstraction police." Over "the last few weeks" those routines opened 388 PRs, of which 180 were merged after Claude Code Review plus human review. When a PR is wrong, they ask Claude to tune the routine so the next day is better (X post by @bcherny, 2026-08-13). That is the same outer-loop pattern (scheduled isolated jobs + review gate), now used as day-to-day app maintenance rather than a one-off coding session.
Two product changes in the same week reduce babysitting inside a session: Claude Code auto mode became the default permission mode on 2026-08-14 (a classifier reviews shell commands; Anthropic reported 89% catch rate on dangerous commands vs 14% for manual approval) (X post by @ClaudeDevs, 2026-08-07); Desktop gained an auto-continue checkbox that resumes a session when the usage limit resets (X post by @ClaudeDevs, 2026-08-13). Auto-continue is a quota bandage, not an architecture: the all-day loop still has to survive a daily cap.
Karpathy's June 2026 note on Claude Tag frames the UX as a "self-contained, persistent, asynchronous entity with org-wide tools and context" — the third LLM UI paradigm after website and downloadable app — but only after "under the hood engineering" for tools, compute environments, memory, and security (X post by @karpathy, 2026-06-23). Persistence here is org-inline presence, not "one context window that never dies."
Guardrails that keep a day-long loop from eating itself
Sources agree on a short list of failure modes. They are operational, not model-quality:
| Failure | What it looks like | Mitigation cited |
|---|---|---|
| Overlapping wakes | Two cron ticks corrupt state.md | File lock + stale-PID check (DEV Community) |
| Context bloat | state.md grows; every loop reloads the journal | Hot state ≤4 KB; cold knowledge on demand (DEV Community); OpenClaw: trim HEARTBEAT.md (heartbeat docs) |
| Activity ≠ progress | 30 loops of self-referential blog posts; refactoring the same component twice | Track outcomes (git push, tests) not actions (DEV Community; Sam French) |
| Optimism feedback | State says "great progress" so the next loop believes it | Verifiable facts only in state (DEV Community) |
| Runaway retries | 47 failed re-queues in 4 minutes | Exponential backoff, cap, then a review queue (Sam French; SitePoint) |
| Hung session | One CLI process blocks the queue | timeout around the agent; --max-turns; dedicated branch (SitePoint) |
| Quota | Routine/subscription cap mid-day | Daily routine caps (routines docs); Desktop auto-continue (@ClaudeDevs); cheaper heartbeat model + quiet hours (OpenClaw) |
| Unsafe autonomy | Spend / post / delete without a human | Approval-request files the next loop reads (DEV Community); routines inherit connector + network scope, no mid-run permission picker (routines docs); Cursor: secrets via OIDC, not long-lived keys (Cursor) |
SitePoint's diagnosis of why agents "lose the plot after an hour" is the same mechanism: context overflow, invented file trees, rewrite of working code, intent drift that tests do not catch. The prescribed architecture is isolated sessions + committed memory + human review of drift (SitePoint).
Workflow vs agent: do not put the scheduler in the model
Anthropic's December 2024 (still-linked, tooling-landscape note added) "Building effective agents" essay draws the line that still organizes 2026 products: workflows are LLMs on predefined code paths; agents are LLMs that dynamically direct their own process. Default to the simplest thing that works; add agent complexity only when the number of steps cannot be hardcoded. Agents cost more and can compound errors; wrap them in iteration caps and a cost budget (Building effective agents).
Applied to all-day loops, that distinction is load-bearing:
- The outer loop (cron / heartbeat / routine trigger / queue drain) should be a workflow: deterministic, one-unit-per-wake, lock, backoff, notify-on-fail.
- The inner loop (research this source; open this PR; triage this alert) can be an agent, because the step count is not known in advance.
French's SQS daemon and the DEV cron script are workflows around claude -p. Claude Code Routines are a hosted workflow that starts an agent session. OpenClaw's heartbeat is a workflow that usually no-ops (HEARTBEAT_OK) and only spends tokens when HEARTBEAT.md has something to do.
A research bot that already has a durable queue (this vault's QUEUE.md) is already on the winning side of that split: drain one pending entry per wake, promote + ingest as separate stages, do not pass --auto unless a human wants the chain. The 2026 sources do not argue for replacing that with a single always-on session.
What this means for a research bot (pattern only)
This pass is about the pattern, not a product to scaffold. Mapped onto a stack that already has weekday cron, a QUEUE.md drain, Cursor cloud agents for wiki/code PRs, and an X ingest pass, the cited material says:
- Keep the outer loop a drain, not a daemon that never exits. One pending entry per invocation is the same "one task per run" rule French and SitePoint landed on.
- Durable state is the queue + wiki + git, not the session. Hot state is the next
pendingrow and the question page; cold state is already-ingested sources. - Use isolated cloud runs for the inner work (Cursor Cloud Agent / Claude Code routine / headless CLI) so a hung or quota-killed session cannot corrupt the queue. Cursor's own docs: treat the agent as low-context; put conventions in
agents.md/ skills (Cursor). - Heartbeat is for cheap "is there anything?" checks, not for burning a frontier model every 15 minutes. OpenClaw's cost table is the cautionary number (heartbeat docs).
- Human review stays at the merge/ingest gate, the way Cherny's 180/388 merge rate still required Claude Code Review + a human (@bcherny).
- Do not invent a new app. The sources that work are a scheduler + a queue file + an isolated agent + a review surface. That is already the vault's skill lifecycle (
queue-next→ research →clipping-promote→ingest-pending→queue-done).
Contradictions and open questions
- "Best" is not resolved to a product. Routines, Cursor Cloud Agents, OpenClaw heartbeat, and a 50-line cron script implement the same outer loop. No source in this pass ran a bake-off on a research-wiki workload. Status: narrowed to a pattern, not resolved to a stack.
- Always-on heartbeat vs scheduled drain. OpenClaw optimizes for proactive "check and maybe notify." Claude Code Routines and French/SitePoint/DEV optimize for "do the next queued unit, then stop." For a research queue with promote+ingest gates, the drain is the better fit on paper; that is an inference from architecture, not a measured comparison.
- Fresh session vs persistent memory. Routines clone the default branch every run and start a new session (routines docs). OpenClaw keeps workspace files (
HEARTBEAT.md, memory, dreams) across heartbeats (heartbeat docs). Both persist files; neither relies on one context window lasting all day. The remaining uncertainty is how much workspace memory a research bot should rewrite each wake without optimism-compounding (DEV's warning). - Quota vs "throughout the day." Routine daily caps (5/15/25) plus subscription usage mean a Max-plan Claude Code routine cannot literally fire every hour all day without overage (routines docs). Auto-continue only resumes after reset (@ClaudeDevs). An all-day research loop therefore needs a cheap outer ticker (cron/heartbeat on a small model) and expensive inner runs only when the queue has work.
- Linear Loops may be the team-governance version of the same pattern (shared config + run history). Official pages timed out; treat as an unconfirmed product mention until fetched.
- Vintage: Cherny's 388/180 PR numbers and auto-mode default are 2026-08 snapshots (capability-tracking discipline). Re-validate before treating merge rate or classifier catch-rate as current.
Provenance
Rounds run: 3 of 3 (round 3 was official-architecture + limits; no further drill would change the "pattern, not product" conclusion)
Sub-questions by round:
Round 1 (broad survey):
- What operational patterns (queue, cron, lock, durable state) do practitioners use for unattended all-day agents?
- How do commercial products (Cursor Cloud Agents, Claude Code, issue-tracker loops) implement that outer loop?
- What failure modes break all-day loops, and what mitigations are documented?
- Is durable filesystem/queue state the consensus replacement for in-context memory across hours?
- Is there a single "best" architecture, or does it depend on task class?
Round 2 (drill-down):
- What do official Claude Code Routines docs say about fresh sessions, triggers, and daily caps? — targeting the productized outer loop
- How does OpenClaw's heartbeat differ from a queue drain (cost, no-op,
HEARTBEAT.md)? — targeting always-on vs drain - What does a week of unsupervised coding (French) add on backoff, TODO.md, and "push or it didn't happen"? — targeting failure modes
Round 3 (resolve remaining uncertainty):
- Does Anthropic's workflow-vs-agent split say the scheduler should stay a workflow? — targeting whether "best" is an agent framework or a coded drain
Anchor source (Grokipedia, fetched before round 1):
- Agentic workflow — 25,017 chars extracted (capped) — perception–reasoning–action inner loop, memory split, single-agent vs multi-agent; used as vocabulary, not as 2026 product evidence.
X sources (X MCP: search_news for discovery only — Grok news-cluster summaries were not cited; get_users_by_usernames + get_users_posts + get_posts_by_id for permalinks; search_posts_all not used):
- 5 items surfaced as citable posts (all
fetch_method: x-mcp/get_posts_by_idorget_users_posts) - X post by @bcherny (2026-08-13) — Slack
proj-claude-maintains-apps+ daily routines; 388 PRs / 180 merged — fetch_method: x-mcp - X post by @ClaudeDevs (2026-08-13) — Desktop auto-continue after usage-limit reset — fetch_method: x-mcp
- X post by @ClaudeDevs (2026-08-07) — auto mode default 2026-08-14; 89% vs 14% dangerous-command catch — fetch_method: x-mcp
- X post by @karpathy (2026-06-23) — Claude Tag as persistent async org-inline entity — fetch_method: x-mcp
- X post by @steipete (2026-08-15) — team building OpenClaw with OpenClaw; session URLs as coordination — fetch_method: x-mcp
URLs fetched (8 successful, 3 failed):
Round 1:
- Cursor Cloud Agent best practices — official — environment-first, agents.md/skills, tool shaping
- How to Run Claude Code as an Autonomous Agent (With a Cron Job) — practitioner blog — cron + lock + small state.md
- Running AI Coding Agents for 13 Days Straight — practitioner guide — isolated sessions, CLAUDE.md, commit-per-task
[Failed: https://linear.app/now/introducing-loops]— timeout
Round 2:
- Automate work with routines — official — triggers, fresh clone, daily caps, no mid-run permissions
- Introducing routines in Claude Code — official (2026-04-14) — cloud-hosted scheduled/API/GitHub routines
- OpenClaw Heartbeat System — community docs — interval, HEARTBEAT_OK, cost table
- How I Let AI Agents Write Code While I Sleep — practitioner (2026-04-08) — SQS + TODO.md + backoff
[Failed: https://linear.app/docs/loops]— timeout
Round 3:
- Building effective agents — official (2024-12-19; page notes tooling landscape has changed) — workflow vs agent
[Failed: https://cursor.com/docs/cloud-agent]— timeout (best-practices page succeeded in round 1)
Tools used: WebSearch, WebFetch, grokipedia-fetch (_lib/grokipedia.py), X MCP (search_news, get_users_by_usernames, get_users_posts, get_posts_by_id). search_posts_all skipped (user-OAuth 403).
Generated: 2026-08-18 15:20 UTC