How can an AI SRE see which values moved most during failed deploys?

Tares gives every agent a stats tool that counts each value of one label in the current window against the window before, with the largest change first. During failed deploys, the AI SRE sees which service, pipeline or environment moved most without reading a line of a busy stream. The agent has this tool by default, alongside read.

How it works

The stats tool is one of two tools a Tares agent has by default. The other is read, which returns one correlated timeline for an entity. Both go through the same Tares read path and cover the sources of the projects the run is for, unless the agent names others with sources.

For a failed-deploy investigation, stats works like this:

• You pick one label, such as the service, pipeline or environment that your deploy events carry.
• Tares counts the events per value of that label in the current window.
• Tares counts the same thing in the window before.
• Tares returns the values ranked by how much they changed, largest change first.

This suits a busy stream better than reading lines. A read of a stream with many events shows only the latest few, so a value that spiked earlier in the window can hide. A count per value, compared with the previous window, puts the biggest movers at the top. The agent can then use read on the entity that stands out to get its correlated timeline.

By default the agent reads and concludes. It does not restart, deploy or ticket anything. The Tools and MCP servers page covers this boundary and how external MCP tools change it for one agent.

Set it up

1. Install the CLI and start Tares locally. On Tares Cloud, sign in with tares login instead.

uv tool install tares     # or: brew install glassflow/tap/tares
tares up

2. Add a source that carries your deploy events, and give it labels for the fields you want to compare. Mark one label as primary. This example takes CI events and labels them by pipeline:

- name: ci-events
  connector: webhook
  config:
    event_type_field: action
    text_template: '{action} by {sender}'
    labels:
      - { name: pipeline, field: pipeline, primary: true }

3. Create an agent for the project that owns that source. It has read and stats without any extra configuration, and both cover the project’s sources.
4. Ask the agent which values moved most during the failed deploys. It calls stats on the label that fits, for example the pipeline, and works from the ranked result.
5. If a failed-deploy signal lives in a source outside the project, name it with sources on the agent so stats covers it too.

For an overview of how an AI SRE fits together in Tares, see AI SRE.

What you get

• A ranked view of which values changed most between this window and the one before, so the likely cause of a bad deploy comes first.
• A readable result from a busy stream, where reading lines would show only the latest few events.
• A natural next step. The agent takes the top value and calls read for the correlated timeline of that entity.
• A recorded run. Each run records what it called, so you can check which reads the conclusion rests on.
• A read-only default. The agent does not restart, deploy or ticket anything unless you connect external tools for it.

When something else fits

• Use read when you already know the entity and want its correlated timeline instead of a ranking across values.
• Use external MCP tools, registered under Settings and opted into per agent, when you want the agent to act after it finds the cause, for example to open an issue. This moves the read-only boundary for that one agent, as described on Tools and MCP servers.

Related