How can an AI SRE see which values moved most during slow database queries?

Tares gives an AI SRE the stats tool, which counts each value of one label in the current window against the window before and lists the largest change first. During slow database queries, that shows you which values jumped, such as a tenant, a table or a status, without reading lines one by one. Every Tares agent has stats by default, next to the read tool.

How it works

The stats tool is one of two default tools on a Tares agent. Both go through the same Tares read path and cover the sources of the projects the run is for, unless the agent names other sources with sources.

• Counts per value. You choose one label. Stats counts how often each value of that label appears in the current window.
• Against the window before. Each count is set beside the count for the same value in the window before, so the output shows change, not just volume.
• Largest change first. The values that moved most come first, so the cause of the slowdown is near the top.

This suits a busy stream. When a source produces many events, reading lines only shows you the latest few. Stats summarises the whole window instead.

Stats is for the overview. When one value stands out, the read tool gives the agent a single correlated timeline for that entity. By default an agent reads and concludes. It does not restart, deploy or ticket anything. If you register external MCP servers and opt the agent in, it can use their tools too, and each run records what it called. The full list of tools is on the Tools and MCP servers page.

Set it up

1. Start Tares locally, or sign in to Tares Cloud.

   tares up

2. Put the data about your slow queries into a source of a project. Give the source a label for each value you want to compare, with one label marked primary. A source declares labels like this, shown here on a Postgres source:

   - name: orders
     connector: postgres
     poll: 10s
     config:
       dsn: postgresql://user:pass@host:5432/appdb
       table: orders
       cursor_column: updated_at
       columns: id,tenant_id,status,amount,updated_at   # empty = every column
       labels:
         - { name: tenant_id, field: tenant_id, primary: true }
         - { name: status, field: status }

3. Create an agent for that project. It has read and stats without any extra setup, and it covers the sources of the projects its run is for.

4. If you want the agent to look only at some sources, name them with sources.

5. When the slowdown happens, have the agent run stats on the label you care about. Look at the values at the top of the result, then let the agent use read on the entity behind the biggest mover.

For how this fits into the wider AI SRE setup, see AI SRE.

What you get

• A ranked view of which values of a label changed most between this window and the window before.
• A summary of the whole window, not just the latest few lines of a busy stream.
• A clear next step: the top value is the entity to hand to read for a correlated timeline.
• A read-only default. The agent reads and concludes, and does not act on your systems.
• An audit trail if you add external tools. Each run records 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 its correlated timeline instead of a ranking of values.
• Use an external MCP server when the agent has to act, for example to create an issue. You register the server and opt the agent in, and tool results are capped at 8,000 characters.

Related