How does an AI SRE remember what fixed high latency last time?

Tares keeps what an agent concluded about a service on that service’s timeline, so the next high latency investigation starts from the last conclusion instead of from scratch. Agents write findings after an investigation and can save their own observations with the remember tool. Both sit next to the service’s metrics, logs and alerts, so one read returns the evidence and the earlier fix.

How it works

Tares gives you two ways to keep a conclusion, and both land in the same place: the timeline of the entity the conclusion is about, such as service=checkout.

• Findings. When an agent investigates, it writes a finding onto the service’s timeline: what broke, since when, the likely cause tied to evidence lines, and a next action. In the AI SRE walkthrough, the incident-first-look agent does this when a trigger wakes it. The finding shows up on the project’s overview and on the service’s timeline in Explore.
• Memory. Any connected agent can call the remember tool (or POST /remember) to record its own observation, for example that a latency spike was caused by a pool-size change. The observation is stored in a memory source and keyed by the entity it was remembered against.

Because memories and findings join the same timeline as the service’s logs, metrics, alerts and deploys, they are not a separate store the agent has to remember to check. When the next agent reads the service, it gets the correlated evidence and the earlier conclusion together. A new high latency alert on api-server or checkout therefore arrives with what was concluded the last time that service slowed down.

The AI SRE guide shows the loop closing: after the agent writes its finding, you ask your connected client the same question again, and it reads the evidence and the finding, so it starts from the previous conclusion.

Set it up

1. Start Tares and build the AI SRE wiring from the AI SRE guide, so metrics, logs and alerts share a service label and a trigger wakes an agent when a latency alert fires.

tares up

2. Start the MCP endpoint in a second shell and connect your client, so you and your agents can read the timeline and call remember.

tares mcp

3. Let the agent write its finding. When the trigger fires, incident-first-look reads the correlated timeline and writes a finding onto the service. Try the latency scenario in the demo to see it.

4. Save what fixed it. Ask a connected agent in plain words:

Use tares to remember that the checkout latency spike on July 1 was caused by the pool-size change.

The first remember call auto-provisions an agent_memory source, so there is nothing to configure. Every connected agent has the tool.

5. Optional: create the memory source yourself, in the console or in YAML, only if you want a custom fallback key or several memory lanes. The key is the entity key used when a memory’s payload has none, and it defaults to agent.

- name: agent_memory
  connector: memory
  config:
    key: agent

6. Verify. After a remember call, the observation appears in the source’s Recent events, keyed by the entity it was remembered against, and in that entity’s correlated timeline. Details are on the agent memory connector page.

What you get

• A starting point for every investigation. The next agent that reads a service sees the last conclusion next to current metrics, logs and alerts, so it can check whether the earlier cause applies again.
• One place to look. What an agent concluded about service=checkout last week sits in the same timeline as the service’s logs and deploys. Nobody has to search a separate notes system.
• Memory that works for any connected agent. The tool is available to every agent you connect over MCP, and the HTTP route POST /remember covers your own code.
• A timeline that improves with use. Each investigation leaves a finding or observation behind, so the evidence grows richer every time something goes wrong.
• Zero setup for the common case. The agent_memory source is created on the first remember call.

For example, if a latency spike last month was traced to a pool-size change and the agent recorded that, the next latency alert on the same service brings that conclusion into the read. The agent can test it first, for instance by checking whether a recent deploy touched the pool again.

When something else fits

• If you only need to know what changed before an incident, a webhook source for deploys and config changes puts those on the timeline, and you do not need memory for that. Use memory for conclusions and findings for diagnoses.
• If you want a human-written fix procedure rather than an agent’s own conclusion, a reference source attaches documents such as runbooks to an entity by its labels, and they are always surfaced when correlating.

Related