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.

Sharing and access control¶

Memory spaces use a user-level feature flag for API and Registry access, plus per-space sharing roles enforced by the agentic memory service.

Enable access to the agentic memory API¶

Before a user can call the agentic memory service or open Registry > Memory spaces, an organization or system administrator must enable the Enable Access to Agentic Memory API feature flag on that user's profile. Without this flag, the memory API and the Memory spaces page are unavailable.

1. Open Admin settings and go to user management.
2. Select the user and click View user profile.
3. Under user settings, enable Enable Access to Agentic Memory API.

Access is all-or-nothing at this layer: the flag does not define separate read and write tiers on the memory API. Once enabled, the user can use the memory service subject to per-space sharing (below).

Per-space sharing roles¶

Each memory space you can access is one you own or that another user shared with you. Listing and visibility follow sharing; the feature flag alone does not expose every memory space in the organization.

When you create or retrieve a memory space, the API response includes:

• rbacResourceId — a platform identifier used to enforce sharing (when present). You do not need this field for normal agentic memory API workflows.
• permissions — what you may do on that space (CAN_VIEW, CAN_UPDATE, CAN_DELETE, CAN_SHARE), as enforced by the memory service on each request.

Owners and users with share permissions can grant Consumer, Editor, or Owner roles to other users, groups, or organizations through the Registry Share dialog. All three roles are available in the role dropdown. See Memory space roles and Share a memory space.

Operations outside your permissions return insufficient-permissions errors. For schema details, see the Agentic memory service REST API (MemorySpaceResponse.permissions and MemorySpaceResponse.rbacResourceId).

To ingest memories, post events, or create sessions in a shared space, you must hold Editor or Owner on that space (not Consumer only).

Revoking a user's access removes all permissions immediately.

Manage sharing in Registry¶

Grant, change, or revoke access through Registry > Memory spaces, using the Share dialog on each memory space. That is the supported workflow for managing collaborators; sharing is not exposed through the agentic memory service API or the Python SDK.

For step-by-step instructions, see Share a memory space.

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}}],
)

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.
• Retention with no end date: Use never when the data must be kept for a period you cannot name today. For an obligation that is longer than two years but still finite, prefer raising the installation's maximum session TTL and keeping a ttl trigger. This allows the lifecycle worker to reclaim the session when the period ends. Confirm the applicable retention period with your compliance owner.

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.

Update retention on an existing session¶

A session created before a retention decision was made can be moved onto a different schedule—including the never trigger, if enabled—by replacing its lifecycle strategies:

session.update(
    lifecycle_strategies=[{"type": "soft_delete", "trigger": {"never": True}}],
)

The same update through the REST API:

curl -X PATCH "https://app.datarobot.com/api/v2/memory/MEMORY_SPACE_ID/sessions/SESSION_ID/" \
  -H "Authorization: Bearer <YOUR_DATAROBOT_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"lifecycleStrategies": [{"type": "soft_delete", "trigger": {"never": true}}]}'

The strategies you pass replace the whole list, so send every strategy the session should keep, not just the one you are changing. Omit the argument to leave the strategies untouched while updating other fields. The request is validated exactly as a create is: between one and five strategies, no duplicate strategy types, and the same rules for spaces without an LLM configured. Strategies cannot be cleared—Session.update raises a ValueError for lifecycle_strategies=None, and the REST API rejects an empty list or null with a 422 response.

Other semantics worth knowing:

• The update bumps the session version, and honors the If-Match precondition header like any other session update. Session.update sends the version it last read automatically; pass if_match=None to opt out of the check, or an integer to override it. Over REST, pass the version you last read as the If-Match header.
• A strategy type that has already run for the session cannot be reconfigured: the lifecycle executor never runs a type twice, so a change that could not take effect is rejected with a 409 response naming the type, rather than stored silently. Re-sending such a type with an unchanged configuration is accepted, so read-modify-write updates of the other fields keep working.
• Where the never trigger is not enabled, adding one to a strategy type that did not already carry it is rejected with a 422 response. A session that already stores a never trigger may resend it, so read-modify-write updates keep working. Moving a session off never onto ttl or idle is always allowed.