How can I confirm an observation an agent remembered was saved and where it will show up?

Tares shows a remembered observation in two places right after the remember call. It appears in the memory source’s Recent events, keyed by the entity it was remembered against, and in that entity’s correlated timeline next to its logs and deploys. This holds for the MCP remember tool and for POST /remember.

How it works

An agent writes an observation with the MCP remember tool, or you send it with POST /remember. Tares stores it in a memory source, and every connected agent has the tool.

• Auto-provisioning. The first remember call creates a source named agent_memory. You do not set anything up beforehand.
• Entity key. Each observation is remembered against an entity, for example service=checkout. That entity is the key you see on the event.
• Fallback key. If the payload of a memory has no entity key, Tares uses the source’s key setting. The default is agent.
• Joined like any other source. Memories are joined into reads and triggers the same way as logs or deploys. What an agent concluded about service=checkout last week sits in the same timeline as the service’s logs and deploys.

So a saved observation is visible in two views of the same data: the raw list of events on the source, and the timeline of everything Tares knows about the entity. The Agent memory connector page describes the source in full, and AI SRE shows how agents use correlated context during an investigation.

Set it up

1. Ask a connected agent to remember something about a specific entity. For example:

   Use tares to remember that the checkout latency spike on July 1 was caused by the pool-size change.

   You can send the same observation with POST /remember instead.

2. Open the agent_memory source and look at Recent events. The new observation is listed there, keyed by the entity it was remembered against. If this was the first remember call, the source now exists because that call created it.

3. Open the correlated timeline of that entity, for example service=checkout. The observation sits in the timeline next to the entity’s logs and deploys, ordered with them.

4. If you want a custom fallback key, or several memory lanes, create a memory source explicitly in the console or in YAML. This step is optional:

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

5. Check the entity key on the event. If an observation shows the fallback key (agent by default) instead of the entity you expected, the memory’s payload carried no entity key. Ask the agent to remember it again against the entity you mean, such as service=checkout.

The key field is the only setting of the connector. It is a string that names the fallback entity key when a memory has none.

What you get

• Proof the write landed. The observation shows in Recent events on the memory source as soon as the remember call finishes.
• A findable entry. The event is keyed by the entity it was remembered against, so you can find it by the same label you use for logs and deploys.
• Context next to the evidence. In the entity’s correlated timeline the agent’s conclusion appears beside the service’s logs and deploys, so the next person or agent who reads the timeline sees what was concluded and what happened around it.
• Memory that triggers can use. Because memories are joined into reads and triggers like any other source, an observation is not a separate note. It is part of the data Tares reasons over.
• No setup for the common case. The first remember call creates the agent_memory source, and every connected agent already has the tool.

When something else fits

• If you need a document that is always surfaced for an entity, such as a runbook, the reference connector fits better than agent memory, because it attaches documents by labels and surfaces them whenever Tares correlates.
• If you need to record an event from a system outside your agents, send it through a source built for that system. The memory source is meant for what an agent itself observed or concluded.

Related