Core concepts

Routines & Runs

A Routine is a scheduled, recurring piece of AI work. Cron expression, markdown brief, on/off switch. Every execution becomes a Run with captured logs you can read line by line.

Where they live

Routines have their own section in the nav, under AI → Routines. That list is company-wide: every routine, every employee, one page. Filter it by the AI Employee a routine is assigned to, or by health — Active, Paused, Needs attention. Company Tags give you another filter for grouping related routines across employees.

Clicking a routine opens its detail page: Overview, Brief, Runs, and Settings. Each AI employee still links to their own slice of that list — same page, filtered to them.

Anatomy

name: What humans call this routine.
cron: A standard 5-field cron expression. Rendered as a human-readable schedule next to the input field.
body: Markdown brief — what the employee should do when this fires. Stored on Routine.body.
enabled: Boolean. Disabling pauses the schedule without losing the row.
approvalRequired: Optional. If true, the runner records the intended action and blocks it on a human ✓ via the Approval entity.
model: Optional. Which of the employee's AI Models this routine runs on. Defaults to Inherit — whichever model is active for the employee. See Picking a model.
timeoutSec: Hard timeout in seconds. The runner aborts the in-process agent after this long and marks the Run timeout. Defaults to 60 minutes and is editable per routine (10s – 6h) from the routine editor — raise it for long jobs, lower it to fail fast.
catchUpPolicy: What to do about slots missed while the server was down. Run once (the default) fires a single catch-up run; Skip declines it when the slot is already more than a minute late. See Downtime and recovery.
maxAttempts: Total attempts per scheduled occurrence, counting the first. 1 by default — no retry. Paired with retryBackoffSec and retryOnTimeout.
browserEnabledOverride: Optional per-routine override of the employee's browser toggle — force it on for a research routine, or off for one that must never touch the web. Unset means "inherit from the employee".

Scheduling

Routines use node-cron, the standard 5-field syntax:

text

┌───── minute (0 - 59)
│ ┌─── hour (0 - 23)
│ │ ┌─ day of month (1 - 31)
│ │ │ ┌─ month (1 - 12)
│ │ │ │ ┌─ day of week (0 - 6, Sunday = 0)
│ │ │ │ │
0 9 * * 1-5   →  weekdays at 09:00
*/15 * * * *  →  every 15 minutes
0 17 * * 5    →  Fridays at 17:00

The editor previews the cron in plain English next to the field, so you can sanity-check before saving.

The brief

The body is markdown the model reads at run time. Keep it short and verb-first. Reference a Skill by name if the playbook already exists; otherwise describe the desired outcome.

markdown

# Morning brief

Every weekday at 09:00, post a 5-bullet summary of:
1. Stripe revenue for the last 24h (call `reconcile-stripe-payouts`)
2. New customer signups (Postgres connection "prod-read")
3. Open PRs assigned to humans (GitHub connection "main")
4. Anything new in #alerts since yesterday
5. One sentence of your own opinion about the day

Post it to the #morning channel.

Parallel delegation

Chat turns and Routine runs include delegate_parallel_work. An AI employee can split an objective into independent briefs, run up to four temporary copies of itself at once, and receive their ordered results before it writes the final answer or takes follow-up action. Each worker uses the same Soul, Skills, AI Model, Grants, secrets, and timeout as its parent.

markdown

Research our weekly launch brief in parallel:

1. Summarize customer feedback from the support mailbox.
2. Compare this week's Stripe metrics with last week.
3. Review merged GitHub pull requests for customer-visible changes.

Verify the three results, resolve any disagreement, then post one concise brief to #launch.

A delegation call accepts up to eight briefs, runs at most four at a time, and a top-level turn can delegate twelve briefs in total. Temporary workers cannot delegate again.
Workers receive only their self-contained brief, not the parent chat history. Include the relevant dates, data sources, constraints, and expected output in each brief.
Workers share the employee's working directory. Parallel reads are safe; for writes, assign distinct files and avoid concurrent git operations or overlapping edits.
Delegation multiplies AI Model usage. The parent Run timeout still applies to every worker and aborts the whole group when it expires.

Employees manage their own routines

You don't have to click through the editor yourself — every AI employee holds built-in tools for the full routine lifecycle: list_routines, create_routine, update_routine, and delete_routine. Ask an employee in chat to set up a weekly report, move it to Fridays, rewrite its brief, or pause it, and they edit the existing routine in place —update_routine covers rename, re-schedule, brief rewrites, and the enable/disable switch, so nothing forces a duplicate.

Every change made this way is written to the audit log, and creating or deleting a routine also lands in the owning employee's journal, so the humans can always see who rescheduled what.

Picking a model

An employee can hold several AI Models and keeps one active. By default a routine runs on that active model — the Model field in the routine editor reads Inherit, and the routine follows the employee whenever you switch their brain.

Pick a specific model instead to pin it. The routine then always runs on that model regardless of which one is active. This is how you put a noisy hourly digest on a cheap local endpoint while the employee's chat stays on a frontier model — or the reverse, pinning the weekly board report to your strongest model.

You can only pin a model that belongs to that employee. Register it on the employee's Models tab first.
A pin only affects this routine's Runs. Chat with the employee always uses the active model.
Remove a pinned model and its routines quietly revert to Inherit rather than breaking. The run log names the model it used and whether it was pinned or inherited.

Runs

Every cron tick — and every manual trigger — creates a Run row. The runner runs the in-process agent in the employee's directory and stores the agent transcript — the model's messages and tool trace, not captured CLI stdout — on Run.logContent (capped at 256 KB; longer logs are head-truncated with a notice).

A routine's full run history lives on its Runs tab — every Run, scheduled or manual, with the log viewer.

Status starts at running and ends at one of completed, failed, skipped (no model was connected), timeout, or interrupted (the server stopped mid-run).
The Run detail view tails the transcript while it's running, then renders the full transcript when it's done.
Manual Runs from the "Run now" button live in the same table as scheduled Runs.
Retry a Run that failed, timed out, or was interrupted straight from its run history. It re-triggers the routine immediately, outside the schedule, and opens the live log for the new Run.

Failures are easy to notice: the Home page shows a Failed routines panel for anything that broke in the last 24 hours, and every Journal entry for a Run links straight to that routine's run history — where the Retry button is one click away. Once you've looked at a failure, hit the ✕ on its row to dismiss it — the run stays in the routine's history, but it drops off the panel (and out of the System Health failed-runs count) so it stops nagging the whole team.

Downtime and recovery

Servers restart, containers get rescheduled, laptops go to sleep. Two things can go wrong, and Genosyn handles them differently.

The server stopped mid-run

A Run that was executing when the process died can't report its own outcome — nobody was left to write the row. The scheduler notices on its next heartbeat and marks it interrupted, appending a line to the transcript saying so. Nothing is known about work the employee did after the last captured line, which is exactly why the status is its own word and not failed.

The same pass releases the workload lease the dead run was holding. That matters more than the status: without it the AI employee reads as busy and refuses chat until the lease expires — up to an hour on the default timeout.

The server was off across scheduled slots

A routine fires once when the server comes back, never once per missed slot. An hourly digest that was down overnight produces one run, not twelve. The catch-up run records how many occurrences it stands in for — you'll see +11 missed on the run row — and its brief tells the employee to cover the whole period rather than just the last interval.

Set After downtime to Skip in the routine's Settings when a late run is worse than no run — a 09:00 standup digest arriving at 16:00 is noise. The skipped occurrences are recorded in the employee's Journal so the gap is still visible.

Retries

Off by default. Raise Attempts above 1 in the routine's Settings and a run that failed or was interrupted is re-attempted automatically, up to 5 attempts, waiting a randomized, doubling interval between each (from Retry backoff, capped at six hours). Timeouts are opted in separately, because retrying one re-burns the routine's whole time budget.

Only scheduled runs retry. A manual "Run now," a webhook, or an approved run had someone present who saw the outcome, so nothing respawns behind their back.
A run with a retry pending stays out of the Home Failed routines panel until its last attempt is spent — it isn't something to act on yet. It shows under Runs waiting to retry in System Health instead.
Cancel retry from the run's log view stops the chain without pausing the whole routine — the escape hatch when you've decided to fix the failure by hand.
These are operator settings. AI employees managing their own routines through update_routine cannot change them.

System Health

Settings → System Health (also a card on the Home page) rolls up everything that might be quietly broken for the company, over a 24-hour window:

Failed runs — failures, timeouts, and restarts that interrupted a run, excluding anything already scheduled for a retry.
Runs waiting to retry — an in-progress retry chain, so it's visible rather than silent. Nothing to do.
Stuck runs — still running after 8 hours. Crash recovery clears orphans within a heartbeat now, so anything here means the scheduler itself isn't running.
Skipped runs and employees missing an AI model — routines that never actually ran because no model was connected.
Approvals waiting too long, email delivery failures, and integration connections in an error/expired state.

Every row deep-links to where you fix it — the routine's run history, the employee's model settings, the approvals inbox, or the relevant settings page. It is read-only and computed live from existing data, so there is nothing to configure.

Approvals

Some routines should not auto-fire. Flip approvalRequired on and the runner stops the moment the routine would take a sensitive action — paying a Lightning invoice, sending an email, hitting a third-party API. The action is recorded as an Approval row; a human clicks ✓ in the inbox and the call is replayed.

Built-in approval kinds

routine — the whole Run is gated.
lightning_payment — auto-issued when a payment exceeds the per-connection cap. See the Integrations page.