Common foundation

Scheduled routines without runaway costs

Four orchestrators (morning, evening, weekly, monthly) driven by plans written in files, rather than twenty scattered tasks.

Associate prof. (MCU-PH)Full prof. (PU-PH)Scheduled taskSkillArtifact1 session, then fine-tuning

Redesigning routines: fourteen scattered tasks merged into four orchestrators.Animation of a real tool · fictitious data
The system map: sources, storage, orchestrators, skills and artifacts.
The system map: sources, storage, orchestrators, skills and artifacts.

Screenshot of a real tool · fictitious data, names blurred

The problem

The temptation is to create one scheduled task per need. After two months you have twenty-five of them, each reloading its own context, stepping on one another, sending six notifications a day and eating up a significant share of your quota.

A typical week of routines

Figure. A week of routines: three daily, one weekly, one monthly.

Step-by-step method

  1. Group them into four orchestrators:

    • MORNING (daily): health check, email triage, roadmap for the day;
    • EVENING (daily): second email pass, update of ongoing projects, pending decisions;
    • WEEKLY (Friday): academic deadlines, thesis defences at D-14, literature watch, month-ahead horizons;
    • MONTHLY (the 1st): CV, activity history, file index, backup.
  2. A one-line prompt: “read your run plan”. The plan is a Markdown file (_SYSTEME/ORCHESTRATEURS/PLAN_MATIN.md). Adding a watch becomes adding a line to a file, not creating a task.

  3. Set a budget: a cap on tool calls per run, a single pass, a consumption log. A lighter model is enough for most scheduled tasks; check which model the task is created with.

  4. Monitor: a status-light page (green, amber, red) fed by the orchestrators themselves, to detect silent failures.

  5. Notify only when an action is expected.

  6. Check the state after any pause: after a general pause of tasks, list those that are active, paused or disabled, and only re-enable with your approval.

  7. An incident log: when a source is unavailable (mailbox not connected, index too large, lost mount), the routine says so, proposes a workaround, and never concludes “nothing new”.

Deliverable

Four tasks, four plan files, one shared rules file, a log and a monitoring page.

Lessons learned

  • A silent failure (attachment extraction broken for two weeks) justified the monitoring page.
  • A plan too heavy for its cap gets cut off: two short runs are better than one long one.
  • Replaced tasks are renamed “ARCHIVE” and disabled, never deleted.

Starter prompt

Here is the list of my scheduled tasks. Propose grouping them into 4 orchestrators, write a Markdown run plan for each, and estimate consumption before/after. Do not create or modify any task without my approval.

← Back to the triptych