Automate a recurring task

Use this when you want an agent to do a task on its own every morning, and want to see how traits, bounds, actions, and schedules combine to get there.

The other guides each cover one primitive. This one chains them into a single story: you give an identity a capability, run it under a restriction, turn the work into a repeatable action, and schedule it to run on its own. The task: every morning, pull your team’s open Linear issues and leave a short triage note, read-only, without you starting it.

Before you begin

Build a Barry. These commands act as the bonanza identity from that guide; use your own identity’s command in its place.
Have a bag of your own at ~/repos/my-tools. Packing bags shows how to make one.
Have a Linear API key, and Barry’s vault set up.
For step 4, pull the local model first with ollama pull qwen3:4b.

1. Give the identity a capability

Install the Linear bag and pack it onto your identity. Installing registers it on the machine; packing adds it to the identity:

barry install https://github.com/perintyler/linear-bag
bonanza pack linear

The Linear bag reads an API key. Store the key in the vault and bind it to the identity in one step, so the Linear tools receive it without it appearing in a prompt. Barry asks for the value at a masked prompt, which keeps it out of your shell history:

bonanza identity secret set LINEAR_API_KEY --in vault

Manage secrets covers this wiring in full.

2. Run it once, under a restriction

Start a session that grants the Linear tools and nothing you did not ask for, read-only so the agent can look but not change anything:

bonanza session start --traits linear --bound readonly

A trait grants; a bound takes away and can never add. The readonly bound removes write tools, so even though you packed Linear’s write tools, this session cannot use them. Ask the agent in plain language:

List our team's open Linear issues and write a short triage note for each.

When the result is what you want, you have proven the task by hand. The next steps make it repeatable.

3. Turn the task into an action

An action is the task as a named procedure with typed inputs and a model of its own, instead of a prompt you retype. Scaffold one into a bag you own:

barry new action morning-triage --bag my-tools

Barry writes actions/morning-triage/action.yaml with a placeholder. Replace the prompt with the steps the agent should follow, declare the inputs it takes, and mark it self-contained with context: none:

version: 1
name: morning-triage
description: Pull the team's open Linear issues and leave a short triage note on each.
context: none
input_schema:
  type: object
  properties:
    team:
      type: string
  required: [team]
prompt: |-
  List the open Linear issues for the given team and write a short triage note
  for each: likely priority, and the one next action.

Rebuild the bag and run the action from the terminal to check it:

barry install ~/repos/my-tools
bonanza action run morning-triage --input team=platform

An action defaults to context: session, which means its prompt needs the conversation that called it, so Barry refuses to run it on its own from the terminal or a schedule. context: none says the action needs no conversation. Using actions covers inputs, deliverables, and reading recorded runs.

4. Point it at a cheaper model

Running a frontier model every morning is more than this needs. An action carries its own model, so point it at a local one and the triage never leaves your machine and costs nothing. Barry derives the vendor from the model ID. Add this block to action.yaml:

agent:
  model: qwen3:4b

5. Schedule it

Declare a schedule in the bag’s bag.yaml so the action runs on its own each morning, as your identity, with the Linear trait, under the same read-only restriction:

schedules:
  morning-triage:
    cron: "0 8 * * 1-5"
    timezone: America/New_York
    action: morning-triage
    identity: bonanza
    traits: [linear]
    inputs:
      team: platform
    bounds: [readonly]

A schedule receives only what it names. identity picks whose keys and default harness the run uses, and traits grants the Linear tools; without them the run has no tools. Barry reads cron in UTC unless you set timezone to an IANA zone name.

Install the bag again, then confirm Barry sees the schedule:

barry install ~/repos/my-tools
bonanza schedule list

Each fire records an action run. Read the morning’s triage over coffee with bonanza action runs and bonanza action show. Schedule and distribute work covers triggers, durability, and running the job on another machine.

What you built

In five steps a trait and a bound became an enforced policy, a prompt became a typed action, a local model made it cheap, and a schedule made it autonomous. Each step is a line or two of configuration, and each keeps every guarantee of the step before. That composition is the whole point of Barry.

Verify

To confirm Barry sees the schedule, run:

bonanza schedule list

The list shows my-tools/morning-triage with its cron trigger, its action, and its next fire. To check the whole chain without waiting for the morning, run the schedule now and read its run by the action’s qualified name:

bonanza schedule run my-tools/morning-triage
bonanza action runs --action my-tools:morning-triage

If it fails

No action named "morning-triage". Install the bag again so Barry picks up the new action.
Could not reach the API to run an agent action. A prompt: action needs Barry’s services. Start them with barry up, and see See what is running.
The Linear tools fail for want of a key. Run bonanza identity check and fix the line that reports MISSING.
The schedule shows failing. Read its latest run with bonanza schedule logs my-tools/morning-triage.

What’s next

What is Barry for the model behind it.
Restricting with bounds to tighten what a scheduled run can do.
Empowering with traits for the grants a schedule can carry.