Activation

An activation policy is what wakes an agent. Cron, interval, webhook, message mention, ambient relevance, GitHub event, Discord event, PagerDuty incident — same category. They are configuration, not ontology. Model them as records attached to an agent plus whatever scopes or resources they target. The important property is inspectability: you should be able to ask why an agent woke, when it should wake again, and what it was allowed to touch.

Today this is hardcoded on agent rows: mention (wake on @mention), ambient (debounce + cooldown + Haiku gate), always (every entry; mentions still work). These are implementation shortcuts. The durable model moves them into activation-policy records — see thinking/record-types for the schema.

Automation is composition: agent + activation policy + permissions + tools + target scope. “Post to Discord every hour” = cron policy + x on a send-message tool + access to the Discord-channel resource. “Summarize new issues every morning” = daily policy + read on the GitHub resource + write on the room where the summary lands. “Review every PR on push” = webhook policy + read on the repo + write on the review thread. Same shape every time: event → dispatch → activation → side effect → recorded result. No workflow DSL. No DAG builder. The substrate already is the automation engine.

Scheduling: DO alarms for the wake-up path; a reconciler for the failure path (alarms are cheap, reconciliation makes missed ticks visible). Webhook and other event-driven policies don’t need a scheduler — the event is the clock. Every trigger flows through one generic dispatch(activationPolicy, event) → run path that looks up matching policies, resolves the agent, checks permissions and capabilities, and invokes the runtime. Today’s mention dispatch in packages/core/dispatch/ is a narrow version of this.

The hourly Discord test reduces to a checklist: agent record + Discord-channel resource record + secret available to that resource + tool record (send-message) + permission for the agent to invoke that tool against that resource + activation policy on a one-hour schedule + a run per tick + a session stream / trace + a result artifact with the remote message ID and timestamp. Token revoked = visible run failure. Wording change = session behaviour. Access revoked = permission change. The layers stay clean.

See: thinking/capabilities, thinking/record-types, thinking/layers, system/dispatch.