Schedules
The Agent Framework introduces schedules as a way to trigger your agent at specific times with a predefined message. The design question is: what should that message contain, and where should the task knowledge live?
What a schedule is
Section titled “What a schedule is”A schedule is two things: a time trigger (like a cron expression — every weekday at 9 AM, or every Monday at midnight) and a message. When the trigger fires, the message is sent to the agent and enters the same agent loop as any user message — with the full system prompt already in context.
That last part matters. The agent already has its identity, context, and instructions. It already knows who it is, what it can access, and how it should behave. The schedule message only needs to say what to do right now.
Three kinds of schedule messages
Section titled “Three kinds of schedule messages”A schedule message can take one of three shapes, and each one is the right choice in different situations.
1. A nudge
Section titled “1. A nudge”A short message that prompts the agent to do something it already knows how to do.
Run the nightly cleanup.
This works when the procedure is already covered — either in the agent’s instructions, or as an obvious extension of what the agent does. The agent fills in the how from context it already has.
2. A full task
Section titled “2. A full task”A complete, self-contained instruction that tells the agent everything it needs for this run.
Fetch my Oura data for last night. Analyze sleep duration, HRV, and readiness score. Compare to the 7-day trend. Send me a briefing via Telegram with highlights and one actionable recommendation.
This works when the procedure is specific to this schedule and is not needed elsewhere. Putting the full task in the schedule message keeps the knowledge exactly where it is used.
3. A nudge plus a skill reference
Section titled “3. A nudge plus a skill reference”A short message that points the agent to a skill containing the detailed procedure.
Generate the weekly report. Use the weekly-report skill.
This is the right choice when the same procedure is also useful outside the schedule — for example, if you sometimes want to generate the weekly report ad-hoc. The skill holds the procedure. The schedule message triggers it. Both stay clean.
Where task knowledge lives
Section titled “Where task knowledge lives”The key design decision is not “how long should the schedule message be” — it is “where does this procedure belong?”
| If the procedure is… | Put it in… |
|---|---|
| Only used by this schedule | The schedule message itself |
| Used by this schedule and also ad-hoc | A skill (schedule nudges toward it) |
| General enough for every interaction | Instructions |
Avoid duplicating procedures across the schedule message and a skill. If you find yourself writing the same steps in both places, the procedure belongs in the skill and the schedule message should just reference it.
Design principles
Section titled “Design principles”Do not restate identity or context. The agent already has these from the system prompt. Writing “You are a sleep coach with access to Oura data…” at the start of every schedule message is waste — the agent already knows.
Pair schedules with instructions. When the instruction says what to care about, the schedule says when to act on it. A sleep coach’s instructions might say “track sleep trends and flag concerning patterns.” The morning schedule is what actually triggers that work.
One schedule, one purpose. If a schedule message tries to do too many unrelated things, split it into multiple schedules. Each schedule should have a clear job.
When to use a schedule
Section titled “When to use a schedule”A schedule is the right choice when:
- The work should happen at specific, recurring times
- You know exactly what the agent should produce
- The timing is predictable and matters
If the agent needs to stay aware of things between conversations and act only when something warrants it, that is a heartbeat, not a schedule. Schedules execute tasks. Heartbeats watch for them.