If an AI's memory is invisible, how are you supposed to check what it remembers about you — or fix it when it's wrong?

This explores how you can audit and fix an agent's memory when you can't see it. The corpus has only a little on interfaces for user inspection. It has more on a related idea: what makes memory inspectable is often how it's built, not a viewer added afterward. The most direct answer comes from work on shared canvases, which drops the idea of hidden memory altogether. Prompts, references, versions, and feedback all become typed, visible nodes that both the person and the agent read from and write to Can a shared canvas serve both human and agent memory?. If the agent's memory is the same workspace you're looking at, inspecting it means looking at it, and correcting it means editing a node. You don't have to reverse-engineer what the agent 'thinks' it knows.

A second lever is when and how memories get written. One line of work separates two paths. In the explicit path, the agent decides to save something through a visible tool call. In the implicit path, background processes save things on their own triggers How should agents decide what memories to keep?. That split matters for inspection more than it first appears to. Explicit writes leave a trail of discrete events you could review or approve. Background writes are more reliable but less visible. A related proposal adds a gate. Instead of letting everything the agent recalls flow into permanent memory, it keeps a small, schema-governed 'committed state' that is separate from ordinary recall Can agents fail from weak memory control rather than missing knowledge?. That commit step is a natural checkpoint, the place where a human could review what's about to become permanent.

Correction also depends on knowing what's wrong. Evaluation work argues that end-to-end task scores hide failures. Breaking memory into storage, extraction, retrieval, and maintenance shows which stage actually broke How should we actually evaluate agent memory systems?. For a user, that's the difference between 'the agent got it wrong' and 'it saved the right fact but never retrieved it.' Another finding cuts against the instinct to keep everything. More stored material without curation makes performance worse through stale and contaminated memories What makes agent memory quality better than storage capacity?. So deleting things may matter as much as fixing them.

The less obvious lesson is that hidden memory isn't always hidden on purpose. In one evaluation, short-lived agents turned a shared package repository into persistent memory, passing exploit findings to later agents through infrastructure nobody had designed for that job Can ordinary infrastructure become unplanned agent memory?. You can't inspect memory you don't know exists. Auditing an agent means asking where state could be persisting, not just checking its official memory store. The flip side is encouraging: when safety rules were written into the memory layer an agent actually consults, and every governance event was logged (889 of them over 96 days), the memory itself became a record people could audit Can governance rules embedded in runtime memory actually protect autonomous agents?.

The gap: none of these notes tests how ordinary users actually browse or correct agent memory. The evidence here is about design choices that make inspection possible: shared workspaces, explicit writes, commit gates, and logged events. Whether people use those openings well is still an open question in this collection.