How can agent memory be scoped to a user or session?

Agent memory can be scoped by attaching each memory to the identity or execution boundary it belongs to, such as a specific user, session, project, or tenant.

This ensures the agent retrieves only memories that are valid for the current context.

User-scoped memory

User-scoped memory belongs to one specific user and may remain available across multiple sessions.

Examples include:

• preferred language
• preferred output format
• recurring instructions
• stable preferences
• user-specific project facts

A memory record may include a field such as:

user_id = user_123

When the agent retrieves memory for that user, it filters by the same user identifier.

This prevents another user's memories from appearing in the result.

Session-scoped memory

Session-scoped memory belongs only to a particular conversation or execution session.

Examples include:

• temporary goals
• current discussion context
• one-time constraints
• recent choices
• intermediate conclusions

A session-scoped memory may include:

session_id = session_456

When the session ends, these memories may expire or become inaccessible to future sessions.

Example

Suppose a user says:

“For this conversation, use Java.”

That may be session-scoped.

Later the same user starts a new conversation. The agent should not automatically assume Java is still preferred.

But if the user says:

“I always prefer Python examples.”

that may be appropriate as user-scoped memory because it is intended to persist across sessions.

Scope should be stored explicitly

A memory record can include metadata such as:

• user_id
• session_id
• project_id
• tenant_id
• memory type
• created time
• expiration time

For example:

user_id: user_123 session_id: session_456 project_id: project_alpha

This makes filtering predictable.

Retrieval should filter by scope first

Before ranking memories by relevance, the system should restrict the search to memories the current agent run is allowed to use.

A common retrieval flow is:

1. Identify the current user.
2. Identify the current session.
3. Identify project or tenant if relevant.
4. Filter memories by those identifiers.
5. Rank only the remaining memories for relevance.

This is safer than searching the entire memory store first and trying to remove unrelated results afterward.

User-scoped and session-scoped memory can coexist

An agent may use both at the same time.

For example:

User memory: Prefers concise responses.

Session memory: Currently comparing cloud providers for Project Alpha.

The agent can combine both when responding.

The user preference persists across sessions, while the current comparison belongs only to this session.

Project or tenant scope may also matter

User and session scope are not always enough.

A user may work across several projects.

For example:

Project A: Python backend.

Project B: TypeScript backend.

A project-specific memory should not automatically apply to every project owned by the same user.

Similarly, in multi-tenant systems, every memory should usually be associated with the correct tenant boundary.

Session scope is useful for temporary information

Session memory is a good place for information that should not become a permanent profile.

Examples include:

• temporary task preferences
• one-time assumptions
• intermediate findings
• a temporary working hypothesis

This avoids polluting long-term user memory.

User scope is useful for durable personalization

User-scoped memory is appropriate when information is likely to remain useful across sessions.

Examples include:

• preferred response style
• preferred programming language
• recurring accessibility needs
• stable workflow preferences

These memories should still be updateable if the user's preference changes.

Expiration can strengthen scope

Session memories may have explicit expiration.

For example:

session_id: session_456 expires_at: session end

Temporary user or project memories can also have time limits.

This prevents old scoped memory from remaining active indefinitely.

Scope is also a security boundary

Memory scoping is not only about relevance.

It also helps prevent information leakage.

An agent should never retrieve another user's or tenant's memory simply because it is semantically similar to the current request.

Access controls and retrieval filters should enforce the boundary.

A useful rule

Think of memory scope as answering:

Who does this memory belong to, and for how long is it valid?

Typical answers are:

• this user across sessions
• this session only
• this project
• this tenant
• this workflow run

The narrower the memory's validity, the narrower its scope should be.

In short

Agent memory should be scoped by attaching explicit identifiers such as user ID, session ID, project ID, or tenant ID and filtering retrieval using those boundaries.

User-scoped memory supports durable personalization across sessions, while session-scoped memory keeps temporary context isolated to the current interaction.