What does the root-cause agent receive when the triage agent hands off high latency?

Tares hands the root-cause agent the triage finding, not the raw logs, and starts it on the entity the finding is about. The finding follows a line such as Handed off by triage with verdict “investigate” on service=checkout. The root-cause agent then fetches any further evidence itself with its tools.

How it works

A handoff is three values: a verdict, the agent that takes over, and a cooldown. When the triage agent flags high latency on one entity, its run ends with the conclude tool and a finding that carries the verdict, for example investigate. Tares compares that verdict to the triage agent’s handoffs (case does not matter) and starts the target agent.

The root-cause agent receives:

• The finding. It is the triage conclusion, which names the numbers that moved. It comes after a line such as Handed off by triage with verdict "investigate" on service=checkout.
• The entity. The run starts on the entity the finding is about, so the root-cause agent works on the same service you saw flagged.
• No logs. The agent is not given the underlying events. It fetches further evidence itself with read, stats and any MCP tools you give it.

The handing agent must end its runs with the conclude tool, because a verdict comes only from that tool. If the triage agent does not conclude with a matching verdict, no handoff happens. A run that ends with no finding, the no_op outcome, hands nothing off.

The handed-off run is recorded with woken_by: handoff and the finishing triage run as its parent. On the project’s Activity page it sits under the run that handed off, so the triage finding and the root cause it led to read as one thread. The root-cause agent writes its own note on the same entity with conclude.

Set it up

1. Put both agents in one project and give the triage agent a schedule trigger over your sources. Label the fields you want counted, such as service, so triage can see which values moved. The Watch, then escalate guide walks through the trigger and the triage preset.
2. Make the triage agent end every run with a conclusion. Tick Ends every run with a conclusion and list the verdict it can give, here investigate.
3. Create the root-cause agent with no trigger, so only a handoff starts it. Seed its prompt from the Root cause after a handoff preset.
4. On the triage agent, under When it concludes, choose Add a handoff. Pick the verdict from the dropdown, the root-cause agent, and a cooldown (30m by default).
5. Or declare the same wiring 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: |
      ...
    handoffs:
      - { verdict: investigate, agent: rca, cooldown: 30m }
  - name: rca               # no trigger: it runs only when handed off
    prompt: |
      ...

6. Open the project. When triage flags an entity, the root cause shows on the Overview under What the agents found as one card for the whole chain. Click it to see the tick, the triage finding and the root cause in order.

The handoffs reference lists every rule, including the limit of 10 handoffs per agent and each verdict and agent pair appearing once.

What you get

• A root-cause run that starts on the exact entity triage flagged, without a second trigger in between.
• A cheap, frequent triage agent in front of a thorough, rare root-cause agent. The main agent runs only when triage flags something, at most once per cooldown per entity.
• A recorded chain. Each tick, triage verdict, handoff and root-cause note sits on the entity’s timeline.
• Visible outcomes when a handoff does not start. Inside the cooldown, the finishing run’s results say handoff to rca skipped: cooldown. If the target is already running for that entity, or has hit its daily cap or budget, the handoff is recorded as a capped run with the reason.
• A bounded chain. A handed-off agent can hand off in turn, and after three handoffs in a row the next is recorded as a capped run with the error handoff chain stopped at depth 3.

The target runs whether or not it is on for its own trigger. Give it no trigger when it should only run when handed off.

When something else fits

• Use a trigger over the findings source when you need a condition, such as several investigate findings in a window or findings from more than one agent. Use one link or the other, not both, or the main agent runs twice per flag.
• If you want an alert-driven agent with no triage in front of it, see Build an AI SRE, the pattern this setup sits in front of.

Related