How does an AI SRE remember what fixed failed deploys last time?
Tares keeps what an agent concluded about failed deploys on the service’s timeline, so the next investigation starts from the last conclusion instead of from scratch. Agents write findings and observations back to that timeline, and the remember tool stores what fixed a failure against the entity it concerns. The next agent that reads the service sees the deploy events, the logs and that earlier conclusion in one correlated read.
How it works
Tares builds one timeline per service. Every source that carries the same label, such as service, merges into it on one clock: metrics, logs, alerts, and deploy events from a webhook source. Two kinds of write-back sit on that same timeline.
- Findings. When a trigger wakes an agent, the agent reads the correlated timeline and writes a finding onto the service’s timeline. The finding says what broke, since when, the likely cause tied to evidence lines, and a next action.
- Memory. The
memoryconnector holds an agent’s own observations, written with the MCPremembertool orPOST /remember. Every connected agent has the tool.
A memory is keyed by the entity it was remembered against. If the payload has no key, Tares uses a fallback key, which defaults to agent. Memory joins 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.
When the next failed deploy happens on that service, an agent that reads the timeline gets the earlier deploy event, the errors that followed, and the finding or memory that recorded what fixed it. The AI SRE guide describes this as the loop closing: every investigation leaves the timeline smarter.
Set it up
-
Start Tares and the MCP endpoint, then connect your agent. The AI SRE guide walks through the full setup, including the Claude Code command for adding the endpoint.
tares up tares mcp -
Keep your sources keyed by the same
servicelabel, including a webhook source that records each deploy as an event. Each deploy then lands on that service’s timeline, next to the errors that follow it. -
Let a trigger wake an agent when a service misbehaves. In the AI SRE guide, the
incident-first-lookagent reads the timeline and writes a finding onto it. Findings appear in the console under What the agents found and on the service’s timeline in Explore. -
After you resolve a failed deploy, ask your connected agent to remember the fix. You can use plain language:
Use tares to remember that the checkout latency spike on July 1 was caused by the pool-size change.
The first
remembercall creates anagent_memorysource for you. You need no setup for this. -
Only if you want a custom fallback key, or several memory lanes, create a
memorysource yourself in the console or in YAML. See agent memory for the connector page.- name: agent_memory connector: memory config: key: agent -
Check that it worked. After a
remembercall, the observation appears in the source’s Recent events, keyed by the entity you remembered it against, and in that entity’s correlated timeline.
What you get
- The next investigation of a failed deploy starts from the last conclusion. The agent reads the evidence and the earlier finding together, so it does not rebuild the diagnosis from nothing.
- Fixes are recorded against the entity they belong to. A note about
service=checkoutshows up when you readcheckout, alongside that service’s logs and deploys. - Past conclusions are available to triggers as well as to reads, because memory joins them like any other source.
- Any connected agent can write and read memory. Claude Code, Cursor, Codex and your own MCP clients all have the
remembertool, so what one agent learned is there for the next. - Findings show up in the console with a headline and a next step, and you can open one for the full note and how Tares got there.
When something else fits
- If you want a fix to be a durable, reviewable document such as a step-by-step runbook, a
referencesource attaches documents to an entity by its labels and always surfaces them when correlating. Use it alongside memory, which fits short observations better. - If the question is what is happening right now rather than what fixed it last time, read the live timeline through your MCP client. Memory only helps when someone has written a finding or an observation.