How can an AI SRE see which values moved most during high latency?

Tares gives every agent a stats tool that counts each value of one label in the current window against the window before and lists the largest change first. During high latency you see which values moved most without reading a busy stream line by line. The tool is on by default and covers the sources of the projects the run is for.

How it works

Every Tares agent has two built-in tools, read and stats. Both go through the same Tares read path and both cover the sources of the projects the run is for, unless the agent names other sources with sources.

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

The point of stats is a busy stream. When a stream produces thousands of lines during a latency spike, reading lines only shows the latest few. stats summarizes the whole window instead, so the values that moved most are at the top of the result, whatever the line volume.

The label you count by comes from the labels you define on your sources. In the source examples for Tares, labels such as service or status each have a name and a field, and one label is marked primary. Counting by a label like that shows which services or statuses changed most while latency was high.

The agent gets other tools around these two:

• A skill tool, added when a project the run is for has skills. It loads one skill’s instructions by name, and each run records the skills it loaded.
• A conclude tool the agent can use to end its runs.

By default a Tares agent reads and concludes. It does not restart, deploy or ticket. Details on all of this are on the Tools and MCP servers page.

Set it up

You do not enable stats. It is part of every agent’s default tools. What you set up is the data it counts and, optionally, its scope.

1. Start Tares and the sources that carry your latency signal. Locally, start Tares with:

tares up

2. On each source, define labels for the fields you want to count by, and mark one as primary. A label has a name and a field, for example a service label. Any label you define is a candidate for stats.
3. Put those sources in the project the agent runs for. The agent’s stats and read tools cover that project’s sources by default.
4. If you want the agent to look at other sources, name them with sources on the agent. Without it, the agent uses the project’s sources.
5. If you want the agent to act on what it finds, register an external MCP server under Settings → MCP servers in a project’s Advanced setup. Then pick it on the agent’s form under External tools. Its tools are offered to the model next to read and stats, prefixed by server name, for example github__create_issue. A tool result is capped at 8,000 characters.
6. Open a run under Runs to review it. Each run records the skills it loaded and any external tools it called.

For the wider picture of how agents watch and investigate, see AI SRE.

What you get

• A ranked view of which values of a label changed most between this window and the one before, so a latency spike points at specific values rather than a wall of log lines.
• A summary that stays useful as the stream gets busier, because it counts values instead of returning the latest few lines.
• The same read path as read, so stats and read cover the same sources and agree on what they can see.
• A safe default. With only the built-in tools, the agent reads and concludes and touches nothing outside Tares.
• An audit trail. Each run records the skills it loaded and the external tools it called, 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. stats counts per value of one label and does not give a timeline.
• Connect an external MCP server when the agent should act on what it finds. By default Tares agents read and conclude, and you choose per agent which servers it may touch.

Related