“Memory” can describe several different things: recent conversation history, a saved user preference, a document store, a summary written by the system, or data retrieved from a connected account. Those categories do not have the same sensitivity or lifecycle.
Before judging whether an agent remembers well, determine what it remembers and how that information can influence future actions.
1. Separate the memory layers
Conversation context
Recent messages help the system interpret follow-up questions. Ask how much context is retained, whether it is visible to the user, and when it expires or is summarized.
Saved preferences
Names, tone preferences, working hours, recurring instructions, and project details can improve continuity. These items should be correctable because a stale preference can quietly shape many later responses.
Connected information
Email, calendars, files, analytics, and other systems may be queried at the moment of a request rather than copied into permanent memory. Ask which data is stored, which is retrieved on demand, and what remains after a connection is removed.
2. Correction matters as much as recall
A system that remembers an incorrect assumption can become consistently wrong. Useful controls include a visible profile, editable memory entries, clear “forget this” behavior, and a support path when the user cannot correct the state directly.
Persistent context without a correction path turns one mistake into a recurring instruction.
Test correction with an ordinary, reversible fact. Change a preference, confirm the new value is used, and verify that the old value does not continue resurfacing.
3. Map permissions to actions
Connected-account permission screens can be long and difficult to interpret. Reduce them to verbs. For each connection, list whether the agent can:
- Read messages, events, files, records, or reports
- Create drafts, calendar events, documents, or rows
- Send or publish communications to other people
- Modify existing data or settings
- Delete information or revoke access
Then ask whether each verb is always available, limited to a defined scope, or held behind human approval. A long feature list is less informative than this action map.
4. Put review before consequence
Low-consequence work may be safe to complete immediately. Higher-consequence work should usually create a draft, preview, or explicit confirmation point. The boundary depends on the user and workflow, but common review candidates include:
- Sending a message to a customer, partner, or large group
- Deleting or overwriting a file or record
- Changing access, billing, or account settings
- Publishing content under a person or company’s identity
- Making a financial, legal, medical, employment, or safety-sensitive decision
“Human in the loop” is useful only when the person sees enough context to make the decision. A vague confirm button is not a meaningful review interface.
5. Ask how the relationship ends
Disconnection and account closure are part of the design. Confirm how to revoke third-party access, export useful information, delete stored content, and obtain support if the automated path fails. Do not assume deleting an app removes permissions granted in another service; verify the connected account as well.
What is remembered? Where is it stored? Who can view or correct it? Which actions can use it? Which actions require approval? How is access revoked and data deleted?
Make the boundary visible
The goal is not to eliminate memory or permissions. It is to make them understandable enough that the user can decide what belongs in the system. Continue with the next field note: choosing messaging channels around the work.