How can an AI SRE see which values moved most during error spikes?

Tares gives an AI SRE agent the stats tool by default, and it counts each value of one label in this window against the window before, largest change first. During an error spike the agent sees which services, environments or other label values moved most, instead of reading the latest few lines of a busy stream. Stats is routed through the same Tares read path as the agent’s other reads and covers the sources of the projects its run is for.

How it works

A Tares agent has two tools by default, both routed through the same Tares read path:

• read returns one correlated timeline for an entity.
• stats returns counts per value of one label, this window against the window before, largest change first.

The ordering is what helps in a spike. On a busy stream, reading lines only shows the latest few, and those may not be the ones that changed. Stats puts the values with the largest change between the two windows at the top, so the agent can start from the values that moved and then use read to pull a correlated timeline for one of them.

Both tools cover the sources of the projects the run is for, unless the agent names other sources with sources. This is the same way an agent works in AI SRE: it reads the evidence Tares holds and concludes.

By default an agent reads and concludes. It does not act, so it does not restart, deploy or open tickets. If you connect external MCP servers to a specific agent, that agent can use their tools, and each run records which external tools it called. Full details are on the tools and MCP servers page.

Set it up

1. Install the CLI and start Tares locally.

tares up

2. Connect the sources that carry your errors, and declare labels on them. A label is a named field of the event, and one label is marked primary. This example is an OTLP source with a service label:

- name: otel
  connector: otlp
  config:
    labels:
      - { name: service, field: service, primary: true }

3. Put the sources in a project and create an agent for that project. The agent gets read and stats without any extra setup, and both cover the project’s sources.
4. If the agent should look at sources outside its project, name them with sources on the agent. Stats then covers those sources too.
5. Ask the agent about the spike, for example which service or environment changed most. The agent calls stats on one label and gets the values ordered by change, largest first.
6. Optional: if the project has skills, the agent also gets the skill tool, which loads one skill’s instructions by name, and each run records the skills it loaded. You can use this to give the agent your own steps for reading a spike.
7. Optional: register an MCP server under Settings, MCP servers, and opt the agent in under External tools if it should act on what it finds. Tool results from an external server are capped at 8,000 characters, and a server that is down when the run starts is skipped and logged.

What you get

• A ranked view of one label, with each value counted in this window and in the window before, so the biggest movers come first.
• A way to read a busy stream without scrolling through lines that show only the latest few.
• A quick path from a moved value to a correlated timeline, because read is available to the same agent over the same sources.
• A clear boundary. The agent reads and concludes, and you decide per agent whether any external tool can act.
• A record of each run, including the external tools it called and the skills it loaded, shown on the run under Runs.

When something else fits

• Use read when you already know the entity and want one correlated timeline for it, rather than a ranking of label values.
• Use AI SRE for the wider picture of how agents watch your systems and escalate. Stats is one of the tools they use.
• If you want something to act on a finding, such as restarting or ticketing, connect an external MCP server to that agent. Without one, the agent only reads and concludes.

Related