Scheduled Tasks
Put recurring work on autopilot.
Tell ZeroTwo what to run, when to run it, and where to deliver the result. It handles recurring briefs, reports, monitoring, triage, and follow-ups.
Daily revenue report
Pull Stripe and spreadsheet data, explain movement, and send the summary.
Weekly code health report
Review GitHub activity, identify risky changes, and create follow-up tickets.
Nightly competitor snapshot
Monitor pricing, positioning, launches, and campaign changes.
Monthly invoice reconciliation
Compare invoices, payments, and exceptions before close.
How a scheduled task actually runs
A scheduled task is an ordinary ZeroTwo task with a clock attached. You write the goal once, in the same plain language you would use in chat, and ZeroTwo re-runs that goal on the cadence you set — reading fresh data each time rather than replaying an old answer.
What you define up front
Four things: the goal, the apps the run is allowed to touch, the frequency, and where the finished result should go. The goal deserves the most attention, because it is the part that repeats. “Summarize revenue” produces a differently shaped report every week. “Compare this week’s net revenue to the prior four weeks, call out any product line that moved materially, and list refunds separately” produces the same shape every week — which is what makes one week comparable to the next.
What happens on each run
The run opens by planning its steps, then reads from the connected apps — a payments export, a spreadsheet tab, a repository, a chat channel — and works through the plan. Read-only steps proceed on their own. Anything with a consequence stops at an approval gate first: sending the email, writing to the sheet, opening the ticket, changing a record. You see what it intends to do before it does it.
Where the result is delivered
Delivery is part of the task definition, not an afterthought. A run can post to a chat channel, send an email, append rows to a spreadsheet, file issues, or write a document. Pointing a recurring report at the channel where people already discuss it tends to work better than filing it somewhere tidy, because the report arrives next to the conversation instead of waiting for someone to go looking.
Run history and what to check
Each run is recorded with its plan, the apps it used, the approvals it requested, and the output it produced. That history is the fastest way to diagnose a task that has drifted: when a report suddenly looks wrong, comparing the last good run against the bad one usually shows either a source that stopped returning data or a connection that lapsed.
Where scheduling is the wrong tool
Scheduling suits work that is genuinely repeatable and worth reading on a fixed rhythm. It suits one-off analysis badly — something you will read once is faster to ask for directly. It also depends on the connected apps staying reachable: if a token expires or an export moves, the run surfaces the failure rather than guessing, and a person has to reconnect it. Work that requires deciding which sources matter this time is usually better as a prompt you re-run by hand.