Suppose your team wants someone to watch three official product pages every week. Everyone nods. Then the weekly job quietly stops, because nobody wrote down where the last result lives.
Four distinctions explain most of these failures:
- A generated plan is not a saved schedule.
- An account connection is not source access.
- A job that started is not an output that was delivered.
- One successful run is not long-run reliability.
The fictional watch
Our example is invented. The team uses a fictional pricing page, a fictional API changelog, and a fictional data-retention policy page. They are named only so the template has concrete values.
The agent should report only decision-changing changes. A reworded footer isn’t one. A price tier that moves, or a retention period that shortens, is. Each reported change needs:
- the URL
- the as-of date
- old meaning and new meaning
- the affected task on your team
Unchanged pages keep their last-seen date. A page that couldn’t be fetched is not “no change.” It’s a source failure, and it gets its own line. Say what the agent does next: retry once, then stop and report. A failed source stays visible until it’s resolved.
The source change watch pack has the full instruction and synthetic samples.
Why the template exists
Vendor docs now describe agents that keep tasks and memory. See Dot tasks and memory, Dot controls and automations. Claude’s scheduling page distinguishes remote recurring tasks from legacy local ones that need a connected desktop. These are documentation, and they differ from each other. Your handoff should not depend on any one product’s memory.
One public bug report shows why delivery needs its own check. Codex issue #52197, dated October 8 and 11, reports messaging from Codex to a Dot failing while the Dot interface itself worked. We read that as one reported case, not a product-wide outage. It shows that a task can be alive in one place while its message fails to arrive in another. Verify the end of the chain.
The handover page
| RESPONSIBILITY | One sentence: what this agent owns, and what it does not. |
|---|---|
| INPUT LOCATION AND ACCESS | Exact URLs or paths. Who granted access. Test: one successful read, logged. |
| CADENCE AND TIMEZONE | Weekly, Monday 09:00, Asia/Singapore (example). Who triggers it if no schedule is saved. |
| DELIVERY LOCATION | Where the report lands. Who reads it. How you confirm arrival. |
| VERSIONED STATE | File name and place of the last-seen record. Dated entries; never overwritten, only appended. |
| DONE CONDITION | What a finished run contains. What ends the whole responsibility. |
| ALLOWED ACTIONS | Read pages. Compare to state. Write the report. Update state. |
| APPROVAL-REQUIRED ACTIONS | Anything sent outside the team, published, purchased, or deleted. |
| FIRST ACTUAL RUN | Run once with a human watching. Check the output against the pages. |
| RECOVERY AND PAUSE | Source fails: retry once, then report failure, keep last-seen. Pause: say who can stop it and how it is recorded. |
| FRESH RECEIVER RESUME | A new agent (or person) reads only this document and the state file, and continues without asking the previous owner. |
The handoff template
Fill in every line. Short answers are fine.
RESPONSIBILITY
One sentence: what this agent owns, and what it does not.
INPUT LOCATION AND ACCESS
Exact URLs or paths. Who granted access. Test: one successful read, logged.
CADENCE AND TIMEZONE
Weekly, Monday 09:00, Asia/Singapore (example). Who triggers it
if no schedule is saved.
DELIVERY LOCATION
Where the report lands. Who reads it. How you confirm arrival.
VERSIONED STATE
File name and place of the last-seen record. Dated entries; never
overwritten, only appended.
DONE CONDITION
What a finished run contains. What ends the whole responsibility.
ALLOWED ACTIONS
Read pages. Compare to state. Write the report. Update state.
APPROVAL-REQUIRED ACTIONS
Anything sent outside the team, published, purchased, or deleted.
FIRST ACTUAL RUN
Run once with a human watching. Check the output against the pages.
RECOVERY AND PAUSE
Source fails: retry once, then report failure, keep last-seen.
Pause: say who can stop it and how it is recorded.
FRESH RECEIVER RESUME
A new agent (or person) reads only this document and the state
file, and continues without asking the previous owner.
The last line is the real test. If a new receiver can’t resume from this page and the state file, the handoff isn’t finished. The history lives in the documents, not in anyone’s head or a product’s memory.
Two places the template protects you
Schedules. A tool may generate a convincing weekly plan. That’s a plan. Unless a product actually saves and runs it, nothing recurs. Our recurring planner helps you write the cadence down in browser-local form. It does not run anything or save a schedule. You take it to the environment you chose, then confirm it’s saved there.
Handoffs. The handoff builder turns your answers into the document above. It too stays in your browser.
What a good first week looks like
- Run one: you watch, and compare to the pages yourself.
- Check delivery: did the report land where you said?
- Check state: is the last-seen file updated and dated?
- Break it on purpose: block one source and see whether it reports failure rather than “no change.”
If those hold, you have one good run. That is all it is. Reliability over months is a separate question, and only time answers it. Review the first few weeks, then decide whether to extend trust.
Scope and sources
Limitations. The watch is fictional. We tested no recurring runs, no scheduling and no delivery in any environment. The GitHub issue is one user’s report, and we haven’t reproduced it. Product features and plan availability change, so check the linked pages for current details.
Next task: Open the handoff builder, fill it in for one weekly job you own, and give the result to someone who has never seen it. Their questions show you what is missing. The recurring planner helps record the cadence; it does not activate a schedule.
Source note. Provider documentation and the linked public issue were checked October 13, 2026. The fictional watch and handoff template are our designed method. No recurring execution or saved schedule is established by this chapter.