What should I do when an AI SRE run on 5xx errors on an API ends as exhausted?

Tares ends a run as exhausted when the agent uses all its model rounds before it concludes, so raise max rounds for that agent and fire its trigger again. Max rounds accepts 1 to 24 and defaults to 6, or 12 once the agent uses external MCP servers. An exhausted run keeps the last text it produced as a partial note and tells you to raise max rounds.

How it works

Each Tares agent run has a budget of model rounds. When a trigger fires on your 5xx errors, the agent reads the correlated timeline for the affected entity, can read a wider window or another entity, and then writes a finding. Every model call in that loop uses a round.

• The cap: max_rounds is 1 to 24. Unset, it is 6, or 12 once the agent uses external MCP servers, because a run that reads a diff or a file and writes back needs more than the read-and-conclude budget.
• Tokens: each call is limited to 2,048 tokens.
• Visibility: every run records the cap it was held to and shows rounds/max, so you can see how close it came.
• Last call: when the budget runs out mid-investigation, the model gets one final call with tools disabled to conclude from what it has.
• Exhausted: if the model still cannot conclude, the run ends exhausted. The last text is kept as a partial note, and the run says to raise max rounds.

An investigation of 5xx errors can take many rounds if the agent keeps widening the window or reading other entities. That is when the cap is most likely to bite. This is the same loop described in Build an AI SRE.

Set it up

1. Open the agent’s page and go to Runs. Find the exhausted run and read its rounds/max value. This shows the cap the run was held to.
2. Read the partial note. It holds the last text the model produced, so it often shows how far the investigation got and what the agent was still reading.
3. Raise max rounds. On the agent form, set max rounds under Advanced. If you manage agents as a catalog, set max_rounds in the catalog YAML instead. The value must be between 1 and 24.

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.

4. Fire the trigger again. The agent runs at most once per the trigger’s cooldown per entity, so a rerun may have to wait for the cooldown to pass. Each agent is also limited to 50 runs per day (TARES_AGENT_DAILY_CAP).
5. Check the new run under Runs. A run that concludes shows its verdict and headline in the outcome column, and its finding appears on the entity’s timeline in Explore.

What you get

• A run that has enough rounds to read the evidence and conclude, so the finding lands on the entity’s timeline with its headline, summary and next step.
• A clear view of how much budget each run used, because every run shows rounds/max.
• A partial note from the exhausted run, so the work it did is not lost while you adjust the cap.
• A bounded cost. The cap never exceeds 24 rounds, and the daily cap of 50 runs per agent still applies.

When something else fits

• If the run still ends exhausted at 24 rounds, tighten the prompt so the agent asks for less, for example a short incident note tied to specific evidence lines. The prompt is the one thing you configure per agent.
• If one agent has too much to cover, split the work and let one agent hand off to another, or use a connected agent over MCP that lives in your own infrastructure.

Related