Event-driven: work that starts when something happens

Scheduled work (syncs on a cron) covers digests and sweeps. But most real work should happen when something occurs — not at 8am, but the moment a prospect replies. Workflows could already declare an event trigger; nothing dispatched to them. This release is the runner (v1.40).

Emit → match → start

curl -X POST -H "Authorization: Bearer $VOCION_TOKEN" -H "Content-Type: application/json" \
  -d '{"type":"prospect.reply","payload":{"dealId":7,"from":"buyer@acme.com"},"dedupeKey":"gmail:msg-abc"}' \
  https://your-install/api/v1/events
# → { "ok": true, "triggered": [ { "slug": "followup", "runId": 812 } ] }

emitEvent finds the active workflows whose trigger is {type:'event', event:'prospect.reply'}, checks each one's optional filter against the payload, and starts every match with the payload as input. A dedupeKey makes redelivery safe — a webhook fired twice runs once. Every event is logged with what it started, so the trail shows why a run exists.

Webhooks are thin adapters

The endpoint is generic on purpose. A HubSpot deal-stage webhook, a Gmail push notification, a calendar "meeting ended," a DocuSign "completed" — each becomes a small adapter that normalizes its provider payload into {type, payload} and POSTs here. The runner doesn't care where the event came from.

The loop is now whole

This is the last of three load-bearing pieces from the last few releases:

1. the team review queue — work routes to the right person,
2. actions — gated writes to the outside world,
3. event triggers — work starts when something happens.

Together: something happens → an agent reads the context and drafts → a gated action is proposed → it lands as an approval card with the right owner → they approve → the system acts → it's logged, and the outcome teaches the next run. End to end, on the platform.