Memory and Key Events

The memory panel manages two kinds of memory: conversation context (short-term memory, full context) and key events (long-term, cross-session business memory).

Short-term memory

Short-term memory determines whether the agent "remembers the last few turns":

• Controlled by the memory panel's "Enable the last N rounds of chat history" setting: you can set how many recent rounds to keep (one question and one answer = one round), defaulting to 30 rounds.
• When turned off, cross-turn history is no longer given to the model, and the agent "forgets the previous turn." When a customer reports "it doesn't remember the last turn," check here first.
• In debug / preview mode, memory is always empty (a clean context each time), which is normal.

Full context

Within the short-term memory window, older rounds keep only the plain text of "what was asked, what was answered" by default — which tool was called at the time, what parameters were passed, and what result came back are not in the history. Full context is a layer on top of short-term memory: it makes the most recent rounds additionally carry the complete tool-call trace (which tool was called, the input parameters, and the returned result), so the model can accurately remember exactly what it just did.

• Controlled by the memory panel's full-context setting (shown as "last N rounds"), defaulting to 1 round, with a range of 0–5; 0 means off (earlier rounds keep only the Q&A text).
• It and the short-term memory round count are two independent settings that do not affect each other.
• It is counted by round (one question and one answer = one round), not by number of replies: if a single round has multiple replies, it is not split in the middle — either the whole round carries the tool trace or none of it does.

When to increase it: when the model "doesn't seem to remember which tool it just called or what parameters it passed," first check whether this value is set to 0 or too small, then increase it. Conversely, the more rounds carried, the faster token usage grows — bigger is not better; 1–2 rounds is usually enough.

Key events

Key events are LoopAgent's cross-session, user-level long-term memory (equivalent to a ticket). During a conversation the model actively creates / updates / queries events for the user (such as "refund processing" or "account anomaly"); when the same user comes back in a different session, they can still be seen and followed up.

• Events are attached to the user identity and are visible and editable across all of that user's sessions.
• Each turn's system prompt automatically carries up to 5 unclosed events for that user; the model actively queries when it needs more.

Difference from ordinary Agent / FlowAgent: all three agent types share the same key-event configuration (switch + event types), but the way they write differs — LoopAgent writes synchronously during the conversation (creating / modifying events directly within the turn); ordinary Agent / FlowAgent extract asynchronously in the background after the conversation. For the general concepts of key events, event-type configuration, and use cases, see Key Events.

Prerequisites: both conditions must be met

For the key-event tools to appear, both of these must be satisfied:

1. The key-events master switch in memory is on;
2. At least one type is configured in the event-type categories.

Switch on but not a single event type created → the key-event tools do not appear, and no historical events are injected. This is not a malfunction.

Common questions

• "Creating an event returns a parameter error": most likely the event type the model used is not in your configured type dictionary. Check that the type the model passed matches the type names on the settings page word for word (case- and space-sensitive).
• "Created but can't be found on a return visit": first suspect that the user identity was not resolved (anonymous / channel session). In that case events fall back to the session, and cross-session retrieval may miss them.