Do I need a separate triage agent for a disk filling up, or can one agent do it all?

Tares works with either setup, and one agent is enough when disk checks are rare or cheap. Add a triage agent when you check every few minutes, so a low-cost model reads each check and a stronger agent runs only on the few hosts that look wrong. The pair costs less in model spend, and the single agent costs less to set up.

How it works

One agent. You create a single Tares agent on a trigger and give it a prompt, a model and a budget. Every wake-up runs the model you picked on that agent. If you pick a strong model, every quiet check pays strong-model prices.

Two agents. The Watch, then escalate pattern splits the work:

• A schedule trigger fires every interval, whether or not anything happened. It hands the triage agent a summary of the window instead of raw lines. For each label you name, the summary gives the count per value against the window before, largest change first, plus a few recent lines.
• The triage agent ends every run with a conclusion. Either nothing needs a closer look (a run with no finding and a one-line reason), or one entity looks like a problem and the run records a finding with the verdict investigate.
• A handoff on the triage agent passes that entity to the main agent. The main agent has no trigger of its own and wakes only on a handoff.
• The main agent receives the triage finding, not the logs. It fetches its own evidence with read, stats and any MCP tools you give it, then writes its root-cause note on the same entity.

In a disk setup, the entity is whatever label you key the trigger on, such as the host.

Set it up

1. Decide by frequency. If you check a few times a day, create one agent on its own trigger and stop here. If you check every few minutes, continue with the pair.
2. Put the source that carries your disk data and both agents in one project. Label the field you want counted, for example host, so the summary shows which values moved.
3. Add a schedule trigger. The interval is at least 1m, and summary_by lists the labels to count:

triggers:
  - name: watch-disks
    sources: [disk_events]
    key_field: host
    condition:
      every: 10m
      summary_by: [host]

4. Create the triage agent on watch-disks. Seed its prompt from the Triage (on a schedule) preset, pick the cheapest model on your provider that calls tools reliably, and set a budget. The preset fills in How it ends, with the verdict investigate.
5. Create the main agent in the same project. Seed its prompt from Root cause after a handoff and set its trigger to No trigger: only a handoff starts it.
6. Open the triage agent, and under When it concludes choose Add a handoff. Pick investigate, pick the main agent and set the cooldown to 30m. That allows at most two root-cause runs per hour per entity.
7. Raise the daily run limit. A 10 minute interval is 144 runs a day, and the default limit is 50 runs per agent per day. Change it under Settings → Agents or with TARES_AGENT_DAILY_CAP.

Use the handoff or a trigger over findings to wake the main agent, not both, or it runs twice per flag. The handoff is the simpler choice.

What you get

• Low spend on frequent checks. A small model reading a summary costs well under a cent a run. The strong model runs only when triage flags a host, and at most once per cooldown per entity.
• One card per incident. The main agent’s root cause shows on the project Overview under What the agents found. Click it to see the tick, the triage finding and the root cause in order.
• A readable quiet history. The triage agent’s runs table shows mostly “no finding” rows, each with its reason and cost. A flagged run shows an investigate chip with its headline.
• A simple off switch. Disable the triage agent or pause its schedule trigger. With no new investigate findings, the main agent goes quiet too. Alert-driven agents keep running as before.

When something else fits

Stay with one agent when checks are infrequent, when you want the fewest moving parts, or when the agent is woken by an alert rule you already trust, as in AI SRE. The pair earns its extra setup when frequent checks make strong-model cost the main concern. A single agent has no handoff to configure and no cooldown to tune.

Related