Which model should triage and which should root-cause failed deploys?

Tares lets you pin the frequent triage agent to the cheapest model that calls tools reliably and the rare root-cause agent to a stronger hosted model, each chosen on its own agent form. Triage runs on a schedule and mostly says “normal” in one line, so it needs low cost per run. The root-cause agent runs only when triage flags an entity, so it can afford a thorough model. This is the pattern in Watch, then escalate, and it sits in front of the alert-driven agent described in AI SRE.

How it works

Two agents are linked by a handoff, and each one carries its own model choice.

• Triage agent. A schedule trigger fires every interval and gives the agent a summary of the window instead of raw lines. For each label you name, it shows the count per value against the window before, largest change first, plus a few recent lines. The agent reads that page and ends every run with no_op or with a finding whose verdict is investigate. It runs often, so pick the cheapest model on your provider that calls tools reliably. A small model reading a summary costs well under a cent a run.
• Root-cause agent. It has no trigger and wakes only on a handoff from triage. 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 runs at most once per cooldown per entity, so a stronger model costs little overall.

The agent form has a provider picker next to a model picker, so each agent is set separately. If you leave the provider on the cell default, the agent follows whatever the default is. If you pick one, the agent is pinned to it. If you leave the model empty, the agent runs on that provider’s default model.

How small can triage go? Connecting a small open model is one provider entry, but a small model sometimes writes its tool call as JSON text, mis-cases a tool name or answers with nothing. Tares runs a call written as text, matches a mis-cased name and flags a run that ends with no conclusion and no tool call. An 8B-class model on a laptop can produce a correct finding on a simple incident, but on an empty result it will invent events. Treat that size as a way to try things out. For root-cause work on real data, use a hosted model or a 30B-class one and above.

Set it up

1. Add your providers under Settings → Model providers. Saving a provider asks the endpoint which models it serves, so the agent form offers exactly what your key can use. Use Refresh models on a provider’s row if the list changes. The model providers page covers the Anthropic, OpenAI and OpenAI-compatible kinds.
2. Put both agents in one project, with the sources you want watched. Label the fields you want counted, so the triage agent can see which values moved. For failed deploys, that means the sources that carry your deploy signals.
3. Add a schedule trigger on those sources:

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

4. Create the triage agent on that trigger and seed its prompt from the Triage (on a schedule) preset. In the form, pick the cheapest model that calls tools reliably, and set a budget so the cadence cannot run up a bill.
5. Create the root-cause 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. Pick a stronger model in its own form.
6. On the triage agent, under When it concludes, choose Add a handoff for the investigate verdict. In the catalog, the model choice sits on each agent with the provider and model fields:

agents:
  - name: triage
    trigger: watch-web
    provider: anthropic
    model: ...              # the cheapest model that calls tools reliably
    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
    provider: anthropic
    model: ...              # a stronger model
    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

7. At a 10 minute interval, triage makes 144 runs a day, above the default limit of 50 runs per agent per day. Raise the limit under Settings → Agents or with TARES_AGENT_DAILY_CAP.

What you get

• A cheap, frequent first level and a thorough, rare second level, with the model for each set on that agent’s own form.
• A run history you can read later. Every run records the provider and model it ran on, on the agent page and in the runs table, so you can compare how each model performed.
• Cost you can see. The spend meter on the Overview prices each run from the model that answered, and splits spend by provider once more than one has run. A model with no price records its tokens and the meter counts the unpriced calls.
• One card on the Overview under What the agents found: the tick, the triage finding and the root cause, in order.
• An easy way to turn it off. Disable the triage agent or pause its schedule trigger, and the root-cause agent goes quiet too.

When something else fits

• If you want one model for everything, leave both agents on the cell default provider and an empty model, and they follow the default.
• If you only need to react to alerts you already wrote rules for, an alert-driven agent covers that without a schedule. See AI SRE.
• If you run a small local model for triage, expect it to need more checking. Keep a hosted or 30B-class model on the root-cause agent.

Related