Agentic memory service¶

The agentic memory surface in DataRobot exposes two different APIs that address different use cases. Choose the path that matches your build, then follow the documentation for that path. You do not need to merge the two in a single application.

If you need to persist and retrieve chat-style history (sessions) through DataRobot's REST API and Python API client with a DataRobot model (accessed via datarobot.models.memory.Session  or datarobot.models.memory.MemorySpace), use the chat history API described in the Chat history API section. Read the REST API and Python API client reference documentation for complete details.

If you are working with long-term, mem0-style memory (including migrating from the open-source mem0 stack), or you want examples and request shapes that match the mem0 product, use the mem0 API. For that interface, the canonical resource is the mem0 documentation.

Quickstart¶

Review a quickstart workflow below.

Prerequisites¶

• Python 3.9+
• A DataRobot account, an API key, and the endpoint URL (e.g. https://app.datarobot.com/api/v2)
• pip install "datarobot>=3.17" "mem0ai>=2.0"

Set credentials once, either via environment (DATAROBOT_API_TOKEN, DATAROBOT_ENDPOINT) or ~/.config/datarobot/drconfig.yaml. The snippets below pass them explicitly.

Connect¶

import datarobot as dr

dr.Client(token="<YOUR_DATAROBOT_API_TOKEN>", endpoint="https://app.datarobot.com/api/v2")

Create a memory space¶

A memory space is the isolation boundary for one application or one end user.

from datarobot.models.memory import MemorySpace

space = MemorySpace.create(
    description="Acme support assistant",
    llm_model_name="vertex_ai/claude-sonnet-4-6",  # used for mem0 fact extraction
)
print(space.id)

llm_model_name selects the LLM used for mem0 fact extraction. It is validated against the models available through the DataRobot LLM Gateway; an unknown name is rejected with a 422 response that lists the allowed models. See LLM availability for the models offered per provider. Non-reasoning models are recommended, as reasoning models are significantly slower for fact extraction without producing better results. Alternatively, llm_base_url points the memory space at a custom OpenAI-compatible endpoint instead of the LLM Gateway; its host must match the allowlist configured by your administrator.

Create a session¶

A session is one conversation. participants is a list of MongoDB-ObjectId strings - typically your end user.

from datarobot.models.memory import Session

session = Session.create(
    memory_space_id=space.id,
    participants=["67500a000000000000000001"],
    description="Triage chat #42",
)
print(session.id)

The server attaches a default soft-delete lifecycle strategy (180 days) if you do not supply one.

Post messages¶

Each message is an event. body is free-form JSON; emitter identifies who sent it.

event = session.post_event(
    body={"content": "Hello, my deployment is failing"},
    emitter={"type": "user", "id": "67500a000000000000000001"},
    event_type="message",
)
print(event.sequence_id)  # 0

Batched append (up to 200 events, single transaction):

session.post_events([
    {
        "body": {"content": "Looking at it now."},
        "emitter": {"type": "agent", "id": "67500a000000000000000002"},
        "event_type": "message",
    },
    {
        "body": {"content": "Found the issue - rolling back."},
        "emitter": {"type": "agent", "id": "67500a000000000000000002"},
        "event_type": "message",
    },
])

Read and edit events¶

# Newest 20 events:
recent = session.events(last_n=20)
for e in recent:
    print(e.sequence_id, e.emitter_type, e.body)

# Edit message #1:
session.update_event(
    sequence_id=1,
    body={"content": "Looking at it now (ETA 5min)."},
)

update_event accepts an optional created_at for optimistic concurrency: if the event has changed since that timestamp, the server rejects the update and the caller must reload and retry.

Memory extraction via stock mem0 client¶

The service exposes a mem0-compatible sub-route per memory space. Point a stock mem0ai.MemoryClient at it and the standard mem0 client works unchanged - add(), get(), search(), get_all(), delete().

from mem0 import MemoryClient

endpoint = f"https://app.datarobot.com/api/v2/memory/{space.id}"
memory = MemoryClient(host=endpoint, api_key="<YOUR_DATAROBOT_API_TOKEN>")

memory.add(
    [{"role": "user", "content": "I deploy on Fridays using ArgoCD"}],
    user_id="alice",
    agent_id="support-bot",
)

hits = memory.search(
    "when do we deploy",
    filters={"user_id": "alice", "agent_id": "support-bot"},
)

The api_key is your DataRobot API token. Memory-space scoping is entirely in the URL path - no extra headers.

Session lifecycle and retention¶

Every session carries one or more lifecycle strategies that control what happens to it over time. A strategy pairs an action—soft_delete (hide the session and its events) or extract_memories (promote the conversation to long-term memory)—with a trigger that decides when the action fires. If you do not supply any strategies at creation time, the server attaches a default soft_delete strategy with a 180-day TTL.

The following triggers are available:

session = Session.create(
    memory_space_id=space.id,
    participants=["67500a000000000000000001"],
    description="Triage chat #42",
    lifecycle_strategies=[{"type": "soft_delete", "trigger": {"ttl": 604800}}],
)

Never-expire sessions¶

The never trigger opts a session out of automatic lifecycle execution entirely: the session and its events are retained until an explicit session delete (or an administrator-triggered permanent deletion) removes them.

session = Session.create(
    memory_space_id=space.id,
    participants=["67500a000000000000000001"],
    description="Application settings store",
    lifecycle_strategies=[{"type": "soft_delete", "trigger": {"never": True}}],
)

Lifecycle strategies are set when the session is created and cannot be changed afterwards, so the never trigger applies to new sessions only. Sessions created earlier keep the expiry they were given; to hold existing data indefinitely, create a new session with the never trigger and write the data to it.

Use the never trigger for:

• Application system data: Records such as user profiles, settings, and workspaces stored in session metadata, where expiry would break the application rather than clean up stale data. A dormant installation survives any retention window without keep-alive traffic.
• Compliance retention beyond two years: The ttl and idle triggers cap at two years, so a longer retention floor (for example, a six-year regulatory requirement for chat history) is only expressible with never.

Avoid the never trigger for ordinary conversational history: nothing collects never-expire sessions automatically, so deleting them becomes your application's responsibility. Prefer ttl or idle for data with a natural end of life.