How does an AI SRE remember what fixed a cron job that stopped last time?

Tares keeps an agent’s findings and remembered observations on the entity’s timeline, so the next investigation of a cron job that stopped starts from the last conclusion. The agent writes what it concluded with the remember tool, and the entry sits next to the entity’s logs, alerts and deploys. The next agent or MCP client that reads that entity gets the evidence and the earlier conclusion together.

How it works

Two things leave a record on the timeline of the entity you investigate, for example the service or job your sources are keyed by.

• Findings. When a trigger wakes a Tares agent, it reads the correlated timeline and writes a finding onto that entity’s timeline: what broke, since when, the likely cause tied to evidence lines, and a next action.
• Memory. Any connected agent can call the MCP remember tool (or POST /remember) to record an observation, such as what fixed the problem. Tares stores it through the memory connector, keyed by the entity it was remembered against.

Because memory is a source like any other, what an agent concluded about an entity last week sits in the same timeline as that entity’s logs and deploys. It is also joined into reads and triggers like any other source.

When the cron job stops again, the next investigation reads that timeline. The evidence and the earlier finding or remembered fix arrive together, so the agent starts from the previous conclusion instead of from scratch. This is the loop described in Build an AI SRE: every investigation leaves the timeline smarter.

Set it up

1. Follow Build an AI SRE to wire your sources, a trigger and an agent. Key all sources for the cron job by the same label, so they merge into one timeline for that entity.
2. Start Tares and the MCP endpoint, each in its own shell.

tares up
tares mcp

3. Connect your agent or MCP client to the endpoint. Every connected agent has the remember tool.
4. After you fix the stopped cron job, ask the agent to record what worked. No memory setup is needed. The first remember call creates an agent_memory source for you. An example request:

Use tares to remember that the nightly cron job stopped because of the cause you found, and that the fix was the step you applied.

5. Check the result. 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. 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

7. The next time the job stops, ask your client about that entity. It reads the correlated evidence and the stored finding or memory together.

What you get

• A record of what fixed the cron job, stored on the entity’s timeline instead of in a chat that ends.
• Investigations that begin from the last conclusion. The agent sees the earlier cause and fix beside the current logs, alerts and deploys.
• The same history for every agent. A Tares agent woken by a trigger and an MCP client you use interactively read the same timeline, so both see the same findings and memories.
• A way to confirm what was stored. Recent events on the memory source and the entity’s correlated timeline show each observation.
• A memory that works in triggers too, because it is joined into reads and triggers like any other source.

When something else fits

• If you only need a human-readable note, such as a runbook that always applies to an entity, a reference source attaches documents to an entity by its labels. Memory is for what agents learn during incidents.
• If the cron job has no signal in Tares yet, add its logs, alerts or deploys as sources first, keyed by the same label. Otherwise the remembered fix has no evidence timeline to sit in.

Related