Session Schedule

Session Schedule

Session schedules inject a message into the current session at a future time. They survive tab switches and app restarts, but they are tied to this session's lifecycle.

The MCP tool is scheduleCallback. The skill name is session-schedule.

Routing decision

Should the run stay bound to the current session?
  Yes -> session-schedule (scheduleCallback)
  No  -> schedule (createScheduledTask)

Both one-shot and recurring schedules are supported here. Pick the timing mode, not a different skill.

Workflow

1. Choose timing mode

Provide exactly one of:

• delaySeconds — one-shot delay (1–86400 seconds). Example: 300 for "check back in 5 minutes".
• cronExpression — recurring session schedule. Example: 0 9 * * * for every day at 09:00 local time.

Do not pass both. Do not pass neither.

2. Create the schedule

scheduleCallback(
  message="...",
  name="...",              // optional label for Planning panel / lists
  delaySeconds=300         // OR cronExpression="0 9 * * *"
)

Requirements:

• Must run from an active session. The tool binds to the current session automatically.
• message is injected when the schedule fires. Make it self-contained enough for the agent to act without guessing.
• assistantId is not required; the backend resolves it from the current session.

3. Manage existing session schedules

After creation, use the returned task ID:

• getScheduledTask(taskId) — inspect timing, message, and enabled state
• toggleScheduledTask(taskId, enabled=false) — cancel or pause before it fires
• deleteScheduledTask(taskId) — remove it entirely

The user can also cancel from the session Planning panel Schedules section.

4. Set expectations honestly

• One-shot schedules disable themselves after firing.
• If the session is deleted, session schedules are invalidated; they do not create a replacement session.
• Recurring session schedules keep firing until paused, deleted, or the session is removed.
• Injected messages appear in the chat stream when the schedule fires.

Guardrails

• Do not use createScheduledTask for in-session delays; it creates global tasks and requires assistantId plus cron.
• Do not require .libragent/teamwork.json or teamwork scaffold files.
• Prefer delaySeconds for relative delays; use cron when the user names a wall-clock recurrence.
• When scheduling multiple callbacks, give each a distinct name when possible so the Planning panel stays readable.

Related skills

• schedule — global cron tasks that survive beyond the current session
• delegate — spawn a child session now, not a future injection into this one
• teamwork — only when building multi-agent workspace constitution; not needed for simple session schedules