Memory Configuration

Overview

Digital Employee Core supports user-scoped memory so an agent can remember facts and preferences across multiple calls. Memory is opt-in:

  • Enable a memory provider in agent_config.

  • Pass a stable memory_user_id on every run() / arun() call.

Key Concepts

What is memory_user_id?

memory_user_id is the user identifier used to scope memory.

  • Same memory_user_id + same agent => the agent can recall previously stored facts.

  • Different memory_user_id + same agent => isolated memory (no cross-user leakage).

  • Same memory_user_id + different agent => isolated memory (each agent maintains its own memory scope).

Memory Provider

Memory is enabled by setting AgentConfigKeys.MEMORY to a provider (e.g. MemoryProvider.MEM0). Currently we utilize GL SDK Memoryarrow-up-right via AIP Memoryarrow-up-right.

Minimal Example

1) Create a memory-enabled Digital Employee

2) Deploy, then call with a stable memory_user_id

circle-info

Note: After storing a memory, there may be a slight delay from the provider before it becomes available for retrieval, so you may need to wait a moment (manually or via Python's sleep() ) before querying for recently stored information.

3) Different user, different memory

Local Usage

To use MemoryProvider.MEM0 locally, you must provide MEM0_API_KEY in your environment variables.

If you load environment variables via .env, ensure your entrypoint calls load_dotenv().

Then, run the digital employee with local=True to run it locally.

Notes / Best Practices

  • memory_user_id is required when memory is enabled; the agent cannot store or recall memories without it.

  • Use stable identifiers (e.g., internal user ID) and do not use PII (like emails) unless necessary.

  • Write clear instructions in the job prompt indicating what to remember (preferences, long-term facts) vs what not to (secrets).

Last updated