Scheduled work

Every agent so far only acts when emailed. Scout's real value is proactive: each morning she should check what's running low and email the ops team. That's a responsibility — a standing duty that runs on a schedule, the Loop layer of Protege.

What a responsibility is

A responsibility is a small, dashboard-managed record: which agent, what instruction, how often. It's not code — it's data, so an operator can add or retune a duty without a deploy. When it comes due, the scheduler runs the owning agent through the same inference cycle an email would, but seeded with the responsibility's instructions instead of an inbound message.

The tick that drives this was already wired by protege:install — an entry in config/recurring.yml that fires Protege::ResponsibilityTickJob once a minute and dispatches whatever's due.

The tick needs a runner that understands recurring.yml

config/recurring.yml is Solid Queue's recurring-task file (the Rails 8 default). It fires only where Solid Queue is actually running — in production that's the default stack; in development the async adapter ignores it, so either run Solid Queue locally (queue_adapter = :solid_queue plus bin/jobs) or just use the Run now button below while developing. On another backend (Sidekiq, GoodJob), schedule Protege::ResponsibilityTickJob every minute with that backend's own cron facility (sidekiq-cron, GoodJob cron) instead.

Let Scout's tools run unattended

A scheduled run has no inbound sender, and toolkit gates are sender-based — so by default a scheduled run has no tools at all. Each attachment opts in explicitly: on Scout's page, open the Operations attachment's Configure Access Settings and check Allow on scheduled runs. That flag is why we bundled send_email into Operations in chapter 5: one flag arms her whole trade, mail included, for proactive work. (Her Default Tools attachment stays reactive-only — that's fine.)

Give Scout a duty

Open Responsibilities in the top nav, hit New, and pick Scout in the Agent select:

• Name: Daily low-stock report

• Schedule: 0 8 * * * (every day at 08:00 — a standard 5-field cron expression, evaluated in your app's Time.zone, so set config.time_zone if duties should fire in local time)

• Instructions:

  Check which flavors are low or out of stock. Email a concise summary to team@thescoop.com, and for anything critical, note whether we should reorder.

Or create it as a record directly:

scout = OperationsAgent.find_by!(name: "Scout")
scout.responsibilities.create!(
  name:         "Daily low-stock report",
  schedule:     "0 8 * * *",
  instructions: "Check which flavors are low or out of stock. Email a concise summary to " \
                "team@thescoop.com, and for anything critical, note whether we should reorder."
)

At 08:00, Scout wakes on her own: her responsibility_resolvers chain assembles the turn (her system prompt plus this duty's instructions), she calls check_flavor_stock as needed, and sends the summary with send_email in new mode. No inbound email involved — she initiated the whole thing.

You could add a second duty the same way — an abandoned-order follow-up that emails customers who never completed checkout — and it runs on its own schedule, independently.

Watching runs

Each execution is a run, recorded so you can see history and audit what happened. A run moves through pending → running → completed (or failed), and the dashboard shows Scout's recent runs with their status, timing, and correlation id — the id that ties the run's trace turns and log lines together when you want the tool-by-tool detail. To test without waiting for 08:00, use Run now on the responsibility — it dispatches immediately.

The scheduler is deliberately minimal

The Loop fires due duties and leaves the rest to Rails. There's no overlap guard — if a run is still going when the next tick fires, a second can start — so keep a duty's cadence comfortably longer than its work takes. Concurrency and retries are your job queue's concern, not the scheduler's. See Scheduler.

Next

Sundae and Scout are both working — one reactive, one proactive. Before you trust them, you'll want to see what they're doing.

→ Observing your agent — the introspection panel and tracing.