What to remember

If the answer is no, do not write it to GUMem. A memory system gets its value from selection, not from saving everything.

Good Memory candidates

Type	Example	Why it belongs in GUMem
Stable preference	The user prefers light-colored running shoes, or uses Berlin for Europe team scheduling.	It can affect later recommendations, scheduling, or decisions.
Explicit fact	The user will travel to Shanghai next Wednesday.	Later tasks may need to cite or remind the user.
Long-lived constraint	Budget must stay below 800, or meetings cannot happen on Fridays.	It reduces repeated questions and bad suggestions.
In-progress plan	The user is arranging a quarterly check-in for the Europe team.	Multi-turn tasks need continuity.
Auditable action	The user confirmed, rejected, saved, skipped, or completed a tool action.	Later decisions may need an explanation.
Behavior pattern	The user repeatedly filters the same price range or chooses the same city.	Behavior can reveal intent more reliably than explicit text.

How to decide whether something should become Facts

GUMem first turns written Message input into Facts, then compresses related Facts into Summary. When deciding whether to write something, first ask whether it deserves to become Facts.

Good Facts usually satisfy these conditions:

• They have a clear source, traceable to a user message, assistant reply, tool result, or behavior event.
• They can affect future answers, recommendations, tool calls, risk decisions, or audit explanations.
• They express a fact, preference, plan, constraint, identity, role, time, place, object, or explicit behavior.
• Their granularity is specific enough for the Agent to use directly.

One Message may contain multiple independent Facts. For example, “Use Berlin for Europe, Toronto for Americas, and avoid Friday meetings” contains at least two city preferences and one meeting constraint. Tightly coupled information should not be split; “Europe defaults to Berlin” should remain one complete fact.

Summary is better for a group of Facts that together express long-term memory. For example, repeated searches, filters, and saves pointing to the same preference can become one Summary that is easier to recall.

Do not write by default

Type	Example	Recommended handling
Temporary UI state	Expanded panels, temporary sort order, one-off hover state.	Keep it in frontend or current request state.
Irrelevant clickstream	Scrolling, accidental clicks, unrelated dwell time.	Do not write unless the product explicitly needs analysis.
Sensitive information	ID numbers, payment data, health details, secrets.	Do not write by default; define redaction, access control, and lifetime first.
Unverified inference	"The user may be anxious" or "the user probably has high income."	Do not write as factual Memory; mark it as low-confidence if you must keep it.
One-time intermediate result	Temporary tool token or pagination cursor.	Store it in workflow state instead.
Model hallucination	Content invented by the Agent and not confirmed by the user.	Do not write unless the user later confirms it.

Pre-write checklist

Before writing Message input or User Actions, check:

• Will this information affect future answers, recommendations, tool calls, or risk decisions?
• Which user_id and Session does it belong to?
• Was it explicitly stated by the user, produced by behavior, or inferred by the Agent?
• If the user asks to delete or correct it, can you find the source?
• Does it contain sensitive data that needs redaction, filtering, or a shorter lifetime?

Choose a write path

Context source	Use
Content explicitly said by the user or assistant in conversation	Use Add Memory to write Session messages.
Searches, filters, clicks, saves, skips, tool calls, or business events	Write behavior Message input with User Actions.
Data that needs filtering, cleanup, or added rules before recall	Use WebHooks in the processing pipeline.
Information only needed in the current request	Do not write it to GUMem; put it directly in the current Agent context.

Next step

• Read Add Memory to write messages and behavior events.
• Read Query Memory to retrieve written Memory.
• Read How Memory Forms to understand how raw input becomes reusable Memory.