Which model should triage and which should root-cause high latency?

Tares lets you pick a model per agent, so you run a cheap model that calls tools reliably on the frequent triage agent and a stronger model on the rare root-cause agent. Triage wakes on a schedule and reads a summary, so cost per run matters most there. The root-cause agent runs only after triage flags an entity, so you can spend more on each run. You set each choice on that agent’s own form, using the provider and model pickers.

How it works

The Watch, then escalate pattern uses two agents linked by a handoff. Each one has its own provider and model, so each is judged on its own job.

• Triage agent. A schedule trigger wakes it every interval, for example every 10 minutes. It reads a summary of the window instead of raw lines and ends every run with the conclude tool: no_op when nothing needs a closer look, or a finding with the verdict investigate. Pick the cheapest model on your provider that calls tools reliably, because the run has to finish with a real tool call.
• Root-cause agent. It has no trigger of its own. A handoff from triage starts it 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. This is the work where model quality counts. Use a hosted model, or a 30B-class one and above.

A small model can fail in a few ways. It may write a tool call as JSON text, mis-case a tool name, or answer with nothing. Tares runs a call written as text and matches a mis-cased name. It marks a run that ends with no conclusion and no tool call with a note to check that the model supports tool calling. An 8B-class model on a laptop gives a correct finding on a simple incident, but it invents events on an empty result. Treat that size as a way to try things out, not as your root-cause model.

Set it up

1. Add your providers under Settings → Model providers. An instance can hold several, for example Anthropic, OpenAI, or an OpenAI-compatible endpoint such as LiteLLM, OpenRouter, Ollama or vLLM. Saving a provider stores the models it serves, so the agent form offers what your key can use.
2. Create the triage agent on your schedule trigger and seed its prompt from the Triage (on a schedule) preset. In the form, set the provider and the model to the cheapest option that calls tools reliably.
3. Set a budget on the triage agent. At 10 minutes it runs 144 times 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.
4. Create the root-cause agent with no trigger and seed its prompt from Root cause after a handoff. Pick the stronger provider and model on its form.
5. Add a handoff on the triage agent for the verdict investigate, pointing at the root-cause agent with a cooldown of 30m.

In the catalog, the provider and model fields sit on each agent:

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 }
    handoffs:
      - { verdict: investigate, agent: rca, cooldown: 30m }
  - name: rca
    provider: anthropic
    model: ...              # a stronger hosted model, or a 30B-class one and above
    concludes: true
    verdicts:
      - { verdict: rca, when: you found what is failing and why }
      - { verdict: resolved, when: it was noise, or it is already over }

Leave the model empty and the agent runs on its provider’s default model. Leave the provider on the cell default and the agent follows whatever the default provider is. If you want each agent pinned to the model you chose, set both fields.

For high latency, point the schedule trigger at the sources that show it, such as your request logs, and label the fields you want counted. The model split is the same either way. Browse the full list of provider kinds on the Model providers page.

What you get

• A triage agent that costs little per run. A small model reading a summary costs well under a cent a run, and the budget caps the cadence.
• A root-cause agent that runs only when triage flags an entity, at most once per cooldown per entity. With a 30m cooldown that is at most two root-cause runs per hour per entity.
• Visible history. Every run records the provider and model it ran on, on the agent page and in the runs table, so you can compare the two agents’ results.
• Cost you can read. 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, such as a local Ollama model, records its tokens with no dollar figure, and the meter counts the unpriced calls.

If you want to see how this fits into the wider alert-driven setup, start from AI SRE.

When something else fits

• If one model on one provider is enough for you, leave both agents on the default provider and skip the per-agent choice. You can split them later.
• If you want to try the pattern on a laptop first, a small local model is fine for triage experiments, but use a hosted or 30B-class and above model for root-cause work on real data.
• If you need the main agent to wake on a condition, such as several investigate findings in a window, use a trigger over findings instead of a handoff. The model choice per agent stays the same.

Related