Remember past investigations

Without memory, every investigation starts from nothing. An agent that diagnosed a problem last week reaches the same conclusion the same slow way this week, and nobody learns that the problem has now happened five times.

Memory changes that. An agent with memory enabled records what it concluded when it reaches a diagnosis, recognizes when a later investigation reaches the same conclusion and counts the recurrence, and searches those records at the start of a new investigation to find out whether it has seen this before.

Both halves show up in the investigation’s tool calls. A memory search runs near the start, before the agent has looked at anything else, and the record is written at the end, when it has a diagnosis.

The agent decides what to record and whether something is a recurrence. Grepr does not extract conclusions on its behalf or merge records by similarity, because the investigating agent is the only thing that saw the evidence.

Memory is off until you turn it on and choose where the memories are stored.

What an agent records

An agent records at most one memory per investigation, written when it reaches a diagnosis rather than after the fact. Each memory holds:

An agent can correct its own memory for an investigation while that investigation is running, so an early diagnosis it later disproves does not stay on the record. Correcting a memory does not count as a new recurrence.

Significance

Significance is how an agent classifies what it found, and it decides how the memory can be found later:

Benign memories are recorded but not indexed for search by meaning or by text. They are reachable only by a timeline search over their entity tags. This keeps the large number of routine all-clear findings out of the way of searches for real problems, at the cost of making them harder to find. If you want an agent to notice that a given service has been triaged as benign many times, search the timeline for that service rather than searching by text.

Turn on memory

Memory needs somewhere to store its search index and a model to build that index with, so there are three things to set up.

Step 1: Create a vector index integration

1. On the Integrations page, next to the S3 Vector Index section heading, click Add new.
2. In the Add Vector Index dialog, enter a Name and the number of Dimensions the embedding model you plan to use produces, then click Create.

The dimensions must match the model’s output, so choose the embedding model first and use its dimension count. An index’s dimensions are fixed after creation.

Step 2: Create an embedding integration

Memory embeds each record with a model from an LLM integration that provides embeddings. If you do not have one, create it before you continue. See Configure LLM provider connections with a Grepr integration.

An agent’s reasoning model and its embedding model are separate choices. An agent can reason with one integration and embed with another.

Step 3: Turn on memory for the agent

1. On the agent’s page, go to the Memory step.
2. Turn on Remember past investigations.
3. Under Storage, select the Vector index integration, the Embedding credentials, and the Embedding model.
4. Save the agent.

Grepr creates the search index when you create the vector index integration in Step 1, and discards the integration if the index cannot be created. Saving the agent then checks that the embedding model actually works against that index, by embedding a test value with it. So a wrong model or an unusable credential stops the save rather than surfacing later as memories that were never indexed.

Choose an embedding model and keep it

A memory is embedded with the model the agent had when it was recorded, and a query can only be compared against embeddings from the same model. Changing an agent’s embedding model therefore cuts its new memories off from the ones it already recorded, as far as searching by meaning is concerned. Treat the choice as long lived.

Using the same model across several agents does not pool their memories into one semantic search. A search by meaning always targets one agent, as described next.

How an agent searches its memory

A search runs in exactly one of three modes, and which mode fits depends on what the agent is trying to find:

Semantic search finds a past incident described in different words, which text search misses. Text search finds a literal, such as an error code or a host name, which semantic search can rank poorly. Timeline search needs entity tags rather than a query, and it is the only mode that returns benign memories.

The modes also differ in how much they cover, which matters when you read an empty result:

• A semantic search covers one agent at a time, because a query is only comparable against embeddings made with that agent’s model. An empty semantic result means nothing similar was found within what the search could reach. It is not evidence that the agent recorded nothing similar, and it is not evidence that your organization has not seen the problem. A memory embedded with a model the agent no longer uses is unreachable until it is embedded again, and a search that cannot reach the embedding provider returns empty as well. When an empty result matters, confirm it with a text or timeline search, which read the records directly.
• A text or timeline search covers every agent in your organization by default, so it is the one to use when you want the organization’s whole history.

So to find out whether any agent has seen something, search by text or timeline, or repeat the semantic search against each agent you care about.

A result carries the memory’s content along with its recurrence count, how long ago it was recorded, when it was last seen, and whether it is active, recent, or historical. There is no relevance score, because the agent judges from the content and the provenance rather than a ranking number.

Search returns at most 50 results and has no pagination, so a broad query can be incomplete. Narrowing by entity tags or by significance is more effective than raising the limit.

Entity tags

Entity tags are what make memories findable by the thing they are about, such as a service, a pipeline, or an environment. Each memory carries two kinds:

• Tags Grepr derives from the triggering signal, which identify the source and the signal type.
• Tags the agent adds, which name the entities it concluded the memory is about.

Grepr derives its tags using a mapping per signal type, which extracts values from the signal payload by path. The shipped mappings cover the common cases:

The webhook mapping reads the service and host from field names Grepr expects. If your payloads name those fields differently, add a mapping so the tags resolve. On the agent’s Memory step, under Entity tags, add a mapping for the signal type, then add each tag key with the paths to read it from. Grepr tries the paths in order and uses the first that resolves.

Consistent tag values matter more than complete ones. A service tagged checkout in some memories and checkout-svc in others splits its history in two, and a timeline search finds only half. Grepr gives an agent the tag values already in use in your organization when it searches, so an agent that searches before recording reuses existing values rather than inventing new ones.

Who can read and write memories

• Reads are organization-wide. Any agent can search any other agent’s memories in your organization. Operational history is only useful shared, so an agent investigating a service finds what another agent concluded about the same service. Permission is uniform across the modes, but coverage is not: a semantic search still examines one agent at a time. See How an agent searches its memory.
• Writes are owner-only. A memory can be written or corrected only by the agent that ran the investigation, so one agent cannot overwrite another’s conclusions.

When an agent finds that a past memory describes what it is now seeing, it links its investigation to that memory, which raises the recurrence count rather than creating a near-duplicate record. Each contributing investigation counts once.

Memories outlive the agent that wrote them. Deleting an agent leaves its memories searchable by your other agents.

Search memories from the CLI

The Grepr CLI searches the same memories an agent does, which is how you read what your agents have concluded.

# Find investigations mentioning a literal string
grepr investigation:memory:search --mode text --query "connection refused" --limit 5
 
# Find investigations whose conclusions are similar in meaning
grepr investigation:memory:search --mode semantic --agent-id <agent-id> --query "intermittent ingestion failures"
 
# See what has been happening to one service lately
grepr investigation:memory:search --mode timeline --entity-tag entity:service=checkout

A semantic search needs an agent id, because a query can only be compared inside the index that agent embeds into. Text and timeline searches cover every agent in your organization by default. Timeline searches need at least one entity tag.

The CLI is how you read what your agents have concluded outside of an investigation. To learn more about the CLI, see The Grepr CLI.