Recommended approach

Schedule T3 conversations without modifying the official T3 app

Build a small standalone macOS helper. It owns the clock and schedule database, then asks the official T3 backend to create an ordinary conversation.

The architecture

The rendered Mermaid diagram is shown first. Use the tabs to switch to the source code, or open the diagram fullscreen.

The helper is separate. T3 remains the conversation engine and the official app remains the user interface.

flowchart LR
  launchd["macOS launchd"] --> helper["Our t3-scheduler helper"]
  helper -->|"authenticated localhost API"| t3["Official T3 backend"]
  t3 --> thread["Normal T3 conversation"]
  thread --> app["Official T3 app"]

What the helper would do

Keep time

Store weekly, fortnightly, or monthly schedules in its own SQLite database.

Run in background

Use macOS launchd to start at login and restart after a crash.

Call T3 safely

Use a Keychain-stored credential and an authenticated local API request.

Prevent duplicates

Attach an idempotency key to each task occurrence and retry only safely.

Record history

Track pending, successful, and failed runs outside T3.

Stay separate

Do not edit T3’s files or write directly into T3’s SQLite database.

Why this is better for us

We do not need to replace the official T3 app.
Official T3 updates can continue normally.
The helper can be updated independently if the API adapter changes.
Created conversations remain ordinary T3 threads and should appear in the official app.
We can later move the scheduler from the Mac to a server without changing the T3 conversation model.

Important limitation: T3 does not yet appear to have a stable public SDK for this. The helper would initially use the current API through a replaceable adapter. If T3 changes that API, we update the adapter rather than rebuilding the whole helper.

What the official project already shows

A previous Server SDK request described external integrations and custom UIs, but was closed as not planned.
A newer RFC proposes an external SDK with createThread, startTurn, and revealThread—the exact kind of boundary this helper needs.
A request for a persistent T3 background service was also closed as not planned, which makes a separate helper practical for our use case.

Integration SDK RFC #6419 · Server SDK #377 · Background service #659

Implementation stages

Create the helper as a standalone TypeScript project.
Implement recurrence, SQLite storage, retries, and idempotency.
Implement a T3 API adapter with a fake-server test harness.
Add Keychain credential storage and a safe setup command.
Add launchd installation, status, logs, and uninstall commands.
Test with a temporary schedule and confirm the official T3 app displays the new thread.

The helper should be built and tested before it is installed as a persistent login service. No official T3 installation needs to be replaced.