What should I do when an AI SRE run on high latency ends as exhausted?
Raise max rounds on the Tares agent that handles high latency, under Advanced on the agent form or as max_rounds in catalog YAML. An exhausted run means the agent used all its model rounds before it could conclude. Tares keeps the last text as a partial note, so you can see how far the investigation got.
How it works
Every Tares agent has a budget of model rounds per run, set by max_rounds.
- The value runs from 1 to 24.
- Unset, the default is 6. It is 12 once the agent uses external MCP servers, because a run that reads a diff or a file and writes back needs more than a read-and-conclude budget.
- Each call is limited to 2,048 tokens.
- Every run records the cap it was held to and shows it as
rounds/max.
When the budget runs out mid-investigation, the model gets one final call with tools disabled. It uses that call to conclude from what it has gathered. If it still cannot conclude, the run ends as exhausted. Tares keeps the last text as a partial note and tells you to raise max rounds.
A high latency investigation often reads several signals before it can name a cause, so it can use up a small budget. The run is recorded under the agent’s page, in Runs, with its status, rounds, duration and errors.
Set it up
- Open the agent’s page and go to Runs. Find the exhausted run and read its
rounds/maxvalue. This shows the cap it was held to. - Read the partial note. It shows what the agent had established before it ran out, which tells you whether the agent was close to a conclusion or still reading.
- Open the agent form, expand Advanced and raise max rounds. Pick a value between 1 and 24. Going from 6 to 12 is a reasonable first step.
- If you manage agents as a catalog, set
max_roundson the agent in catalog YAML instead:
agents:
- name: incident-first-look
project: Default # optional; the project that made it
trigger: incident # the trigger that wakes it
enabled: true # on in its project
max_rounds: 12
prompt: |
You are an SRE taking the first look when an alert fires on this service. You are handed the
correlated timeline: the firing alert plus the signals behind it and the request logs.
Produce a tight incident note: what is failing and since when, the most likely cause tied to
specific evidence lines, and a suggested next action. Do not speculate beyond the evidence.- Make sure the agent is on in its project. A new agent starts off, and it runs on the next firing once you enable it.
- Wait for the trigger to fire again, or fire it yourself as in the Build an AI SRE guide. The agent runs at most once per the trigger’s cooldown per entity, and at most 50 runs per agent per day. The new run records the higher cap, so you can compare
rounds/maxwith the earlier run.
What you get
- A run on high latency that has enough rounds to read the evidence and conclude, instead of stopping with a partial note.
- A finding written back to the entity’s timeline, with its headline, summary and next step shown on the project’s Overview under What the agents found.
- A clear record of each run’s cap in Runs, so you can tell whether a higher max rounds helped.
- The same setting in the console and in catalog YAML, so a change you test in the console can be shipped in a seed catalog.
When something else fits
- If the agent still ends exhausted at 24, narrow the prompt so it asks for less, or split the work across agents with a handoff. Each agent then has its own round budget.
- If the run fails or concludes inconclusive rather than exhausted, max rounds is not the cause. Check the error shown for the run in Runs.
- If you see no runs at all, check that the agent is enabled and that the instance has a model provider.