Memory service¶

The memory service provides persistent memory management for AI agents. It stores and retrieves conversational context across sessions, manages memory lifecycle (TTL, event counts), and uses PostgreSQL with pgvector for vector-based semantic search over memories. The service includes a bundled embedding service that runs CPU-only ONNX inference for text embedding and reranking, with the model weights baked into the container image.

Enabling the service¶

To enable the Memory Service, edit the values.yaml file:

memoryservice:
  enabled: true

Database configuration¶

The Memory Service uses PostgreSQL with the pgvector and pg_trgm extensions. It connects to the shared DataRobot PostgreSQL instance by default. If you use an external PostgreSQL instance, ensure the pgvector and pg_trgm extensions are available—see the external PostgreSQL guides for cloud-specific setup instructions.

LLM configuration¶

Memory extraction (the mem0-compatible API) uses an LLM that each memory space selects at creation time via the llmModelName field. By default, LLM requests are routed through the DataRobot LLM Gateway, so the Generative AI service must be enabled and configured with provider credentials. Model names are validated against the LLM Gateway catalog and a built-in allowlist; see LLM availability for the models offered per provider.

A memory space can instead point at a custom OpenAI-compatible endpoint via the llmBaseUrl field. Custom endpoints are restricted to a single allowed host, configured with the allowedLlmUrlHost value (exposed to the service as the ALLOWED_LLM_URL_HOST environment variable):

memoryservice:
  allowedLlmUrlHost: "llm.example.com"

When allowedLlmUrlHost is unset, the allowed host falls back to global.domain. If neither is set, custom llmBaseUrl values are rejected and memory spaces can only use the LLM Gateway.

Model provisioning¶

The models the memory service uses ship inside its container image, so pods start without downloading anything—no init container runs and no CDN access is required.

The image includes the following models:

Install in offline clusters¶

No additional steps are required. The models arrive inside the container image through your registry, so the memory service requires neither CDN egress nor pre-provisioned model weights in blob storage, and it no longer depends on the Generative AI service static files migration.

To restore the legacy download flow for the embedding models in an offline cluster, set:

global:
  airgap:
    enabled: true

memoryservice:
  embeddingService:
    modelsBakedIn: false

With modelsBakedIn: false, an init container downloads the embedding models at every pod start: from blob storage when global.airgap.enabled is true—complete the Generative AI service static files migration first so the model weights are available there—or from the DataRobot GenAI CDN (HTTPS egress on port 443) when the cluster has internet access. The spaCy model is part of the application itself and is always included in the image.