# 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](./record-types.md) 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](./capabilities.md), [thinking/record-types](./record-types.md), [thinking/layers](./layers.md), [system/dispatch](../system/dispatch.md).