Watch, then escalate

Pick the sources to watch

Any sources work; put both agents in one project. Label the fields you want counted, such as service and status_code, so the triage agent can see which values moved. For example, your request logs in a web_logs source, labeled by service.

Add a schedule trigger

A schedule trigger fires every interval for all the events of its sources, whether or not anything happened. It hands the agent it wakes a summary of the window instead of raw lines: for each label you name, the count per value in this window against the window before, largest change first, plus a few recent lines. A busy stream of tens of thousands of lines becomes a page the model can read.

On the project’s page click + next to Triggers, then fires: on a schedule. Or 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

Add the triage agent

Create a Tares agent on watch-web and 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 so the cadence cannot run up a bill.

The preset tells the model to consider only values that grew at least 3x and by at least 50 events since the window before (or are new with 50 or more), to ignore routine noise such as uptime probes, and to judge among what is left. The numbers are in the prompt, so tune them by editing it.

The preset also fills in How it ends: Ends every run with a conclusion is ticked, and Verdicts it can give lists investigate, “one entity looks like a problem and needs a closer look”. Tares then holds the agent to it: every run ends with the conclude tool, and a finding carries investigate or goes back to the agent to fix (see How a run ends).

Every run ends one of two ways:

• no_op: nothing needs a closer look. The run is a success with no finding; the runs table shows it as “no finding” with the one-line reason.
• finding with verdict investigate: one entity looks off. The finding is recorded on that entity (for example service=checkout), naming the numbers that moved. The preset tells the model that this verdict hands the entity off to the agent that takes a closer look.

Hand off to the main agent

The simplest link is a handoff on the triage agent: when it concludes with verdict investigate, the main agent takes over on the same entity.

Create the main agent in the same project and seed its prompt from Root cause after a handoff (it comes with the verdicts rca and resolved). Set its trigger to No trigger: only a handoff starts it: it never wakes on its own, and its page says “Only a handoff from triage starts it”. Then open the triage agent, and under When it concludes choose Add a handoff: pick investigate from the verdict dropdown, the main agent, cooldown 30m. In the catalog:

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

The main agent is handed the triage finding, not the logs, so it fetches its own evidence with read, stats and any MCP tools you give it, then writes its note on the same entity with conclude. See Hand off to another agent for the cooldown, the depth limit and what is recorded when a handoff does not start.

Or wake it with a trigger over findings. A handoff is the simpler fit, and it shows on the triage agent’s page under When it concludes. A trigger is worth it only when you need a condition, such as several investigate findings in a window or findings from more than one agent. A trigger over the findings source, filtered to the triage agent’s investigate findings, wakes the main agent:

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, enable it, and seed its prompt from Root cause after a handoff the same way. Use one link or the other, not both, or the main agent runs twice per flag.

Watch it work

Open the project. When triage flags something, the main agent’s root cause shows on the Overview under What the agents found: one card for the whole chain, with the headline and the next step. Click it to see how Tares got there: the tick, the triage finding and the root cause, in order.

To look closer, Setup → Advanced setup. The triage agent’s runs (click it under Agents) show mostly “no finding” rows in the outcome column, each with its reason and cost; a flagged run shows an investigate chip with its headline. Advanced setup’s Activity shows the tick, the triage finding and the root cause as one thread.