Operations

Reactivity

A cron answers when. This page covers the four features that answer everything cron can't: Triggers fire a Routine the moment something changes, Wakeups let an employee check back later, Workstreams carry working state across Runs, and Initiatives let an employee propose new standing work that a human accepts.

Triggers — Routines that fire on change

A Trigger is an event subscription attached to a Routine: when a resource family changes anywhere in the company — a deal moves, mail lands, a Run finishes, a Goal updates — the Routine fires without waiting for its next cron slot. Triggers are managed by admins on the routine's Settings → Triggers card, and the list of subscribable kinds is served from the same registry the app's own live updates run on — anything that refreshes on your screen can fire a Routine.

Gated Routines stay gated. A trigger fire on a routine with approvalRequired enqueues the same Approval a cron tick would — the webhook precedent, verbatim. An event is never a bypass.
A minimum interval bounds every Trigger — 15 minutes by default, floor of 1 minute. However many changes land inside the window, the Routine fires at most once, so a routine that writes the very family it subscribes to converges to one fire per interval instead of a hot loop.

Wakeups — check back later

A Wakeup is a timed follow-up session an employee schedules for itself — "check back on the invoice in two days" — using the schedule_wakeup tool, with a note its future self will read (and cancel_wakeup when the follow-up becomes moot). At the time named, a fresh session starts under the employee's own authority, briefed with that note. The session's report lands on the wakeup and in the employee's journal, so a timer never fires into silence — and if no AI Model is connected when it comes due, the note itself is delivered to the journal instead of being lost. Pending wakeups show in a card on the employee's page.

At most 20 pending wakeups per employee, and at most 90 days out — standing work that far ahead should be a Routine, not a timer.

Workstreams — state that survives the Run

A Workstream is a persistent state document for work that spans many Runs — a migration, a long negotiation, a multi-week cleanup. The employee maintains it with create_workstream, update_workstream, and list_workstreams; each update replaces the document in full, so the latest version is always the whole truth. Binding a workstream to one of the employee's Routines makes every future Run brief open with the latest state — the context seam that used to be journal archaeology.

One active workstream per Routine, so the brief seam stays unambiguous — and at most 20 active per employee.
The terminal states are done or abandoned with a reason. An admin can close a stale workstream from the card on the Routine page.

Initiatives — work an employee proposes

An Initiative is proactive work discovery. An employee that notices actionable slack — a report nobody compiles, a follow-up nobody owns — calls propose_initiative and files the evidence, the case, and the exact Routine it wants:

title: What the initiative is called. Duplicate pending titles are refused.
routine: The name, cron expression — validated at propose time, not on accept — markdown brief, and optional acceptance criteria of the Routine the employee is asking for.
evidence & case: Why this work should exist — what the employee observed, and what running the routine would change.

Admins are paged, and pending initiatives live in their own Initiatives section under the AI nav. Accepting creates precisely the Routine proposed — owned by the proposing employee, scheduled immediately. Declining journals the reason back to the employee, so the next proposal is better aimed. At most 5 initiatives can be pending per employee.