How does an AI SRE remember what fixed crash loops last time?

Tares keeps what an agent concluded about a service on that service’s timeline, so the next crash loop investigation starts from the last conclusion. Agents write findings back to the timeline, and any connected agent can save an observation with the remember tool. A later read returns the logs, alerts and metrics together with those earlier conclusions.

How it works

Tares builds one correlated timeline per entity, such as a service, from every source that carries the same label. Memory lives on that same timeline, so there is no separate store to query.

• Findings. When a trigger wakes an agent, the agent reads the timeline, names the likely cause and a next action, and writes a finding onto the service’s timeline. The finding shows on the project’s Overview under what the agents found, and on the service’s timeline in Explore.
• Observations. Any connected agent can call the MCP remember tool, or POST /remember, to save its own observation against an entity. The memory connector stores it, keyed by that entity.
• Reads. Memory is joined into reads and triggers like any other source. What an agent concluded about service=checkout last week sits next to the service’s logs and deploys in the same timeline.

So when a service enters a crash loop again, the agent that investigates reads the fresh evidence and the earlier conclusions together. If an earlier note says a pool-size change caused the problem, the new investigation starts there. Every investigation leaves the timeline a little smarter, which is the loop the AI SRE guide builds end to end.

The first remember call creates an agent_memory source for you, and every connected agent has the tool. If a memory has no entity in its payload, Tares keys it by the fallback key, which is agent by default.

Set it up

1. Start Tares and, in a second shell, the MCP endpoint. The AI SRE guide shows the full demo wiring if you want a working system to try this on.

   tares up
   tares mcp

2. Connect your MCP client to the endpoint at http://127.0.0.1:8788/mcp. The client then has the remember tool, plus the read tool that returns the correlated timeline.

3. Make sure your sources for the service share one label, such as service, so metrics, logs and alerts land on one timeline. Add a trigger that wakes an agent when the service misbehaves. The agent’s finding is then written onto that timeline automatically.

4. After you or the agent fix a crash loop, record what worked. Ask your connected agent in plain words:

   Use tares to remember that the checkout crash loop was fixed by rolling back the pool-size change.

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

6. Next time, ask your client what happened to the service. It reads the evidence and the earlier findings and observations together.

You only need to create the memory source yourself when you want a custom fallback key or several memory lanes. Add it in the console or in YAML:

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

The key field is the fallback entity key used when a memory’s payload has none.

What you get

• A starting point for every investigation. The agent reads the last conclusion for the service along with the current logs, alerts and metrics, so it does not rebuild the story from nothing.
• One place for history. Findings, remembered observations, deploys and logs share the entity’s timeline, so a past fix sits next to the events around it.
• Memory from humans and agents alike. Any agent connected over MCP can write an observation, and triggered agents write findings on their own.
• Visible records. You can open a finding for the full note and how Tares got there, and see remembered observations in the memory source’s Recent events.
• No extra setup to begin. The first remember call provisions the memory source.

When something else fits

• If you only need to see what happened in the last few minutes, a plain read of the timeline is enough and you do not need to write anything to memory.
• If your team already keeps fix notes in runbooks, the reference connector is not the tool for that. Tares has a separate reference source type for documents attached to an entity by its labels, which is the better fit for fixed procedures rather than an agent’s own conclusions.

Related