镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

feat: Add "Schedule for Later" message delivery #5356

Open

Description

@sernst

Motivation

Asynchronous communication is fundamental to distributed teams and respects work-life balance across time zones. Many teams have members in different regions, and immediate message delivery can interrupt sleep, focus time, or off-hours for collaborators. Slack's "Schedule message" feature has become a standard expectation in team communication platforms, allowing users and agents to compose messages now and deliver them at a time that doesn't interrupt recipients.

Buzz currently lacks this capability, which means:

  • Users must manually send messages at specific times or interrupt teammates across time zones
  • Agents cannot respect timezone-aware delivery windows for automated messages
  • Teams lose the ability to queue communications for working hours without external workarounds

Proposed solution

Add a "Schedule for Later" feature that:

  1. Composer integration: Add a "Schedule" button or time-picker in the message composer (alongside "Send now") that lets users specify:

    • Date and time for delivery
    • Optional: recurring schedule or delivery window
    • Display selected delivery time near the send button
  2. Agent support: Allow agents to schedule messages via the CLI/API:

    • buzz messages send --channel <uuid> --scheduled-at <ISO8601-timestamp> --content "..."
    • Messages persist in the harness queue across agent restarts
  3. Queue and delivery:

    • Store scheduled messages durably (relay-backed or local)
    • Deliver at the specified time automatically
    • Show scheduled messages in a "Scheduled" view before delivery
    • Allow editing/cancellation of pending scheduled messages
  4. User experience:

    • Show clear indication in the channel when a message is scheduled vs. sent
    • Display delivery time in local timezone
    • Timezone-aware scheduling for teams across regions (stretch goal)

Alternatives considered

  • External scheduling via cron/Lambda: brittle, requires manual setup per team, no UX integration
  • Relay-side scheduling microservice: adds operational complexity; feature should live in the client for simplicity
  • Draft messages: solves the "compose later" problem but not "deliver later"

Additional context

  • Slack's Schedule Message docs
  • This mirrors a core feature in Discord, Teams, and other async-communication platforms
  • Agents benefit especially: can publish summaries, reminders, and updates outside human working hours
  • Duplicate check: None found in open issues

Activity

  1. ndizazzo commented on Aug 18, 2026

    @ndizazzo

    @sernst @nandanadileep It would be useful to extend the baseline work with a separate UI/UX issue, adding support to the mobile and desktop clients to allow the UI to hook into the underlying APIs to schedule the message...

    Use case:

    My agents hit limits extremely often... being able to set a manual follow up that will land AFTER my limits reset would be EXTREMELY helpful, as the agent could be prompted to continue working after timing out.

  2. fck007 commented on Aug 22, 2026

    @fck007

    A very simple Gmail-style UX would cover a lot of the real-world need here without exposing cron/workflow concepts in the composer.

    Concrete proposal for an MVP:

    • Keep the current send button behavior: click = send now.
    • Add a small chevron / secondary action on the send button, similar to Gmail's Schedule send.
    • The menu could offer a few quick choices (in 1 hour, tomorrow morning) plus Pick date & time….
    • Scheduled delivery should be one-shot by default, not a recurring cron. Recurring automation can remain a separate Workflows feature.
    • Pending scheduled messages should be visible somewhere lightweight so the author can edit or cancel them before dispatch.
    • Most importantly, when the scheduled time arrives, the message should be emitted with the same author identity and mention semantics as a manual send, so @agent mentions wake/trigger the intended agent exactly as if the user had pressed Send at that moment.

    A concrete use case: I may have several long commands already composed for an agent, but its model quota/token window resets in ~1 hour. I want to go offline now, choose Schedule send → 01:05, and have Buzz deliver that command later without setting up an external cron, CLI task, or Workflow.

    That feels like a small composer feature rather than an automation system, and it would make scheduled agent work much more approachable for non-technical users too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions