What should I do when an AI SRE run on failed deploys ends as exhausted?

Tares ends a run as exhausted when the agent uses all its model rounds without concluding, and the fix is to raise max rounds for the agent that watches failed deploys. Set it under Advanced on the agent form or as max_rounds in catalog YAML, anywhere from 1 to 24. Unset, the limit is 6 rounds, or 12 once the agent uses external MCP servers. The run keeps its last text as a partial note, so you can read what the agent had so far.

How it works

Each Tares agent run has a budget of max_rounds model rounds, with 2,048 tokens per call. Every run records the cap it was held to and shows it as rounds/max.

When the budget runs out mid-investigation, this happens:

• The model gets one final call with tools disabled, so it can conclude from what it has already read.
• If that call produces a conclusion, the run ends normally.
• If it still cannot conclude, the run ends exhausted, keeps the last text as a partial note, and tells you to raise max rounds.

The default depends on the agent’s tools. Unset, it is 6 rounds. It becomes 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. If your agent for failed deploys reads that kind of material through an MCP server, it already starts at 12.

See Tares agents for the full runtime and guardrails, and AI SRE for the loop these agents belong to.

Set it up

1. Open the agent’s page and go to Runs. Filter to failed runs if the list is long. Find the exhausted run and compare its rounds/max value with the cap.
2. Read the partial note on that run to see how far the agent got before it ran out of rounds.
3. In the console, open the project’s Advanced setup, open the agent that handles failed deploys, and edit it. Under Advanced, raise max rounds. Pick a value from 1 to 24. Raise it a few rounds at a time rather than jumping to 24.
4. If you manage agents as a catalog, set max_rounds on the agent in the YAML instead:

agents:
  - name: incident-first-look
    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.

5. Fire the trigger again and open the new run under Runs. Check that it ends with a conclusion and that rounds/max shows headroom.

If the agent keeps exhausting even at a higher cap, tighten its prompt so it concludes from the evidence it has. The prompt is the one thing you configure per agent besides the provider and model.

What you get

• A run that has enough rounds to read the timeline, look at a wider window or another entity if it needs to, and conclude.
• A finding on 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 every run. Each one shows its status, rounds, duration and errors, and rounds/max tells you how close it came to the cap.
• A partial note on any run that still ends exhausted, so you do not lose the work it did.

The other guardrails stay as they are. The agent runs at most once per the trigger’s cooldown per entity, and at most 50 runs per agent per day, so a higher round cap does not remove the limits on how often it runs.

When something else fits

• If runs fail for another reason, such as a missing model provider, max rounds is not the cause. Without a provider, each firing is logged as “no model provider” and no finding is written, so check Settings and Model providers first.
• If the agent reaches a conclusion but the answer is thin, a different model or a sharper prompt helps more than extra rounds.

Related