Automations

An Automation is the WHEN of the system — a first-class object binding a trigger to a piece of work: when: {schedule | event} → do: {run a workflow | check a mission}. Missions and workflows contain no trigger logic; automations are the only place time and events live.

The four-object model

The litmus test: workflows are deterministic, missions are agent-driven. If you can write the steps down and they're the same every run, it's a workflow. If discharging it takes judgment about what's needed this time, it's a mission. Either way, the cadence or event that fires it is an automation.

Authoring

One YAML per automation in workspace/<org>/automations/:

# Check a standing mission every weekday morning
slug: morning-briefing
name: Morning revenue briefing
when:
  schedule: "0 12 * * 1-5"   # 5-field cron, UTC
do:
  checkMission: daily-revenue-briefing

# Run a deterministic procedure when an event arrives
slug: reply-followup
when:
  event: prospect.reply
  filter: { pipeline: default }   # optional payload match
do:
  workflow: discovery_followup
  input: { source: event }        # optional fixed input

when takes exactly one of schedule (cron) or event (+ optional filter); do takes exactly one of workflow, checkMission, or job (a built-in server job — deterministic, not an agent). A checkMission automation may add do.prompt — the execution prompt for this cadence's fires (WHAT to do on this schedule); the mission stays the standing context, and the generic scheduled-check brief applies when omitted.

Ownership: every automation rolls up to an owner agent. For checkMission the owner is implied by the mission's own agent; job/workflow automations set a top-level agent: <slug> so the schedule belongs to a visible agent instead of running ownerless.

How it runs

• Schedule-whens materialize as Temporal Schedules, reconciled idempotently by workspace:apply — edit the cron, re-apply, done. The Temporal worker fires automationFire, which dispatches the do.
• Event-whens are matched when POST /api/v1/events receives a matching type + filter (deduped by dedupeKey, so webhook retries are safe).
• A mission check is one lead-agent judgment pass: read the charter, review current state, do only what's needed (skills, tools, proposed actions into the review queue), report — or say "nothing needed" and stop.
• A workflow run executes the fixed steps; approve steps pause it into the review queue as usual.

The dashboard

Dashboard → Team → Automation lists every automation — human-readable cadence ("12

Automations are also inspectable and testable: the card states the authored description, the parameters it runs with, its owner agent, and its last outcome — every fire (scheduled or manual) persists a run row that closes with the result or the error, so a run that scanned nothing, ran clean, or threw are distinguishable afterwards. A Test run control (backed by POST /api/v1/automations/<slug>/run) forces a run through the same fire path Temporal uses, so a manual run exercises the authored do.input; jobs that support it accept a day to replay and a dry-run mode.