#long-running jobs and tasks from multiple parts
1 messages · Page 1 of 1 (latest)
@winged swan any ideas?
@winged swan wdyt?
My take: for “fetch 100 websites” style work, don’t let the main chat turn be the worker. Treat the main agent as the coordinator and move the slow parts into background/sub-agent runs.
Concrete shape I’d recommend:
- First sanity check: what version?
openclaw --version— long-task/subagent delivery has had fixes, so being current matters. - Use sub-agents for the heavy pieces: “spawn sub-agents in batches of 5–10 sites, write results to a file, then summarize.” That keeps the main session from ballooning/forgetting.
- Make the task self-checkpointing: tell it to write
progress.json/results.mdafter every batch. If the model context compacts or a run dies, the next turn can resume from disk instead of memory. - For Discord, prefer thread-bound/persistent sessions for follow-up work, so completion and follow-ups land in the right thread.
- Inspect the task ledger when it “disappears”:
openclaw tasks list, thenopenclaw tasks show <runId-or-sessionKey>, andopenclaw tasks auditif things look stale. - If sub-agent completion doesn’t post, check route/notify behavior: stale/missing requester route,
NO_REPLY/ANNOUNCE_SKIP, timeout after tool-only output, or channel auth failures can all make it look like it vanished.
Docs worth reading:
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/automation/tasks
https://docs.openclaw.ai/help/faq
Tiny prompt improvement that helps a lot:
“This is a long-running task. Use sub-agents for independent batches. Keep a progress file. After each batch, verify output exists. When all batches finish, send one final summary with counts, failures, and file paths.”
If they’re already doing that and it still forgets/fails to announce, I’d ask for openclaw --version plus openclaw tasks show <id> output next. That’ll tell us whether it’s model behavior, task timeout/lost state, or delivery routing. 🦞