Overview
Memory on the MongoDB Atlas Agent Engine is configured at the project level. All agents in a project share the same memory service, store, and settings. You can enable or disable memory for individual agents in their agent.yaml file.
To configure memory, edit the memory: block in your project-config.yaml file, upload the required API keys as project secrets, and deploy your agent. After the initial deployment, you can update memory settings without redeploying.
To learn more about memory, including how it's stored and extracted during conversations, see the Agent Memory guide.
Prerequisites
Ensure that you have the following prerequisites before you begin:
An
agent.yamlfile and a deployed agent. To get started, see Get Started with the Atlas Agent Engine.The
agentengineCLI installed and authenticated. To learn more, see Install and Authenticate.An Atlas Flex (minimum requirement),
M10,M20, or higher tier cluster (recommended) to store your memory data. To provision a cluster, see Set Up Atlas Resources.- We recommend deploying a dedicated
M10or higher tier cluster to accommodate your memory data and index count as they grow. Atlas Flex is the lowest cluster tier that can support the memory service.
Note
If the linked Atlas cluster can't create the Search and Vector Search indexes that memory requires, the Atlas Agent Engine stops deployment at the Memory: waiting stage and might time out with an Error: context deadline exceeded error message.
Enable Memory
To enable memory for your agent, set features.memory: true in your agent.yaml file, then add the following variables to your .env file before starting the local environment:
VOYAGE_API_KEY: Required for generating memory embeddings.MONGOMEM_DB_NAME: Optional. The MongoDB database name the memory server writes to. Defaults tomdb_memory_<project-id>.
Memory requires the two-level project structure described in the following section. If you use the agentengine create command to scaffold your project, the CLI generates this structure for you.
Note
TypeScript agents enable memory by using the same method. A TypeScript agent accesses the app.memory client only while it handles a platform request. To read or write memory outside of that context, use the Memory client from the @mongodb-js/agent-engine-sdk-memory package, which connects to the memory server directly over HTTP.
Project Structure for Memory
Your project root has a project-config.yaml file that stores the memory configuration. Each workspace, which contains an agent.yaml file, is a subfolder of the project root. The following example shows the expected project structure for memory configuration:
my-project/ ├── project-config.yaml └── my-workspace/ └── agent.yaml
The project-config.yaml file has a memory: section that configures the memory server for your project. The following example shows the available memory configuration options and their default options:
memory: # Memory-server log level. One of: debug | info | warning | error | # critical. log_level: info # Voyage AI embeddings. # The Voyage API key is NOT set here — upload it as a project # secret with: # agentengine secret set VOYAGE_API_KEY <value> voyage: model: "voyage-4-large" dimension: 1024 # Short-term memory write-path behavior. short_term: # Embed each turn's content when it is written (only when the # caller supplies no embedding), so it is searchable by # relevance immediately instead of waiting for background # embedding. Adds embedding latency to the write. embed_on_write: false # LLM used for background extraction. # The API key is NOT set here — upload it as a project secret. If # your agent already uses a supported LLM connection, upload that # same key under the shared LLM_API_KEY name so the agent and # extraction reuse one secret: # agentengine secret set LLM_API_KEY <value> # Otherwise, upload a provider-named key instead, for example: # agentengine secret set OPENAI_API_KEY <value> extraction_llm: provider: openai # one of: openai | anthropic | gemini | cerebras model: null # overrides the provider's default model base_url: null # optional: route requests through a gateway # or proxy instead of the provider's default # endpoint. Required only for gateway # connections; omit to call the provider # directly. api_key_secret: null # optional: the name of the project secret # that holds the extraction LLM's API key. # One of: LLM_API_KEY, OPENAI_API_KEY, # ANTHROPIC_API_KEY, GEMINI_API_KEY, or # CEREBRAS_API_KEY. If omitted, extraction # checks provider-named keys before # LLM_API_KEY. auth_header: null # optional: the header the gateway expects for # the API key. One of: authorization (Bearer) # or api-key. Omit for native provider # authentication. background_extraction: snapshot: max_messages: 20 stale_minutes: 3 embed_stm_before_promotion: true topic_shift_enabled: false topic_shift_threshold: 0.35 delete_promoted: false ttl_days: 30 # Extraction pipeline. Add memory types to the 'enabled' list to # turn extraction on, for example: # enabled: # - semantic # - episodic # Valid types: semantic, episodic, taxonomic, entity, preferences, # procedural. # NOTE: Removing the 'enabled' line entirely re-enables ALL types. # Keep it as [] to extract nothing. extraction: enabled: []
To upload and sync memory configuration for a deployed project, see Configure Memory.
Migrate Project Structure
If your project uses a flat structure with agent.yaml at the project root, migrate to the two-level structure before enabling memory. The flat structure is deprecated.
To migrate your flat structure, perform the following steps:
Create a project-config.yaml file at the project root.
The following sample file project-config.yaml shows the memory: section configuration:
memory: log_level: info voyage: model: "voyage-4-large" dimension: 1024 short_term: embed_on_write: false extraction_llm: provider: openai model: null base_url: null api_key_secret: null
Configure Memory
Use the agentengine memory commands to upload and sync your project's memory configuration for deployed projects. Memory configuration is project-scoped: one configuration document applies to all agents in the project.
To configure memory for local development, see Enable Memory.
Configuration Command Syntax
The agentengine memory configure command reads a project-config.yaml file from your agent directory, extracts the memory: section, and uploads it to the Atlas Agent Engine. The command confirms the target project before uploading.
Important
A future release will remove support for the agentengine memory configure command. Instead, the platform will support memory management through the UI.
The following example shows the command syntax to upload memory configuration:
agentengine memory configure <path> [--project-id <id> --org-id <id> --base-url <url>]
Alternatively, you can use the agentic memory configure command and pass only the --context flag, as shown in the following example:
agentengine memory configure <path> [--context <name>]
Warning
If the project-config.yaml file does not contain a memory: key, the command returns an error. A missing memory: key does not remove an existing configuration.
The following table describes the available flags:
Flag | Description |
|---|---|
| The name of a saved context that identifies the target platform base URL, organization, and project. To view your saved contexts, run |
| Project ID. If omitted, the command uses the
project from your local authentication state. If you set
this flag, you must also set the |
| Organization ID. Required if you use the |
| Platform base URL. Required if you use the |
| Skip the confirmation prompt. Use this flag in Continuous Integration (CI) environments. |
Note
Memory configuration is not a secret store. Store only non-secret settings in the project-config.yaml file. Use the agentengine secret set command for API keys, connection strings, and other credentials. The Atlas Agent Engine rejects uploads that contain values matching common secret patterns.
Initial Memory Configuration
Before your first deployment with memory enabled, perform the following steps:
Edit the memory: block in your project-config.yaml file.
Open project-config.yaml at the project root and configure the memory settings. To view the available options, see Project Structure for Memory.
Upload the required secrets.
Run the following commands to upload the secrets, and include the --project-scope flag to target project-scoped secrets:
agentengine secret set VOYAGE_API_KEY --project-scope agentengine secret set LLM_API_KEY --project-scope
If you scaffolded your project with the agentic create --llm <provider> --memory command and selected a supported LLM provider, the CLI already added extraction_llm.api_key_secret: LLM_API_KEY to your project-config.yaml file. This is the same secret name your agent's .env file uses, so uploading it once supplies the key to both the agent and memory extraction.
Note
You can still use provider-named keys, such as OPENAI_API_KEY or ANTHROPIC_API_KEY. Without an explicit api_key_secret value, extraction checks provider-named keys before LLM_API_KEY. Set the api_key_secret field explicitly if memory requires a separate credential from your agent, or if you have keys for multiple providers and want to select one.
If you set api_key_secret to a value other than LLM_API_KEY, replace LLM_API_KEY in the preceding command with that name instead.
Update Memory Configuration
Memory configuration changes don't require redeploying the agent. To apply updated memory settings to a running deployment, perform the following steps:
Edit the memory: block in your project-config.yaml file with your new memory settings.
Open project-config.yaml at the project root and configure the memory settings. To view the available options, see Project Structure for Memory.
Apply the configuration.
agentengine memory apply
The agentengine memory apply command restarts the memory server so it registers the new configuration. The platform delivers configuration changes asynchronously and the changes take effect when the pod restarts or when the updated configuration is applied on startup. If the stored configuration is not yet synced, the agentengine deploy command syncs the configuration as part of the next deploy process.
Declare Custom Memory Types
Custom memory types store domain-specific records that don't correspond to the four built-in memory types. To declare and use custom memory types, perform the following steps:
Declare your custom types.
Add a custom_memory_types: block to the memory: section of your project-config.yaml file. The following example creates a custom customer_profile type:
memory: custom_memory_types: # Custom memory types (max 5) - name: customer_profile collection: profiles tags: - name: location - name: tier - name: profile.location # One level of nested tag keys
Each custom memory type has the following fields:
name: (Required) The type name. The value must start with a lowercase letter and contain only lowercase letters, numbers, and underscores. It cannot use any of the built-in type names or exceed 64 characters in length.collection: (Required) The collection in the project's memory database that stores the type's records.tags: (Optional) Filterable tag keys, up to ten per type. A tag key can use dot notation to nest up to one level, such asprofile.location. Tag values must be non-empty strings, numbers, or booleans.
Provision the new types.
Run the following commands to upload the updated configuration and apply it to the memory server, which provisions each new type:
agentengine memory configure agentengine memory apply
Note
After you upload a configuration that declares a custom memory type, you cannot edit or remove the type's collection or tag set. To change a type, declare a new type name instead.
Read and write custom memory records.
In your application, use the save() and retrieve() methods to write and read custom memory records:
memory.save( memory_type="customer_profile", content="Prefers direct vendor onboarding contact.", tags={"tier": "gold"}, ) hits = memory.retrieve( memory_type="customer_profile", query="How should we onboard this customer?", tags={"tier": "gold"}, top_k=5, )
Access Memory From Your Agent
When you deploy an agent with memory enabled, the platform provides the app.memory client on the application object. Use this client to read and write memory from your agent. The platform resolves the current user and session from the runtime context, so you don't need to pass user_id or session_id arguments explicitly to app.memory.
To access memory from an agent-engine-sdk-langgraph agent, perform the following steps. Every Atlas Agent Engine agent template uses the agent-engine-sdk-langgraph package, so these steps apply regardless of your agent's use case.
Access the app.memory client.
In your agent code, retrieve the app.memory client and use it to read and write memory. The following example shows how to access this client:
from agent_engine_sdk_langgraph import App app = App(app_name="support-agent") def build_graph(): # Your LangGraph state machine. ... # Later, in a request handler for a conversation turn: memory = app.memory
Retrieve context that is relevant to the user's message.
Use the app.memory.build_context() method to retrieve memory that is relevant to a message and format it as context, as shown in the following example:
def handle_turn(user_message: str) -> str: ctx = memory.build_context( query=user_message, max_tokens=2000, ) prompt = f"{ctx.formatted_context}\n\nUser: {user_message}" return prompt
Note
For a deployed agent, the platform records conversation turns automatically. You do not need to call record_turn() to save conversation turns.
Next Steps
After enabling memory for your agent, you can test the agent locally and deploy it. To learn how to test your agent, see Test the Agent. To learn how to deploy your agent, see Deploy.
To use memory from an application that runs outside the Atlas Agent Engine, see the Use the Standalone Memory Service App guide.