How does an AI SRE remember what fixed 5xx errors on an API last time?

Tares keeps each finding on the service’s timeline and lets your agent write observations with the remember tool, so the next investigation of 5xx errors on your API starts from the last conclusion. Findings and memories sit in the same correlated timeline as the service’s metrics, logs and alerts. When an agent reads that timeline, it sees what fixed the problem before, not only what is broken now.

How it works

Two things carry the memory, and both attach to the entity the problem happened on, for example service=api-server.

• Findings. When a trigger wakes an agent on a 5xx alert, the agent reads the correlated timeline and writes a finding back onto the service’s timeline: what broke, since when, the likely cause tied to evidence lines, and a next action. The finding shows in Explore next to the metrics and logs.
• Memory observations. Any connected agent can call the MCP remember tool, or POST /remember, to record its own conclusion. The first call creates an agent_memory source for you. Tares stores the observation under the entity it was remembered against, and the memory connector joins it into reads and triggers like any other source.

Because the memory is keyed by the same label as your metrics, logs and alerts, what an agent concluded about the service last week sits in the same timeline as today’s evidence. If a memory has no entity in its payload, Tares files it under a fallback key, which defaults to agent.

The next time the 5xx rate climbs, the agent reads one timeline that holds the new alert, the error logs, and the earlier finding or memory such as “the spike was caused by the pool-size change”. It starts from that conclusion instead of from scratch. The AI SRE guide builds this loop end to end.

Set it up

1. Install Tares and start it locally. The guide’s demo uses the same two commands.

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

2. Start the MCP endpoint in a second shell and connect your agent or MCP client to it. Every connected agent has the remember tool.

tares mcp

3. Label your sources by the same key, such as service, so the 5xx metrics, error logs, alerts and memories land on one timeline per service. The AI SRE guide shows the three sources and the trigger that wake an agent on a fired alert.

4. After you fix an incident, tell the agent what worked. No source setup is needed, because the first remember call creates it:

Use tares to remember that the api-server 5xx spike was fixed by rolling back the last deploy.

5. Only if you want a custom fallback key or several memory lanes, create a memory source yourself in the console or in YAML:

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

6. Check that it worked. The observation appears in the source’s Recent events, keyed by the entity it was remembered against, and in that entity’s correlated timeline.

7. On the next incident, ask your client what happened to api-server. It reads the evidence and the earlier finding together.

What you get

• A timeline per service that keeps its own history of conclusions, so a repeat 5xx incident does not start from zero.
• Findings written by the wake-up agent and observations written by any agent or by you through remember, all in one place.
• The same memory for every connected agent, whether it is the built-in agent that a trigger wakes or your own MCP client investigating on demand.
• Memories that trigger conditions can use as well, because the memory source is joined into reads and triggers like any other source.
• A guide you can follow end to end: each investigation leaves the timeline smarter, and the next agent reads the previous conclusion along with the live metrics, logs and alerts.

When something else fits

• If you need runbook steps that are always shown for a service, regardless of what an agent concluded, the reference connector attaches documents to an entity by its labels and surfaces them every time you correlate.
• If your 5xx fix history lives in a ticket tracker, read those tickets through the Linear or GitHub Issues connectors instead of copying them into memory.

Related