Which model should triage and which should root-cause slow database queries?

Tares lets you put a cheap, tool-calling model on the frequent triage agent and a stronger hosted model on the rare root-cause agent, each set on its own agent form. Triage reads a short summary every few minutes, so the cheapest model that calls tools reliably is enough. The root-cause agent runs only when triage flags an entity, so you can spend on a stronger model there.

How it works

Two agents work as a pair in one project, linked by a handoff. The watch, then escalate pattern splits the work by how often each agent runs.

• Triage runs often. A schedule trigger wakes it every interval. It receives a summary of the window, not raw lines: for each label you name, the count per value against the window before, largest change first, plus a few recent lines. Most runs end as no_op with a one-line reason. When one entity looks off, it concludes with the verdict investigate.
• Root cause runs rarely. It has no trigger of its own. A handoff on investigate starts it on the same entity, at most once per cooldown. It receives the triage finding, not the logs, and fetches its own evidence with read, stats and any MCP tools you give it.

Because the two jobs differ, you pick a model for each on that agent’s own form. The agent form has a provider picker next to a model picker. Pick a provider and the agent is pinned to it. Leave the provider on the cell default and it follows the instance default. Leave the model empty and the agent runs on that provider’s default model.

For the model choice:

• Triage: the cheapest model on your provider that calls tools reliably. Your slow-query data reaches it as a count summary, which keeps the job small. Tool calling matters because every run must end with the conclude tool.
• Root cause: a hosted model, or a 30B-class one and above. This agent works on real data across several tool rounds, and small models sometimes write a tool call as text, mis-case a tool name or answer with nothing.

An 8B-class model on a laptop is fine for trying things out, but on an empty result it will invent events. Do not use that size for root-cause work on real data.

Set it up

1. Add the providers you want under Settings → Model providers. Tares supports Anthropic, OpenAI and any OpenAI-compatible endpoint such as LiteLLM, OpenRouter, Ollama or vLLM. Saving a provider reads the models it serves, so the agent form offers exactly what your key can use. If the list is stale, use Refresh models on the provider’s row.
2. Label the fields you want counted on the sources that carry your slow-query data, so triage can see which values moved. Put both agents in one project.
3. On the project’s page click + next to Triggers, then fires: on a schedule. Or add the trigger 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

4. Create the triage agent on that trigger and seed its prompt from the Triage (on a schedule) preset. Pick the cheap provider and model on its form, and set a budget so the cadence cannot run up a bill.
5. Create the root-cause agent with no trigger, seed it from Root cause after a handoff, and pick the stronger provider and model on its form.
6. On the triage agent, under When it concludes, choose Add a handoff for investigate, pointing at the root-cause agent with a cooldown of 30m. In the catalog the model choice sits on each agent with provider and model:

agents:
  - name: triage
    trigger: watch-web
    concludes: true
    provider: anthropic
    model: ...              # the cheapest model that calls tools reliably
    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
    provider: anthropic
    model: ...              # a stronger hosted model
    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. A 10-minute schedule is 144 runs a day, above the default of 50 runs per agent per day. Raise the limit under Settings → Agents or with TARES_AGENT_DAILY_CAP.

What you get

• A low, predictable bill for the watch. A small model reading a summary costs well under a cent a run, and the strong model runs only when triage flags something, at most once per cooldown per entity.
• Every run records the provider and model it ran on, on the agent page and in the runs table. 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. You can see what each tier costs and adjust.
• One card on the Overview under What the agents found for the whole chain: the tick, the triage finding and the root cause, in order.
• Freedom to change either model later without touching the other agent. Change the cheap model if triage misses calls, or the strong one if root-cause notes fall short.

For the wider pattern, see Build an AI SRE.

When something else fits

• If one model on the default provider is good enough for both agents, leave the provider and model empty and both follow the instance default. See Model providers.
• If you need a condition before escalating, such as several investigate findings in a window or findings from more than one agent, wake the root-cause agent with a trigger over findings instead of a handoff. Use one link or the other, not both.

Related