A recurring task needs a durable state

“Review new documents each Friday” leaves basic questions unanswered. Which documents count as new? What if last week's run failed? What if a document was renamed? Where is the output, and who checks it?

Define the trigger, time zone, source scope, cursor or last-success marker, output, and permitted actions. A schedule starts a run. It does not guarantee that the run had access to the right sources or completed successfully.

Design a simple recurring workflow

For a weekly practice-document inventory, keep a manifest with stable IDs and processing status: queued, processing, complete, or review required. Record an output version and the source version it used. A failure should preserve the last successful output and leave a visible exception.

A retry should recognize work already completed. Otherwise the system may duplicate rows or repeat external actions. For extraction, a useful key can combine source identity, source version, and workflow version. Changing the source should trigger reconsideration rather than being mistaken for the old completed task.

Use explicit checkpoints

text
Run ID: 2026-03-20-weekly-inventory
Input scope: Practice folder only
Last success: 2026-03-13, manifest v04
Current output: proposed_inventory_v05.csv
Completed this run: A01–A12
Needs review: A07 unreadable; A09 date conflict
Next action: Process A13–A18
External actions: None
Completion test: Every input has a final status and the output passes validation

Long-running agent systems benefit from progress artifacts that let later sessions reconstruct the state. Those artifacts need checking against the actual environment. An old note declaring completion should not override missing output. [source]

Plan failure before enabling the schedule

Ask what happens if a connector expires, the model times out, or a file changes during processing. Decide which errors can be retried automatically and which require review. Set a budget and stop condition. Keep routine results easy to scan and exceptional results easy to notice.

For deadline-related work, use the authorized practice system as the authoritative record. An AI-generated report can identify a candidate issue, but it should not quietly alter dates or communicate commitments. The exact approval arrangement belongs to the actual task and firm policy.

Try it: a partial run

A task processed 12 of 18 documents before failing. Its final chat message says “Done,” but the manifest still shows six queued. Which state controls?

Check your understanding

The task has not met the defined completion test. Reconcile the actual outputs and manifest, preserve the completed rows, and resume the remaining six. Do not accept a conversational assurance as proof of an external result. A useful recurring system reports partial completion explicitly and provides a route to recovery.

Rehearse the run before enabling external actions

Use a dry run that writes a proposed action log without changing the live record. Deliberately test a missing input, a repeated trigger, and a partial failure. Confirm that the system reports the exception and does not repeat an already completed action on retry. Put approval before any consequential action that needs it; a single approval at the very end is too late if earlier steps have already sent messages or overwritten records.