What does it mean when an agent run ends as exhausted, and how do I fix it?

When a Tares agent run ends as exhausted, it used up its max_rounds model rounds before it could conclude, and you fix it by raising max rounds. Set it under Advanced on the agent form or as max_rounds in catalog YAML. Tares keeps the last text the model wrote as a partial note, so you do not lose the work done so far.

How it works

Every Tares agent runs on a fixed budget. The budget is max_rounds model rounds, from 1 to 24, with 2,048 tokens per call. If you leave it unset, the default is 6. Once the agent uses external MCP servers, the default is 12, because a run that reads a diff or a file and then writes back needs more than a read-and-conclude run.

When the rounds run out in the middle of an investigation, Tares does not cut the run off. The model gets one final call with tools disabled, so it has to conclude from what it has already gathered.

• If the model concludes in that final call, the run ends normally.
• 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.

Every run records the cap it was held to and shows rounds/max. A run that shows 6/6 or 12/12 used its whole budget.

Set it up

1. Open the agent’s page and go to Runs. Find the run that ended as exhausted and check its rounds/max value and its partial note. The list can be filtered to failed runs only.
2. Decide on a new cap. Pick a value from 1 to 24. If the agent reads diffs, files or other external data through MCP servers, give it more rounds than a read-and-conclude agent needs.
3. In the console, open the project’s Advanced setup, edit the agent, open Advanced on the agent form and raise max rounds. Save it.
4. If you manage agents as a catalog, set max_rounds on the agent in 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               # 1 to 24
    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 agent’s trigger again. After the trigger’s cooldown has passed for that entity, the agent runs with the new cap. Check the new run under the agent’s Runs and confirm that it ends with a verdict or a finding and a rounds/max below the cap.

If the run still ends as exhausted at a higher cap, tighten the prompt so the agent asks for less, or narrow what it reads. Raising the cap past what the task needs only adds rounds to each run.

What you get

• A run that finishes with a finding on the entity’s timeline instead of a partial note.
• A clear record of how much budget each run used, because every run shows rounds/max.
• A partial note from the exhausted run, so you can see how far the agent got and what it had already found.
• A run that fails or is inconclusive is recorded under the agent’s Runs and never pollutes a timeline.

The other guardrails stay in place when you raise the cap. The agent still runs at most once per the trigger’s cooldown per entity, and at most 50 runs per agent per day. A higher max rounds makes each run longer, not more frequent. The Build an AI SRE guide shows the whole loop from trigger to finding on a demo system.

When something else fits

• If the agent reaches the cap on every run, even at 24 rounds, the prompt asks for too much in one run. Split the work across two agents and use a handoff, described on the Tares agents page.
• If runs fail with “no model provider” instead of ending as exhausted, the cause is the model provider, not the round budget. Set one in Settings → Model providers or with an API key in the daemon’s environment.

Related