Commands

A Command is a named, reusable investigation procedure. Where free-form Workspace Chat trades on phrasing skill, a Command bundles “the right way to look into this situation” so any team member — or the platform on a schedule — can invoke it consistently.

Commands have two firing modes:

• On-demand — invoked from chat as a slash command (e.g., /investigate-namespace).
• Scheduled — fired automatically on a cron, with results delivered to email or Slack.

The same Command definition supports both. You author the procedure once and choose how (or whether) to schedule it later.

Why Commands exist

Three problems Commands solve that free-form chat does not:

1. Repeatability. A new responder doesn’t have to remember (or rediscover) the right phrasing — they pick the slash command and get the same workflow as the senior engineer.
2. Quality floor. When /troubleshoot-checkout-flow always covers the same set of checks, the worst investigation in your team rises to a known baseline.
3. Time-shift. Some investigations should happen on a schedule — every weekday morning, every release window, every hour after a deploy — without a human prompting them. Scheduled commands turn a Command into a recurring digest.

Anatomy of a Command

A Command has, conceptually:

• A name that surfaces in the slash-command picker (/investigate-namespace).
• A scope (workspace, per-assistant, or per-user) that controls who sees it.
• The instructions the assistant should follow when the command fires — what to check, in what order, what to summarize.
• Optional parameters the user supplies at invocation time (e.g., the namespace to investigate).

The assistant still does the actual reasoning when the command runs — the Command is the instruction set, not a hard-coded script.

On-demand commands

Type / in Workspace Chat and the picker shows the slash commands available in the current scope. Picking one runs the procedure as a normal RunSession; the user sees the same response surface they would for a free-form question.

This mode is appropriate when:

• Different people will invoke the same investigation at different times.
• You want a guaranteed baseline of checks regardless of who asks.
• You want self-service: a developer types /onboard-me instead of asking a senior engineer for orientation.

Scheduled commands

A Command becomes scheduled when you attach a cron expression and at least one delivery target (sink). The platform refuses to enable a schedule until both are set — a scheduled command that has nowhere to deliver its result is not useful.

A scheduled run is functionally identical to a slash invocation, with three additions:

Addition	What it controls
Cron expression	When the run fires. Common patterns: a daily morning digest, an hourly post-deploy check, a weekly review.
Run-as identity	Whose workspace permissions the run executes under. Typically an admin or service identity, since recipients depend on the run completing reliably.
Sinks (delivery targets)	Where the result goes: an email address, the entire workspace member list, a Slack channel the RunWhen app can post to, or a Slack incoming webhook.

Optional controls:

• Pause / resume — Stop scheduled firing without losing the configuration; the same command can still be invoked on-demand.
• Run budget — Cap total scheduled executions before the schedule disables itself (useful during evaluation).
• Run now — Force an immediate run on the same path the cron uses, for testing.
• Execution history — Inspect past runs, per-target delivery status, and the artifact that was sent.

Scheduled vs event-driven

Scheduled commands and Workflows overlap in spirit but differ in trigger:

Trigger	Use a…
Time (cron) — daily digest, hourly health check	Scheduled command
External event — incoming alert, webhook, SLO violation	Workflow

A scheduled command answers “every weekday at 9 AM, summarize Flux health”. A workflow answers “when this PagerDuty incident fires, start an investigation”.

Where Commands sit in operational context

Commands are one of three levers — see Rules, Knowledge, and the Building Operational Context guide — for adapting an assistant to your team. Rules tune interpretation; Knowledge supplies facts; Commands provide standardized starting points.

Anti-patterns

• Putting one-time investigation steps in a Command. A Command is for repeated procedures; if it runs once, it is a chat session.
• Encoding interpretation rules inside a Command’s prompt. That belongs in a Rule so it applies across all invocations, not just this one.
• Scheduling a Command without a clear recipient. A daily digest with no audience accumulates artifacts no one reads. Decide who consumes the output before you turn on the cron.

Where to use this in the UI

For the in-product workflow — creating Commands, attaching schedules, picking sinks, reviewing history — see Use → Workspace Studio → Commands and Scheduled commands.