Automations

Automations allow AI Intern to perform ongoing, unattended engineering tasks (like routine dependency audits, framework migrations, test flake investigations, and scheduled code health sweeps) without waiting for a human prompt.

Trigger kinds

Automations support up to 20 triggers evaluated together (OR semantics). When any trigger condition is met, AI Intern initiates an approval-gated delegation run.

Kind	Trigger Source	Frequency / Floor
`schedule`	Five-field cron expressions evaluated via Cloudflare Triggers	Minimum 5-minute floor; missed ticks coalesce
`github`	Webhook events: PR opened, commits pushed, issues labeled, reviews	Real-time via `/api/github/webhook`
`slack`	Mentions, channel alerts, or bot notifications	Real-time via `/api/slack/events`
`webhook`	Dedicated HTTP endpoint with per-automation authentication token	`POST /api/automations/{id}/trigger`
`manual`	Triggered immediately from the Dashboard or CLI	On-demand execution

Status: trigger engine only

The trigger engine (src/automations.ts) is implemented and unit-tested, but no scheduler ships yet: wrangler.jsonc has no triggers.crons and the Worker has no scheduled() handler, and there is no Automations Durable Object or API to create automation records yet. Nothing fires on its own. The sections below describe the designed behavior for when the runner is built — not what the deployed Worker does today.

Configuring an automation

You can declare automations in your dashboard or programmatically via the API:

{
  "id": "nightly-dep-audit",
  "prompt": "Audit dependencies for known vulnerabilities, update patch versions, and run vitest",
  "repoUrl": "https://github.com/org/web-app",
  "enabled": true,
  "triggers": [
    {
      "kind": "schedule",
      "cron": "0 2 * * *"
    },
    {
      "kind": "github",
      "events": ["pull_request:closed"]
    }
  ]
}

The `run_when` gate

Exact filters cannot express “only when it’s actually a bug report”. Any trigger may carry a run_when sentence, checked by the cheap Workers AI orchestrator model before the run starts: a single call, no AI Gateway round trip, and no token bill against your provider key.

{ "kind": "github", "events": ["issues:opened"], "runWhen": "the issue is a bug report, not a feature request" }

The gate fails closed. A model error, an empty answer, or anything not clearly affirmative means no run, and the reason is recorded on the automation rather than dropped.

Safety and rate limiting

An automation is an approval gate with nobody standing at it. Three controls apply together, plus two kill switches:

Approval by default. Every automated run posts an approval card and starts no container until a human approves it. An automation schedules work; it does not authorize it.
Unattended mode is opt-in and narrow. Set unattended: true and list the repo in unattendedRepos. It is refused unless opening a pull request is the run’s only mutation: a PR is reviewable and revertible, nothing else is.
Daily run budget. dailyRunLimit (default 20) per automation per UTC day. A cron misconfiguration or a webhook loop otherwise burns tokens until somebody notices, and tokens are 20–40× the compute bill. Run N+1 is refused with the reason.
Schedule floor. A strict minimum of 5 minutes between firings (SCHEDULE_FLOOR_MINUTES = 5); missed ticks coalesce into one run, never a backlog.
Concurrency. Automations share the global limiter (MAX_CONCURRENT_RUNS = 5, matching max_instances). New runs wait for a slot. Parallelism costs no more, because billing is container-seconds.
Kill switches. enabled: false per automation, and the AUTOMATIONS_ENABLED var globally.