How do I put a cheap triage agent in front of my root-cause agent?

Tares lets you put a cheap triage agent in front of your root-cause agent with a schedule trigger and a handoff. The trigger gives triage a summary of each window. When one entity moves, the handoff starts the main agent on that entity only. The full walkthrough is in Watch, then escalate.

How it works

Three pieces work together: a trigger, a small agent and a handoff.

• The summary. A schedule trigger fires every interval, whether or not anything happened. The agent it wakes gets a digest instead of raw lines. For each label you name, the digest shows the count per value in this window against the window before, largest change first, plus a few recent lines.
• The triage verdict. The triage agent reads the digest and ends every run with the conclude tool. Either nothing needs a closer look (no_op, a success with a one-line reason), or it records a finding with verdict investigate on one entity, such as service=checkout, naming the numbers that moved.
• The handoff. When triage concludes with investigate, the main agent takes over on the same entity. It receives the triage finding, not the logs, so it fetches its own evidence with read, stats and any MCP tools you give it. It then writes its note on that entity with verdict rca or resolved.

The Triage (on a schedule) preset tells the model to consider only values that grew at least 3x and by at least 50 events since the window before, or that are new with 50 or more. It also tells the model to ignore routine noise such as uptime probes. The numbers live in the prompt, so you tune them by editing it.

Each tick, triage verdict, handoff and root-cause note is recorded on the entity’s timeline.

Set it up

1. Gather the sources. Put both agents in one project. Label the fields you want counted, such as service and status_code, so triage can see which values moved. For example, request logs in a web_logs source labeled by service.
2. Add the schedule trigger. On the project page click + next to Triggers, then fires: on a schedule. Or add it in the catalog:

triggers:
  - name: watch-web
    sources: [web_logs]
    key_field: service
    condition:
      every: 10m                          # at least 1m
      summary_by: [service, status_code]  # labels to count; default: the trigger's key field

3. Create the triage agent. Make a Tares agent on watch-web and seed its prompt from the Triage (on a schedule) preset. Choose the cheapest model on your provider that calls tools reliably, and set a budget. The preset ticks Ends every run with a conclusion and lists the verdict investigate.
4. Create the main agent. Seed its prompt from Root cause after a handoff, which comes with the verdicts rca and resolved. Set its trigger to No trigger: only a handoff starts it.
5. Link them. Open the triage agent, and under When it concludes choose Add a handoff. Pick investigate, the main agent and cooldown 30m. In the catalog the two agents look like this:

agents:
  - name: triage
    trigger: watch-web
    concludes: true
    verdicts:
      - { verdict: investigate, when: one entity looks like a problem and needs a closer look }
    prompt: ...             # from the Triage (on a schedule) preset
    handoffs:
      - { verdict: investigate, agent: rca, cooldown: 30m }   # at most two root-cause runs per hour per entity
  - name: rca               # no trigger: it runs only when handed off
    concludes: true
    verdicts:
      - { verdict: rca, when: you found what is failing and why }
      - { verdict: resolved, when: it was noise, or it is already over }
    prompt: ...             # from the Root cause after a handoff preset

6. Raise the run limit. At 10 minutes triage runs 144 times a day, above the default of 50 runs per agent per day. Raise it under Settings → Agents, or with TARES_AGENT_DAILY_CAP.

What you get

• A cheap first look. A small model reads one page of counts and costs well under a cent a run. Most runs end as “no finding” with a one-line reason.
• A rare, thorough second look. The main agent runs only when triage flags something, and at most once per cooldown per entity. With 30m that is two root-cause runs per hour per entity.
• One card per incident. On the project Overview, under What the agents found, the chain shows as a single card with the headline and the next step. Click it to see the tick, the triage finding and the root cause in order.
• A visible audit trail. Under Setup → Advanced setup, the triage agent’s runs list an outcome, a reason and a cost for each run. 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. Your alert-driven agents keep running as before.

When something else fits

A handoff is the simpler link and is the right default. Use a trigger over the findings source only when you need a condition, such as several investigate findings in a window, or findings from more than one agent. It looks like this:

triggers:
  - name: escalate
    sources: [findings]
    key_field: service
    filters:
      - {field: agent, op: eq, value: triage}
      - {field: verdict, op: eq, value: investigate}
    condition: {aggregate: count, predicate: "> 0", window: 5m}
    cooldown: 30m    # at most two root-cause runs per hour per entity

Create the main agent on escalate and enable it. Use one link or the other, not both, or the main agent runs twice per flag. A trigger over findings must be filtered to another agent’s findings with agent eq <name>. A trigger over all findings, or over the agent’s own, is refused so an agent never wakes itself.

If you already know the failure you care about, an alert-driven agent from the Build an AI SRE guide is the better fit. This pattern sits in front of it and catches what nobody wrote a rule for.

Related