What does the root-cause agent receive when the triage agent hands off error spikes?

Tares hands the root-cause agent the triage finding, not the raw logs, after a line such as Handed off by triage with verdict "investigate" on service=checkout. The agent runs on the entity the finding is about and fetches any further evidence itself with its tools. The triage agent must end its runs with the conclude tool, because the verdict comes from that tool.

How it works

A handoff is three values: a verdict, the agent that takes over, and a cooldown. When the triage agent’s run ends with a finding whose verdict matches (case does not matter), Tares starts the target agent on the entity the finding is about.

For error spikes, the root-cause agent receives:

• The finding. It comes after the handoff line, which names the handing agent, the verdict and the entity, for example service=checkout. The triage finding names the numbers that moved.
• The entity. The run is scoped to the entity the finding is about, so the root-cause agent works on the same service that triage flagged.
• No log lines. The target is handed the finding, not the logs. 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.

The handing agent must end its runs with a conclusion. A verdict comes only from the conclude tool, so an agent that does not conclude never produces a finding to hand off. When you tick Ends every run with a conclusion and list the verdict, Tares holds the agent to it: every run ends with conclude, and a finding carries the verdict or goes back to the agent to fix.

The target runs whether or not it is on for its own trigger. Give it no trigger when it should run only when handed off. The handed-off run is recorded with woken_by: handoff and the finishing run as its parent, so on the project’s Activity the triage finding and the root cause read as one thread.

Set it up

1. Put both agents in one project, with a source whose labels you want counted. For error spikes, label fields such as service and status_code, so triage can see which values moved.
2. Add a schedule trigger that fires every interval and hands the triage agent a summary of the window.

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

3. Create the triage agent on watch-web, seed its prompt from the Triage (on a schedule) preset, and make sure it ends every run with a conclusion and can give the verdict investigate.
4. Create the root-cause agent with no trigger, seeded from the Root cause after a handoff preset. Its page then says only a handoff from triage starts it.
5. On the triage agent, under When it concludes, choose Add a handoff. Pick investigate, the root-cause agent and a cooldown (30m by default). In the catalog it looks like this:

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

6. Give the root-cause agent the tools it needs to gather evidence, since it receives the finding and not the logs. The full walkthrough is in Watch, then escalate.

Use one link or the other, a handoff or a trigger over findings, not both, or the root-cause agent runs twice per flag.

What you get

• A root-cause agent that starts with a short, focused briefing: the triage verdict, the entity and the numbers that moved.
• Fresh evidence gathered at the moment of the root-cause run, not a stale pile of log lines copied from triage.
• One thread on the project’s Activity: the tick, the triage finding and the root cause, in order. The Overview shows one card for the whole chain under What the agents found.
• Guardrails around the chain. At most one handoff per agent pair per entity within the cooldown. 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. When 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, so nothing is dropped silently.

For the full rules, see Hand off to another agent. The pattern sits in front of the alert-driven agent described in AI SRE.

When something else fits

• If you need a condition before escalating, such as several investigate findings in a window or findings from more than one agent, use a trigger over the findings source filtered to another agent’s findings instead of a handoff.
• If the root-cause agent should wake from alerts on its own schedule, give it its own trigger. A handoff is the simpler link when one agent’s verdict should start the other.

Related