> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kylon.io/llms.txt
> Use this file to discover all available pages before exploring further.

# followup

> `kylon workspace followup` command reference.

```text theme={null}
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, workflows, webhooks, or external resources for changes.
    Use workflow instead for recurring schedules, App-record/webhook triggers, reusable multi-step automations, or durable run history/configuration.
    Do not create a workflow 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.

    --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.
```