Activation
An activation policy defines what wakes an agent.
Examples include cron or interval, webhook, message mention, ambient relevance, GitHub event, Discord event, and PagerDuty incident.
A policy is configuration, not a new ontology. It should be modeled as records attached to an agent and one or more target scopes or resources.
The important thing is not the trigger UI. The important thing is that activation is first-class and inspectable.
See record-types for the activation-policy schema.
Current trigger modes
Two trigger modes govern when agents engage today. Mention agents respond only when @mentioned — immediate, synchronous. Ambient agents also respond to conversation they judge relevant, debounced with a configurable delay so multiple rapid messages produce one considered response rather than a cascade.
Ambient triggers pass through two gates before reaching the LLM: a cooldown check (skip if the agent was the last speaker) and a relevance check (a cheap model judges whether the conversation warrants a response). These gates prevent noise without requiring explicit human direction.
These hardcoded trigger modes move to activation-policy records in the new model.
Automation is composition
An automation is: agent + activation policy + tool permissions + target scope.
“Post to Discord every hour” = agent with cron activation policy, x on discord-send-message tool, r on the resource record describing which channel. Each tick activates the agent; it calls the tool, and the result is recorded in the session stream.
“Summarize new issues every morning” = agent with daily cron activation policy, x on github-list-issues tool, w on a target room. It reads, summarizes, posts the summary as a message to the room’s stream.
“Review every PR on push” = agent with webhook activation policy, x on github-comment tool, r on the github-repo resource. GitHub calls the webhook, the app dispatches to the agent, the agent reviews and comments.
The pattern is always: event → dispatch → activate → tool call → artifact. No workflow DSL. No DAG builder. The substrate is the automation engine. Activation policies on agent records define when. Permissions define what. Tools define how. Streams record what happened. Sub-agent coordination is autonomous — an agent that needs to delegate does so; no special mechanism required.
The scheduler question
Who ticks cron and interval activation policies?
Option A: the DO itself, using Cloudflare Alarms. The DO sets an alarm for the next tick, wakes itself, creates a run, executes. Simple, but alarm failures are silent and there’s no external observability of “the alarm was supposed to fire but didn’t.”
Option B: a scheduler service (another DO or a cron worker) that reads activation-policy records and dispatches activations. More moving parts, but the scheduler is inspectable and can detect missed ticks.
Option C: both. The DO uses Alarms for the actual wake-up, but a lightweight scheduler DO periodically reconciles “policies that should have fired” against “runs that actually exist” and raises alerts for gaps.
Option C is probably right. Alarms for the happy path, reconciliation for the failure path. The reconciler is itself an agent with an activation policy — it’s turtles, but only two deep.
For webhook and event-driven triggers, the adapter receives the external event, looks up matching activation policies, and dispatches to the relevant agent DOs. No scheduler involved — the event is the clock.
Activation dispatch
When a scheduler tick fires, or an adapter receives an external event, something needs to: look up matching activation policies, resolve the target agent, check capabilities, and call the agent DO. The current app worker does a version of this for mentions. The new version needs a generic dispatch(activationPolicy, event) → run path that any adapter can use. The adapter hands an event to the dispatcher, gets back a run correlation ID.
The hourly Discord test
“Say hello every 1 hour in our Discord general chat” should compile into:
- an agent record with identity
- a resource record representing the Discord channel
- a secret reference for the Discord credential
- a tool record such as
send-message - a capability grant allowing the agent to invoke that tool against that resource
- an activation policy record on a one-hour schedule
- a run created on each tick
- a session stream recording the reasoning and side effects, even if terse
- a result record storing the remote message ID and timestamp
No sandbox is required unless the policy or tool actually needs one.
If the message fails because the token is revoked, that is a run failure with a visible reason. If the agent wants to change its wording, that is session-level behavior. If a human revokes its access to the Discord resource, that is a permission or capability change in the substrate. The layers stay clean.