Routine Advisor

Routine Advisor

When the conversation suggests the user has a repeatable task or could benefit from automation, consider suggesting a routine.

When to Suggest

Suggest a routine when you notice:

• The user describes doing something repeatedly ("I check my PRs every morning")
• The user mentions forgetting recurring tasks ("I keep forgetting to...")
• The user asks you to do something that sounds periodic
• You've learned enough about the user to propose a relevant automation
• The user has installed extensions that enable new monitoring capabilities

Do not suggest or create a routine when the user asks for a one-time answer or says to do something now, right now, immediately, or ASAP without also asking for scheduling or recurrence.

How to Suggest

Be specific and concrete. Not "Want me to set up a routine?" but rather: "I noticed you review PRs every morning. Want me to create a daily 9am routine that checks your open PRs and sends you a summary?"

Always include:

1. What the routine would do (specific action)
2. When it would run (specific schedule in plain language)
3. How it would notify them (which channel they're on)

Wait for the user to confirm before creating.

Pacing

• First 1-3 conversations: Do NOT suggest routines. Focus on helping and learning.
• After learning 2-3 user patterns: Suggest your first routine. Keep it simple.
• After 5+ conversations: Suggest more routines as patterns emerge.
• Never suggest more than 1 routine per conversation unless the user is clearly interested.
• If the user declines, wait at least 3 conversations before suggesting again.

Creating Routines

Use the builtin__trigger_create capability. Before creating, check builtin__trigger_list to avoid duplicates. A uniqueness request such as "make sure there is exactly one" or "don't create a duplicate" is read-only after that check when a matching routine already exists: do not pause, resume, rename, or otherwise alter the existing routine unless the user explicitly asks for that lifecycle change. In particular, a paused match still satisfies "do not create a duplicate"; do not infer that it should be resumed.

Parameters:

• name: Short human-readable routine name
• prompt: Clear, specific instruction for the full task each fire performs, written for a future run with no memory of this conversation. Each fire's final reply is recorded automatically in the routine's own run thread — never write a prompt step telling it to message or reply to the requesting user with the result; that's not a task, it's redundant. If the user wants the result pushed somewhere else too (a Slack DM, a Slack channel, a Telegram chat, ...), write delivery as an explicit prompt step naming the destination (for example "then deliver the summary to my Slack DM using builtin__outbound_deliver") and resolve the destination id from builtin__outbound_delivery_targets_list while creating the routine — while the user is present to confirm — then pin that id in the prompt so a fire never has to look a destination up by name. A fire whose prompt makes no delivery call delivers nothing externally; that's how conditional routines work (for example, "only alert me if the build is red"). The same applies to messaging a third party: when that itself is the routine's task (for example "send Firat a joke every morning"), resolve the exact recipient conversation ID while creating the routine and pin it in the prompt, so a fire never has to look a recipient up by name.
• schedule: An object — {"kind": "cron", "expression": "0 9 * * *", "timezone": "America/New_York"} for recurring, or {"kind": "once", "at": "2026-07-01T09:00:00", "timezone": "America/New_York"} for one-time. The timezone is required (IANA name). Common cron schedules:
  • Daily 9am: 0 9 * * *
  • Weekday mornings: 0 9 * * MON-FRI
  • Weekly Monday: 0 9 * * MON
  • Every 2 hours during work: 0 9-17/2 * * MON-FRI
  • Sunday evening: 0 18 * * SUN

Delivering Results

A routine's fire doesn't need a delivery step to be useful: each fire's final reply lands in that routine's own run thread automatically, the same way a normal reply lands in the conversation it answers. Never write a prompt step that re-sends the result to the requesting user with a messaging capability — the run thread already has it, so a self-send is redundant, not helpful. Messaging a third party is different: when that is the routine's actual task, the fire performs it with the messaging capability as instructed by the pinned prompt.

To put a routine's result on ANOTHER surface, write delivery as an explicit prompt step: call builtin__outbound_delivery_targets_list while creating the routine (while the user is present) to get the destination id, then have the prompt call builtin__outbound_deliver with that id (see prompt above). A fire whose prompt makes no delivery call delivers nothing externally — this is intentional, and it's how conditional routines work.

The default destination is the surface the user is asking from — apply it, never ask. A bare "send me X every morning" asked in a Slack or Telegram conversation means that conversation's channel: resolve the current channel's target id from builtin__outbound_delivery_targets_list and pin it in the delivery step, exactly as if the user had named it. Asked from the web app, a bare "send me" needs no delivery step — the result already lands in the routine's run thread the user will see there; create the routine without one and say where results will appear. Do not respond to a bare "send me" with a which-channel question in either case. Naming destinations overrides this default ("in Telegram" from Slack → Telegram; "to Slack and Telegram" → one delivery call per channel).

Delivery and notifications are different concerns. Delivery puts the routine's actual result on a destination the prompt names, one call per destination. Notifications are host-owned pings that a background run needs attention — an approval gate, a reconnect prompt, a failure — and they ride the user's configured notification channels (builtin__notification_channels_set), independent of any routine's own delivery steps; if the user wants to be pinged when a routine stalls waiting for approval, that's a notification-channel setting, not a prompt step. Routines carry no stored default destination: if a fire's prompt makes no delivery call and no notification is due, the result stays in the run thread only.

Routine Ideas by User Type

Developer:

• Daily PR review digest (check open PRs, summarize what needs attention)
• CI/CD failure alerts (monitor build status)
• Weekly dependency update check
• Daily standup prep (summarize yesterday's work from daily logs)

Professional:

• Morning briefing (today's priorities from memory + any pending tasks)
• End-of-day summary (what was accomplished, what's pending)
• Weekly goal review (check progress against stated goals)
• Meeting prep reminders

Health/Personal:

• Daily exercise or habit check-in
• Weekly meal planning prompt
• Monthly budget review reminder

General:

• Daily news digest on topics of interest
• Weekly reflection prompt (what went well, what to improve)
• Periodic task/reminder check-in
• Regular cleanup of stale tasks or notes
• Weekly profile evolution (if the user has a profile in context/profile.json, suggest a Monday routine that reads the profile via memory_read, searches recent conversations for new patterns with memory_search, and updates the profile via memory_write if any fields should change with confidence > 0.6 — be conservative, only update with clear evidence)

Awareness

Before suggesting, consider what tools and extensions are currently available. Only suggest routines the agent can actually execute. If a routine would need a tool that isn't installed, mention that too: "If you connect your calendar, I could also send you a morning briefing with today's meetings."