DeepSeek Harness Scheduled Tasks: Persistence & History

DeepSeek Harness v0.1.7-rc.2 includes scheduled tasks and time context. The shipped feature set is disabled by default and must be enabled manually. Once enabled, an Agent can create one-time reminders, interval jobs, daily or weekly jobs, and Cron rules. The Host persists them and can deliver a follow-up to the original Session even when that Session is not resident in memory.

One boundary matters from the start: the current “run history” records whether a message was delivered to the Session Inbox. It does not mean the model completed the task or that the user received a system notification.

Check the version and components first

1. Use DeepSeek Harness v0.1.7-rc.2 or the corresponding source revision.
2. Enable Schedule, Time Context, and the relevant UI integration in plugin or feature settings.
3. Reload the Profile and confirm the Agent can create, inspect, edit, and delete scheduled tasks.
4. Create a reminder a few minutes in the future to verify Host time, timezone, and Session delivery.

The release notes and source composition differ in one practical detail: the subsystem is present in the code, but the rc.2 shipped experience keeps it off by default. The existence of Schedule components in source does not mean every installation enables them automatically.

Supported schedule rules

Wall-clock schedules retain an IANA timezone. When daylight saving time, travel, or server timezone changes are involved, inspect the stored timezone rather than only the displayed hour.

How persistence works

The Host owns the Schedule Store, independently of whether a Session is loaded. Each record includes its original Session ID, timing rule, active state, latest delivery receipt, and bounded delivery history. On restart, the Host restores timers only for active tasks.

When a task is due, the Host uses the Session Controller to write a normal follow-up into the original Session. A cold Session can therefore receive the Inbox item before it is loaded again.

Delivery is not completion

The receipt currently proves that the follow-up was persisted to the Session Inbox. It does not prove that:

• the model started or completed a run;
• an external API, script, or browser action succeeded;
• a desktop or email notification reached the user;
• the final output passed a business acceptance condition.

“Delivery history” is therefore a more precise term than execution history. Important workflows still need completion criteria, failure records, and external monitoring.

Restart, missed runs, and duplicate delivery

After the Host has been offline, a recurring task delivers only the latest overdue occurrence instead of replaying every missed interval. This prevents a day of downtime from creating a burst of stale messages.

The Session Inbox and Schedule Store are separate stores, so their writes are not atomic. If the process crashes after the Inbox write but before the delivery receipt is committed, recovery can deliver the same occurrence again. Side-effecting workflows should be idempotent, for example by using the task ID plus scheduled time as a deduplication key.

Editing, deletion, and retention

• Editing uses optimistic comparison. If a delivery changes the task while an old draft is open, the stale edit may be rejected.
• Deletion is permanent and removes both the task and delivery history; there is no recycle bin.
• The current design has no separate pause operation; remove or disable the task through the available control.
• History is bounded by both age and record count. The architecture defaults are 30 days and 200 records, configurable by the Host.

Save the rule, original prompt, and required evidence before deleting an important task.

A practical test sequence

1. Create a one-time reminder five minutes ahead and record its task ID.
2. Close the page while keeping the Host alive, then confirm delivery to the original Session.
3. Create a short recurring task and inspect delivery history and the next due time.
4. Restart the Host and confirm active tasks resume without replaying every missed interval.
5. Test a side-effecting action and verify the deduplication design.
6. Delete the test task and confirm its history is removed with it.

Good and poor fits

Scheduled tasks are useful for reminders, recurring checks, report drafts, and returning follow-up work to an Agent. Payments, deletion, automatic publishing, and other high-risk operations need human approval, idempotency, and an independent audit trail; an Inbox receipt is not sufficient authorization or proof of completion.

Related reading

• DeepSeek Harness v0.1.7-rc.2 update
• DeepSeek Harness dynamic tools and KV Cache
• DeepSeek Harness security boundaries

References

• DeepSeek Harness v0.1.7-rc.2 release
• Host schedule storage architecture
• Schedule hard delete and bounded history
• Web schedule composition