How does an AI SRE remember what fixed slow database queries last time?

Tares keeps an AI SRE’s conclusions on the entity’s timeline, so the next investigation of slow database queries starts from the last conclusion instead of from scratch. Findings the agent records and observations it writes with the remember tool sit in the same timeline as the service’s metrics, logs and alerts. When you or an agent read that service again, the earlier fix is part of the evidence.

How it works

Tares does the data side and you bring the agent. Every source is labeled by the same entity, for example service, and Tares merges them into one timeline per entity. Two things write conclusions back onto that timeline:

• Findings. When a trigger wakes an agent, the agent reads the correlated timeline and writes a finding onto the entity’s timeline. The finding says what broke, since when, the likely cause tied to evidence lines, and a next action. It is also listed on the project’s overview, and the same finding appears in Explore.
• Memory. Any connected agent can call the MCP remember tool, or you can send POST /remember. The observation is stored by the memory connector, keyed by the entity it was remembered against. It is joined into reads and triggers like any other source, so what an agent concluded about service=checkout last week sits next to the service’s logs and deploys.

The next investigation is a normal read of that entity. Because the read returns the evidence and the earlier finding or memory, the agent sees the last diagnosis, such as a pool-size change behind slow queries, before it looks at anything new. In the AI SRE guide, this is the loop closing: every investigation leaves the timeline smarter.

The memory source has one setting. key is the fallback entity key used when a memory’s payload has none, and it defaults to agent.

Set it up

1. Start Tares and the MCP endpoint. Run each command in its own terminal.

tares up
tares mcp

2. Connect your MCP client to the endpoint at http://127.0.0.1:8788/mcp. Per-client setup is on the agents pages linked from the AI SRE guide.
3. Make sure your sources carry the same entity label, such as service, so the database metrics, logs and alerts for a service land on one timeline. The AI SRE guide builds this wiring end to end.
4. Tell the agent what fixed the problem. Every connected agent has the remember tool, so a plain request is enough. For example:

Use tares to remember that the slow queries on checkout were fixed by raising the connection pool size.

5. No source setup is needed for memory. The first remember call auto-provisions an agent_memory source. Create a memory source yourself only to set a custom fallback key or to run several memory lanes:

- 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.
7. For the automatic path, subscribe a Tares agent to a trigger on that entity. When the trigger fires, the agent reads the timeline and writes its finding back. The next time slow queries show up, ask your client what happened to the service. It reads the evidence and the earlier finding together.

The agent memory connector page has the full field reference.

What you get

• A starting point for every investigation. The agent sees the last conclusion about the entity together with fresh metrics, logs and alerts, so it can check whether the earlier fix applies again.
• One place for human and agent knowledge. An observation you ask an agent to remember and a finding an agent records both sit on the entity’s timeline, next to the evidence they were drawn from.
• Context that follows the entity. Memories are keyed by the entity they were remembered against. Reading service=checkout returns what was concluded about checkout, not about everything.
• Memory that works with triggers. Because memory joins reads and triggers like any other source, what an agent wrote earlier is available to later investigations, interactive or automatic.
• No extra setup to start. The first remember call creates the memory source for you, and every connected agent already has the tool.
• A way to check the result. Recent events on the memory source and the entity’s correlated timeline both show what was stored.

When something else fits

• If you only need to attach fixed documents, such as a runbook, to a service, a reference source is the better fit. It holds documents attached by labels, while memory holds what an agent observed.
• If you want to keep the fix in your own system of record, send findings out through Slack or a write-back webhook as well. The timeline is still where the next Tares investigation reads from.

Related