Scheduled Threads for T3 Code

Scheduled threads

Recurring workflows that open a fresh T3 chat.

A native scheduled-task system for recurring review work—such as the monthly Meta, Rybbit, and PracticeHub cycle—without turning an agent into an unattended production mutator.

What it does

1. ScheduleChoose a recurrence, timezone, project, prompt, and provider.

2. WakeThe server claims the due occurrence exactly once.

3. CreateT3 creates a new durable thread and queues the first turn.

4. ReviewThe run produces a report and stops at existing approval gates.

Recommended architecture

A server-owned scheduled-task store contains the owner, project/environment, prompt, recurrence, timezone, enabled state, provider/model, permission mode, and run history.
A bounded scheduler polls due tasks, claims each occurrence idempotently, creates the thread, queues the prompt, and records success or failure.
Existing orchestration remains responsible for command validation, event persistence, provider sessions, approvals, and turn execution.
The new thread is the user-visible durable record of each scheduled run.

Safety default: scheduled runs use approval-required. The scheduler never grants broader permissions than the task stores, and it never bypasses Meta, website, Cloudflare, or other external approval mechanisms.

Recurrence and reliability

Weekly, fortnightly, and monthly calendar recurrences with explicit IANA timezones.
One next-run timestamp per task; missed runs coalesce instead of replaying every missed occurrence.
A unique task-occurrence key prevents duplicate threads after retries or restarts.
Run states: running, succeeded, failed, and skipped.
Lease timeout makes crashed runs retryable while preserving exactly-once thread creation.
Disabled or deleted tasks stop future runs but never delete existing threads.

Implementation options

Native T3 feature — recommended.

Add schedule storage, a scheduler worker, schedule CRUD, run history, and a safe “new thread + first turn” path. It survives restarts and is manageable inside T3.

External cron/API wrapper.

Fast to prototype, but brittle and not visible or manageable inside T3.

Hermes or Cloudflare trigger.

Useful as a remote trigger later, but it adds authentication and deployment complexity before T3 has a stable scheduling API.

Verification plan

Test recurrence calculation, timezone and daylight-saving boundaries, missed-run coalescing, occurrence idempotency, lease recovery, approval defaults, and thread/first-turn creation. An integration test should advance a test clock and verify exactly one new thread and one queued first turn.