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 or checkMission.

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