What does the root-cause agent receive when the triage agent hands off failed deploys?

When the triage agent hands off failed deploys, Tares starts the root-cause agent on the same entity and gives it the triage finding, not the raw logs. The finding comes after 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. This works only if the triage agent ends its runs with the conclude tool, because the verdict comes from there.

How it works

A handoff is three values: a verdict, the agent that takes over, and a cooldown. When a triage run ends with a finding whose verdict matches, Tares starts the target agent. Case does not matter in the match.

The root-cause agent receives three things:

• The finding. It is handed the triage finding for failed deploys, naming what moved, after the line Handed off by triage with verdict "investigate" on service=checkout.
• The entity. The run starts on the entity the finding is about, for example service=checkout, so its note lands on the same timeline.
• No evidence bundle. Tares does not pass the logs along. The agent pulls what it needs with its own tools, such as read, stats and any MCP tools you give it. Its note is written on the same entity with conclude.

The verdict comes from the conclude tool, so the handing agent must end every run with a conclusion. A run that finds nothing ends as no finding and hands off nothing.

The handed-off run is recorded with woken_by: handoff and the finishing triage run as its parent. On the project’s Activity it sits under the run that handed off, so the triage finding for the failed deploys and the root cause read as one thread.

These rules apply to every handoff:

• The target can be any other agent on the instance. The run belongs to the project whose wiring holds the handoff.
• The target runs whether or not it is on for its own trigger. Give it no trigger when it should run only on a handoff.
• The cooldown allows at most one handoff from this agent to that agent per entity. A handoff inside the cooldown starts no run, and the finishing run’s results say handoff to rca skipped: cooldown.
• Chains stop at depth 3. The next handoff is recorded as a capped run with the error handoff chain stopped at depth 3.
• 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.

Set it up

1. Create the triage agent on a schedule trigger and seed its prompt from the Triage (on a schedule) preset. The preset ticks Ends every run with a conclusion and lists the verdict investigate, so every run ends with the conclude tool.
2. Create the root-cause agent in the same project and seed its prompt from Root cause after a handoff. Set its trigger to No trigger: only a handoff starts it.
3. Open the triage agent. Under When it concludes, choose Add a handoff. Pick the verdict from the dropdown, pick the root-cause agent, and keep the cooldown at 30m, the default. You can also type any verdict word. If the agent never gives that word, the form warns you that the handoff would never run.
4. Or declare the same wiring in the catalog, or through POST and PUT /api/agents/builtin, where handoffs is a list:

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: |
      ...

5. Watch it work on the project’s Overview. One card under What the agents found shows the whole chain, from the tick through the triage finding to the root cause.

An update that leaves handoffs out keeps the existing ones, and an empty list clears them. Each agent can have at most 10 handoffs, and each verdict and agent pair can appear once. For the full guide, including the schedule trigger that feeds the triage agent, see Watch, then escalate. The wiring rules are on Handoffs.

What you get

• A root-cause run that starts on the entity the failed deploys finding is about, with the triage finding as its starting point.
• A cheap, frequent triage agent in front of a thorough, rare root-cause agent, with no second trigger between them.
• One thread on the project’s Activity: the triage run, the handoff and the root cause.
• No silent drops. A skipped or blocked handoff is recorded with its reason, either in the finishing run’s results or as a capped run.
• A cap on cost. The cooldown of 30m means at most two root-cause runs per hour per entity, and the target’s own daily cap and budget still apply.

This pattern sits in front of the alert-driven agent described in AI SRE.

When something else fits

• If you need a condition before the root-cause agent wakes, such as several investigate findings in a window or findings from more than one agent, use a trigger over the findings source instead. Use one link or the other, not both, or the root-cause agent runs twice per flag.
• If the triage agent does not end its runs with conclude, there is no verdict to match, so a handoff cannot start the next agent.

Related