What verdict and next step should an AI SRE record for high latency?

Tares lets the agent end a high latency run with the conclude tool. If latency is normal, it ends with no_op and Tares records no finding. If one entity looks slow, it records a finding with a verdict such as investigate, a headline of up to 100 characters and a next step of up to 300 characters. The verdict words are yours to define, and the presets give you investigate, rca and resolved.

How it works

An agent set to end every run with a conclusion gets the conclude tool and ends each run on purpose. For high latency, the run ends in one of two ways:

• no_op: nothing to report, so no finding is recorded. Use it when latency is back to normal or never crossed the line.
• A finding: a verdict about a named entity, such as the service that is slow, plus a headline and a next step.

The finding carries three fields:

• verdict: one word from your own list, with a description of when to give it.
• headline: one line of up to 100 characters, what was found in the reader’s terms.
• next_step: up to 300 characters, what a person should do. Leave it empty when nothing needs doing.

The project’s Overview shows the headline and next step on each card, and agents are told to give both. If a run omits them, Tares takes the headline from the note’s heading, bold lead or first sentence. It takes the next step from the text after “Next step:”, “Next:” or “Recommendation:”.

For high latency, this maps onto the verdicts the presets already ship:

• investigate: the triage agent sees one entity with high latency that needs a closer look. The next step says who looks, and where.
• rca: after a handoff, the agent found what is failing and why. The next step says what to change or fix.
• resolved: the latency was noise, or it is already over. The next step is empty, because nothing needs doing.

A headline in the reader’s terms reads like “Checkout latency is up” and not like a metric name. A next step reads like a task for a person, for example “Check the checkout service’s recent deploy and its database calls.” These two lines are illustrations of tone, not fixed text.

Set it up

1. Open the agent form and find the How it ends section.
2. Tick Ends every run with a conclusion. In YAML this is concludes: true. The agent then always gets the conclude tool, and Tares adds the instructions for it, so your prompt only describes the job.
3. Under Verdicts it can give, add your own words, each with when to give it. You can add up to 10. Each is one word of letters, digits or dashes, listed once, and none is no_op, because nothing to report is always possible.
4. For a latency triage agent, start with investigate and describe it in your own terms, as in this example.

agents:
  - name: triage
    trigger: watch-web
    concludes: true
    verdicts:
      - { verdict: investigate, when: one entity looks like a problem and needs a closer look }
    prompt: |
      ...

5. In the prompt, describe only the job, for example which latency signal to look at and what counts as slow for your service. Do not repeat the conclude instructions.
6. For a second agent that runs after a handoff, add rca and resolved with the descriptions the preset uses: you found what is failing and why, and it was noise or it is already over.

The Triage (on a schedule) preset comes with investigate. The Root cause after a handoff preset comes with rca and resolved. The agent’s summary shows how it ends, and its handoffs key off these verdict words, so pick words you want to route on. How a run ends covers every option on the form. For the wider picture of how an agent watches and escalates, start at AI SRE.

With a verdict list in place, the conclude tool accepts only your words and tells the model what each means. A finding must carry one. An off-list word or a missing verdict goes back to the agent to fix within the same run. If a run stops without concluding, Tares asks once more with conclude as the only choice.

What you get

• Every latency run ends with a clear outcome: no finding when all is well, or a finding about a named entity.
• Each card in the project’s Overview shows a one-line headline and a next step, so a person knows what to do without opening the run.
• A verdict list you control, so the words match how your team talks about latency.
• Handoffs can key off the verdict. For example, a triage agent’s investigate can pass work to an agent that gives rca or resolved.
• Corrections happen inside the run. A missing or off-list verdict goes back to the agent to fix before the run ends.

When something else fits

• If you want the agent’s last message to be its finding with no verdict, leave the conclusion box off. You then get free text and nothing to route on.
• If you do not set a verdict list, a finding can carry any verdict, or none. That is fine for a first try, but a list gives you consistent words for handoffs.

Related