followup

kylon workspace followup — kylon workspace help detail

followup — one-shot scheduled agent follow-ups in this room
  kylon workspace followup create (--at <iso_timestamp> | --in <duration>) --message <text> [--title <text>] [--notify-users <user_id[,user_id...]>] [--current-thread | --target-room | --thread-root <message_id>]
    Create a durable one-shot scheduled callback owned and executed by the creating agent. Use this whenever you promise to ping, remind, or check back later.
    Natural-language acknowledgement is not enough; the promise is scheduled only after this command returns a created follow-up ID.

    Follow-ups fire once. They do not recur automatically, and they do not watch App records, threads, Automations, webhooks, or external resources for changes.
    Use an Automation (kylon workspace workflow create) instead for recurring schedules, App-record/webhook triggers, reusable multi-step automations, or durable run history/configuration.
    Do not create an Automation just to remind or ping once.
    If the user asks to keep checking until a condition changes, the follow-up task must explicitly decide whether to create the next follow-up and when to stop.
    The --message text should be the future instruction: what current state to inspect, who to notify, and whether to reschedule.

    Always supply --title: a short, user-facing label in the user's language, starting with "Follow up" (localized) and naming what to check, e.g. "Follow up on #6915 check progress". Describe the follow-up, not a promised outcome; keep execution steps in --message.

    --at: absolute ISO 8601 timestamp.
    --in: relative delay such as 30m, 2h, 1d, or 90s.
    By default, a follow-up created in a thread runs in that thread; one created in a room runs in the creating agent's room session.
    --current-thread: explicitly deliver the follow-up turn in the current thread. Only available from thread turns.
    --target-room: from a thread, explicitly run the follow-up in the creating agent's room session.
    --thread-root: deliver the follow-up turn in a specific existing thread root message.
    --notify-users: user IDs to keep attached to thread delivery context. This affects thread-scoped follow-ups; for room-level follow-ups, mention relevant users in the follow-up message text instead.
    Common create aliases are accepted for recovery: --delay means --in, --task means --message, and --thread means --thread-root.
    --room is only accepted when it matches the current room; follow-ups cannot target arbitrary rooms from another room's turn.
    For "ping me" in a thread, include --notify-users with the requester's user ID when known.
    For "ping me" in the room, include @user_id in --message when known so the fired follow-up visibly notifies them. Use member list or current activation context to resolve user IDs; do not invent them.
  kylon workspace followup list [--status pending|fired|cancelled|failed|all] [--limit <n>]
  kylon workspace followup show <followup_id>
  kylon workspace followup cancel <followup_id>

Note: quote flag values that contain spaces; follow each command's JSON syntax.