Memory browser

What this page is for

The Memory Browser is the curation surface for Exolvra’s memory system. Use it to inspect what agents have saved, fix bad entries, delete stale ones, and understand how memory is shaping agent behavior.

See Memory & knowledge for the conceptual model — the short version is that memories are short notes scoped to system, project, or agent, and they’re injected into agent context on every turn based on semantic relevance.

Layout

The browser has three main controls above the results:

• Scope filter — all, system, project, or agent-scoped
• Agent filter — narrow to memories saved by a specific agent
• Search box — filters by content (hybrid keyword + semantic)

Below those, a results list shows each memory with:

• Content — the actual text of the memory
• Scope — a badge indicating system, project, or agent
• Author — which agent saved it
• Project — if project-scoped
• Created — timestamp
• Relevance — a score (when you’re searching; highest first)

Click any memory to open a detail view with edit and delete options.

Common tasks

Search across all memories

Type a query into the search box. Results come back ranked by relevance — semantic matching finds conceptually similar memories even when the wording differs. Try queries like:

• “user preferences about report format”
• “staging environment URL”
• “things I got wrong”
• “billing module refactor”

Filter to one agent’s memory

Pick the agent from the dropdown. Now you see only memories that agent has saved — useful for auditing what a specific agent remembers and whether its self-knowledge is reasonable.

Filter by scope

The scope filter restricts to one of:

• System — visible to every agent in the instance. Usually small and stable.
• Project — visible to agents working inside one project. The bulk of memory lives here.
• Agent — the agent’s private notes, visible to that agent across every project.

If you’re investigating why an agent is behaving oddly in one project, filter by that project scope to see what’s influencing it.

Edit a memory

Click the memory, then Edit. Fix the wording, correct a factual error, or adjust the scope. Save. The new version replaces the old immediately — there’s no version history for memories (unlike the data store).

Delete a memory

From the memory detail view, click Delete. Confirm. The memory is gone permanently and will no longer surface in agent retrieval.

Promote a memory from agent scope to project scope

If you notice an agent has saved something in agent scope that would benefit the whole project team, edit the memory and change the scope dropdown to project. Save. Now every agent in that project sees it on retrieval.

Disable memory for an agent

If you want an agent to run stateless, with no memory influence, open the agent’s edit page and uncheck Use memory. That agent won’t search memory on any turn. Its own memories stay in the store but aren’t retrieved — you can re-enable later.

When to clean up

Memory drift is a real thing. Over time you’ll accumulate:

• Stale facts — the staging URL changed but the old memory still says the old URL
• Duplicates — the same observation saved two or three times in slightly different wording
• Bad observations — an agent misunderstood something and saved an incorrect note
• Irrelevant noise — trivial stuff the agent saved on a bad day

Periodic curation keeps the signal-to-noise high. Once a quarter for an actively-used instance is usually enough.

Common pitfalls

Treating memory as a database. Memory is for fuzzy, natural-language observations. If you want structured records with fields, use the data store instead.

Not curating. Agents save memories aggressively in some configurations. Without cleanup, the memory store bloats and relevance ranking gets noisier over time. Set a calendar reminder to review memory once a month for any project you care about.

Confusing memory with document collections. Memory is agent-written notes. Document collections are human-uploaded files for RAG grounding. They’re different systems for different jobs.

Where to go next

• Memory & knowledge — the full conceptual model
• Documents — the RAG-grounded counterpart
• Agents — per-agent memory toggles