talons
talons are site-scoped automations: a trigger, an optional condition, and one or more outputs. hoot can create them conversationally, and every run is recorded.
talons are owlette's automations — the owl's instrument of action. each talon is a small pipeline: when something happens (the trigger), optionally check something (the condition), then do something (the outputs). talons live at /talons in the dashboard, are scoped to a site, and can target every machine in the site or a chosen subset.
you can build a talon in the visual editor, start from a preset, or simply ask hoot — "every morning at 8, screenshot the wall and email me if the loop isn't playing" becomes a talon you can inspect and edit like any other.
triggers
| trigger | fires when | notes |
|---|---|---|
| schedule | fixed times on chosen weekdays, or every n minutes | evaluated in the site timezone; minimum interval 5 minutes (15 with a visual check) |
| threshold | a metric alert rule fires and its breach matches the talon's own predicate | rides the existing alert pipeline — a threshold talon does nothing until a matching alert rule exists |
| event | one of the subscribed machine events lands | process crash / start failure / restart, exe missing, machine offline, and the display events; an optional delay (1–1440 minutes) lets a slow-starting app settle before the talon looks |
the condition
a talon can run its outputs unconditionally (none), or first perform a visual check: capture a screenshot of the machine and have hoot judge it against a plain-language expectation you write — "the screen should be showing the content loop, not the desktop, an error dialog, or a black screen." the verdict, confidence, reasoning, and the screenshot itself are recorded on the run. outputs only fire when the check fails.
visual checks spend an LLM key — see which key an unattended run spends — and are capped at one run per 15 minutes per talon.
outputs
a talon can have several outputs; each is attempted and recorded independently on the run.
- email — notifies the site's alert recipients, with per-recipient unsubscribe links.
- webhook — a signed POST to your endpoint. the signing secret is generated server-side and is never readable from the dashboard.
- hoot — hands hoot a directive to carry out against the machine, in a chat you can open and read afterwards. by default the turn is read-only (tier 1 tools). a site admin can arm let hoot act on the output, which raises it to tier 2 — process control, screenshots, service management, windows update policy. tier 3 (raw shell, file writes) is never available to an unattended run, whatever the flag says.
- command — queues a process command (restart / start / stop) against the machines in scope. authoring a command output requires a site admin, since it is the same power class as an armed hoot output.
the identity that pays and acts is the talon's creator, re-checked on every run — a creator who has left the site stops the talon rather than lending it stale privileges.
presets
six built-ins ship with every site: morning wall check, crash triage, weekly health report, exe went missing, wall check after restart, and update guard — the last one re-asserts the windows update install window and the suppression of the full-screen setup screens (privacy experience, welcome experience, "let's finish setting up your device", edge first run) every sunday morning, so an update never hijacks the exhibit. presets ship un-armed: the ones that need to change machine state tell you to turn on let hoot act after you add them.
runs, failures, and audit
every firing writes a run record — trigger summary, per-machine target, condition verdict, each output's result, and timing — visible in the talon's run history and in the site activity log. cooldowns (default 60 minutes for threshold and event talons) stop a flapping machine from firing the same talon in a loop. a talon that fails 10 runs in a row is switched off automatically with the reason recorded on it; re-enabling it resets the counter.
structural changes — create, edit, enable, disable, delete — are written to the site audit log as talon_mutated entries, attributed to the human who made them (including talons created through hoot).
limits
- 20 talons per site.
- schedule intervals: 5 minutes minimum, 15 with a visual check.
- one run in flight per talon; a run stuck past 10 minutes is marked failed.
- run history follows the standard 400-day retention window.
hoot (ai chat)
hoot is the dashboard chat surface for diagnosing and managing machines with an LLM. It supports Anthropic and OpenAI providers, can target either one machine or every online machine in a site, and routes tool calls through the safest available execution path for the current target.
activity logs
The activity logs page shows a site-scoped timeline for agent, process, command, deployment, and scheduled reboot events. Open it from the dashboard menu by selecting logs, or go directly to /logs.