Skip to content
CodexWork
Any AIChatGPTClaudeCodexCopilotGeminiGrokOther agents

Use materials in your tool

All tool notes →

CASE 03 / Designed, not run

What an agent needs to own a weekly job

A recurring job fails at the handoffs: where it reads, where it remembers, where it delivers. Here is a complete template, built around a fictional three-page watch.

Material
Synthetic data
Evidence
Designed, not run
Source checked
2026-10-13
In this case

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.