How does an AI SRE remember what fixed a disk filling up last time?

Tares keeps what an agent concluded on the entity’s timeline, so the next investigation of a disk filling up starts from the last conclusion. Agents write findings and observations back with the remember tool, and the memory sits next to the entity’s metrics, logs and alerts. When the disk alert fires again, the agent reads the old conclusion together with the new evidence.

How it works

Two things carry the memory, and both land on the same per-service timeline.

• Findings. When a Tares agent wakes on a trigger, it reads the correlated timeline and writes a finding onto the entity’s timeline: what broke, since when, the likely cause tied to evidence lines, and a next action. The finding stays there after the incident ends.
• Memory observations. Any connected agent can call the MCP remember tool (or POST /remember) to write its own observation. The memory connector stores it keyed by the entity it was remembered against. An agent might record that a disk filled because of a particular cause and what cleared it.

Because the memory is joined into reads and triggers like any other source, what an agent concluded about an entity last week sits in the same timeline as that entity’s logs and deploys. Nothing separate needs querying. When a disk-space alert arrives for the same entity, the agent’s read returns the new evidence and the earlier conclusion together, so it starts from what was found before instead of from scratch.

This is the loop the AI SRE guide describes: a trigger wakes an agent, the agent names the root cause and writes the conclusion back where the next investigation will find it. Every investigation leaves the timeline smarter.

Set it up

1. Start Tares and connect your sources, keyed by the same label for each entity, such as service. The AI SRE guide walks through metrics, logs and alerts on one timeline per service.

tares up

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

tares mcp

3. Let the agent write its conclusion. No setup is needed for memory: the first remember call creates an agent_memory source for you. After a disk investigation, ask your agent in plain words:

Use tares to remember that the disk filling up on this host was fixed by clearing the old logs.

4. Optional: create the memory source yourself 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

5. 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.

6. Next time the disk alert fires, ask your client what happened to that entity. It reads the evidence and the earlier finding or memory in one read.

What you get

• A fix you found once stays attached to the entity instead of living in someone’s head or a closed chat.
• Each new investigation of a disk filling up opens with the last conclusion next to the current metrics, logs and alerts.
• Findings from Tares agents and observations from your own agents land in the same place, so a human or any MCP client sees them in Explore.
• Memories are keyed by entity, so what you recorded about one service does not mix with another.
• No extra infrastructure. The memory source is created on the first remember call, and you can check it in Recent events.

When something else fits

If you want runbook steps that never change, such as a fixed procedure for freeing space, a reference source attaches documents to an entity by its labels instead of relying on what an agent concluded. If you only need a quick answer for one incident and no history, a plain read of the correlated timeline is enough, and you can skip writing memories.

Related