Skip to content

Routine Design

Routines are autonomous scheduled tasks owned by individual minions. They execute skill pipelines on a cron schedule without HQ involvement.

{
"name": "morning-report",
"pipeline": ["write-daily-report", "send-to-slack"],
"content": "Write a daily report and post it to the team Slack channel",
"cron_expression": "0 9 * * 1-5",
"minion_id": "<uuid>",
"workspace_id": "<uuid|null>"
}
FieldTypeDescription
namestringRoutine name
pipelinestring[]Ordered list of skill IDs to execute
contentstring|nullDescription (Markdown)
cron_expressionstring|nullCron schedule
minion_idstringUUID of the owning minion
workspace_idstring|nullOptional workspace this routine is bound to. null runs the routine in minion-wide context (only minion-wide secrets/vars are injected); a UUID binds it to a workspace, so workspace variables and workspace-scoped secrets are also exposed at execution time. MINION_ROUTINE_WORKSPACE_ID is exported to the session in either case

All skills in a routine pipeline run within a single CLI session. This means context is preserved across steps — the output of one skill is available to the next.

flowchart LR
A["write-daily-report"] --> B["send-to-slack"]

When the CLI session completes, the runner reports the outcome (success/failure and a log-tail summary) to the minion’s local outcome API automatically.

Both routines and workflows execute skills on a schedule, but they differ in scope and governance. A routine runs a linear skill pipeline within one minion; a workflow is a project-scoped DAG (node/edge graph) that can branch, fan out, and span multiple minions.

Think of routines as a personal crontab and workflows as a CI/CD pipeline.

AspectRoutineWorkflow (DAG)
ScopeOne minion, self-containedProject-wide, multi-minion coordination
ShapeLinear skill pipelineNode/edge graph (parallel, fan-out/join, conditional)
OwnerIndividual minionProject
Role assignmentNone — the owning minion runs everythingPer-node roles (PM / Engineer)
Review gatesNoneReview nodes with human/minion approval and revision loops
VersioningNone — always uses latest skill versionsFull version history with immutable snapshots
Execution trackingLocal only (minion-side, last 200 runs)Full audit trail in HQ database
TriggerCron on minion (autonomous)Cron or on-demand from HQ

Use a routine when:

  • A single minion can complete the entire task
  • No human review is needed between steps
  • The task is a personal habit (daily standup prep, end-of-day review, inbox triage)
  • You want lightweight, autonomous execution

Use a workflow when:

  • Multiple minions need to collaborate (e.g., engineer analyzes, PM reviews)
  • Human approval gates are required before certain nodes
  • The task has real dependencies — parallel branches, fan-out over a list, or conditional routing
  • You need an audit trail of every execution with node-level tracking
  • Reproducibility matters — pinning exact skill versions is important

The same skills can be used in both routines and workflows depending on the required governance level.

As a routine (one minion, autonomous):

flowchart LR
subgraph "Routine: morning-report (weekdays 9:00)"
A["write-daily-report"] --> B["send-to-slack"]
end

As a workflow (project-coordinated DAG, with a review gate):

flowchart LR
subgraph "Workflow: team-daily-report"
A["Skill: write-daily-report<br/><i>engineer</i>"] --> R{"Review<br/><i>pm</i>"}
R -->|approved| C["Skill: send-to-slack<br/><i>pm</i>"]
R -. revision .-> A
end

Notice that write-daily-report and send-to-slack are the same skills in both cases. The difference is how they are orchestrated — a workflow can add review gates, branches, and fan-out — not what the skills do.

Standard cron expressions are supported (same syntax as workflow schedules).

ExpressionExecution timing
0 9 * * *Every day at 9:00
0 9 * * 1-5Weekdays at 9:00
0 18 * * *Every day at 18:00
0 0 * * 1Every Monday at 0:00