Version 11.13.0¶

September 30, 2026

This page contains the new features, enhancements, and fixed issues for DataRobot's Self-Managed AI Platform 11.13.0 release.

Version 11.13.0 includes the following new features and fixed issues.

Agentic AI¶

Public discoverability of A2A agent cards¶

Before calling an agent, A2A clients fetch the agent’s card from a well-known URL. Now, you can allow unauthenticated clients to reach /.well-known/agent-card.json on DataRobot agent endpoints. This permits external consumers and partners to complete that handshake without already holding an API key. Discovery is served from the existing endpoint structure on custom model deployments. An anonymous caller receives a redacted card—enough to identify the agent and how to authenticate—with internal details omitted. An authenticated caller in the same tenant receives the full (extended) card. A caller authenticated for a different tenant is rejected, as before.

BYO LLMs to the LLM gateway¶

The LLM gateway provides easy user access to supported LLMs, as configured by an enterprise admin. Previously the gateway only supported models provided by DataRobot. This releases introduces the ability to “bring your own LLM” and register it in the gateway catalog. By doing so, these LLMs share the same interface and support as out-of-the-box LLMs.

The administration of adding enterprise-supported LLMs is an API-only feature. Once onboarding of the LLM is complete, however, the model will appear in the gateway UI with an identifying badge for users with appropriate permission.

Build Workload images from source code¶

You can now hand DataRobot your source code and let the platform build the container image for a Workload—no local docker build, registry push, or registry credentials. Set imageBuildConfig on a container instead of setting imageUri, point it at an uploaded catalog snapshot with a codeRef, and trigger a build. When the build finishes, DataRobot writes imageUri onto the container for you.

This flow works on draft artifacts of type service, agent, or mcp. You choose the Dockerfile: upload one with your source (provided), or let the platform generate one (generated) from a Python (pyproject.toml + uv.lock) or Node.js (package.json + package-lock.json) project at the upload root. Generated builds install locked dependencies on an execution-environment base image. Anything else (pip, Poetry, Yarn, pnpm, mixed-language repos) needs a provided Dockerfile.

Each step is independent: re-upload source without rebuilding, rebuild without redeploying, or reuse the built image on more than one Workload.

For more information, see Build an image from source code.

MCP OAuth now validates with Okta¶

DataRobot MCP servers now support two-level OAuth checks with Okta. The platform gateway authenticates each request by verifying that the Okta-signed JWT is valid. When MCP builders opt in with MCP_ENABLE_OAUTH_CLAIM_VALIDATION, the MCP server then authorizes the tool call by validating the token’s audience (aud) against the value in the MCP configuration and confirming that the token includes every required scope.

You can declare required scopes per tool with a tool tag or a tool decorator. A JWT that uses a mismatched audience string—including a trailing-slash difference—or that is missing any required scope is rejected with a 403. Validation applies to both on-behalf-of (OBO) user flows and OBO external application flows.

On self-managed depoyments, MCP builders can also opt in to an unauthenticated MCP well-known endpoint with MCP_ENABLE_UNAUTHENTICATED_WELL_KNOWN_ROUTE. This feature is not available for STS deployments.

Deploy MCP servers using the Workload API¶

The DataRobot MCP template can now deploy your MCP server using the Workload API as a preview option, in addition to the existing serverless custom model deployment. With Workload API deployment, DataRobot builds the container image for you from your MCP server's source code, so you can customize the template and deploy it without building an image yourself.

Serverless deployment remains the default. To deploy to the Workload API instead, set ENABLE_MCP_ON_WORKLOAD_API=true in your .env file and run task deploy. Run task workload-deployment-flag-check to confirm which deployment mode your configuration resolves to before deploying. Optional settings control the Workload's Dockerfile path, container port, replica count, CPU, and memory. After deployment, the MCP endpoint is available from the Pulumi stack output, and MCP servers deployed as Workloads appear in the MCP UI when the Workload API is enabled for your organization.

For more information, see Standalone MCP server.

Registry and Console¶

Python pipelines in Registry¶

The Pipelines tab in Registry lets you author, run, and schedule Python pipelines as directed acyclic graphs (DAGs). Define work with @dr.task and @dr.pipeline`; DataRobot parses the task-call graph, runs independent tasks in parallel, and records status, logs, and results per task.

Add a pipeline from a three-step wizard: upload or paste the Python source (Definition), set parameters parsed from the pipeline signature (Inputs), and attach a reusable container image (Image)—select an existing image or create one with the packages the pipeline needs. Completing the definition phase saves a mutable draft. Recurring schedules require a locked pipeline: Lock & Schedule freezes the logic and environment, then sets a simple or advanced (cron) cadence in UTC. You can also run a pipeline immediately; when it is locked, image and inputs are immutable.

Each pipeline opens to an interactive Workflow view of the DAG, details, and runs history, with task-level stdout/stderr and downloadable return values. A scheduled run that would overlap another run of the same input is rejected. Images live on the Images tab and can be rebuilt or shared across pipelines.

Manage memory spaces in Registry¶

The Memory spaces in Registry is a centralized place to view and manage memory spaces for agentic applications. A memory space is an isolation boundary for chat sessions, events, and long-term semantic memories. From the Registry > Memory tile, you can see every space you created, own, or that another user shared with you. Filter the list with All, Owned, and Shared with me, and search by label or memory space ID.

Memory spaces are created through the REST API or Python client. In Registry, owners and users with share permissions can grant Consumer, Editor, or Owner access to users, groups, or organizations. Consumer is read-only; Editor can ingest memories, post events, and create sessions; Owner has full control, including delete and re-share. Sharing is managed in the Share dialog; it is not exposed through the memory service API or Python SDK.

An administrator must enable Enable Access to Agentic Memory API on the user's profile before they can open the page or call the memory API. With that flag on, you still see only spaces you own or that were shared with you—not every space in the organization.

Unified tracing UI for applications and deployments¶

Applications and deployments now share the same Tracing interface. Deployments have a dedicated Tracing tab. Search and filter traces by timestamp, status, and type; inspect spans in a combined list and timeline; and review attributes, logs, input, and output on one page.

Platform¶

User Activity Monitor filter and export updates¶

The User Activity Monitor uses a Filters panel allowing you to narrow the online report preview by username or user ID, project ID, organization name or ID, and event name. A new Audit events only option limits results to security-relevant audit events and excludes analytic-tracking events such as notebook interactions; this filter applies to both the online preview and exported reports. Click Apply filters to update the preview and Clear all to remove them.

Within the exported CSV archives, Admin Usage and App Usage reports also add Client IP (the address DataRobot received; N/A for automated events) and Was Success (true/false) for all events.

Code-first¶

Python 3.13 is now the default notebook and codespace environment¶

New notebooks and codespaces now use the built-in Python 3.13 environment image by default, replacing Python 3.11. The image includes Python 3.13, the DataRobot Python client, and common data science libraries. It is also required to connect a local IDE to a codespace over SSH.

Existing notebooks and codespaces keep the image already selected for them. To continue using Python 3.11, choose that image on the Environment tab. Self-managed administrators can restore Python 3.11 as the cluster default by setting DEFAULT_ENV_ID in values.yaml; see Notebooks.

Python 3.11 will be deprecated in a future release. DataRobot recommends upgrading to Python 3.13.

For more information, see Built-in environment images.

Search for groups by name through the API¶

You can now look up a group by its exact name using the new GET /api/v2/directoryEntities/ endpoint, without needing to belong to that group or hold admin permissions. Matching is case-insensitive.

This helps teams that manage sharing and access through CI/CD pipelines rather than the UI: previously, a standard user's search returned an empty list for any group they weren't a member of, with no indication that results had been filtered. Now any authenticated user can resolve a known group name to its ID and use that ID with the existing sharing endpoints to grant the group access to Use Cases, deployments, and other assets programmatically.

Results are scoped to the caller's own organization, and resolving a group ID grants no access on its own—the sharing endpoints continue to enforce their own permissions.

Deprecations and migrations¶

• The Python 3.11 image will be deprecated in a future release. DataRobot recommends upgrading to Python 3.13. See the announcement for more information.

• Prometheus Pushgateway support for Kavmon metrics export will be retired in January, 2027. Organizations should migrate to OpenTelemetry integration before this date for continued metrics export. For full details, see the install guide section on exporting Kubernetes availability monitor metrics.

Issues fixed in Release 11.13.0¶

GenAI fixes¶

• BUZZOK-31983: Fixes an issue where filtering a playground or custom application on a metadata column that the vector database has no data for returned an error containing only the column name. The error now states that the vector database holds no metadata for that column, and that the document file paths in the metadata dataset must exactly match the file names in the dataset.

• RAPTOR-20388: Fixes an issue where creating an execution environment version failed with a 409 error after an older version was deleted because deleted versions were still counted toward the version limit. Deleted versions are no longer included in that count.

• RAPTOR-20151: The custom model workshop now uses CUSTOM_TASK_VERSION_MAX_FILES as the limit on how many files can be deleted at once. A change to that value on the System Configuration page takes effect without an application restart.

• RAPTOR-19774: Fixes an issue where some uploaded custom model files, including vector database chunks.db files, were stored with extra bytes at the start and then failed to load. Multipart uploads are now saved as the file that was uploaded.

• RAPTOR-19743: Fixes an issue where updating a custom job returned a 500 error when the job contained a zero-length file. File size is now calculated correctly for empty files on every configured storage provider.

Data fixes¶

• DM-22413: Fixes an issue where the Insights page for a registered model issued many catalog list requests in parallel and exhausted API memory. List and search requests for datasets and catalog items from the same user now run one at a time.

Application fixes¶

• AECO-19: Fixes an issue where users with the Apps Consumer role received a 403 error on the Applications page.

Predictive AI fixes¶

• UIUX-17153: Fixes an error on the Lift Chart and ROC Curve insights for models with multiple backtests.

• MODEL-24739: Fixes an issue where an external test that produced empty or non-numeric scores was reported as successful, so the score stayed blank and that model and dataset pair was treated as already scored. Those runs are now marked failed and can be scored again.

• MMM-25410: For self-managed deployments, including STS, the deployment and workload tag UI now honors the configured limits for tags per deployment, tag name length, and tag value length (MMM_MAX_DEPLOYMENT_TAGS_PER_DEPLOYMENT, MMM_MAX_DEPLOYMENT_TAG_NAME_LENGTH, and MMM_MAX_DEPLOYMENT_TAG_VALUE_LENGTH).

• MMM-25355: Fixes an issue where creating a deployment tag failed with a 409 error when the tag name matched an existing runtime parameter on the same deployment. Tags and runtime parameters are matched separately, so the same name can be used for both.

Platform fixes¶

• PLT-24096: Non-Builder users can now call GET /api/v2/groups/. Applications that authorize users by group membership no longer receive a 403 error for those users.

• PLT-24004: Fixes an issue where permanently deleting a user was reported as completed when deletion failed while removing the user's no-code applications, which left the account partially deleted. That failure is now reported as a failed deletion.

• PLT-19724: Fixes an issue where system administrators were unable to increase an organization's seat license allocation from the License page without deleting the allocation, which removed every assigned seat. Allocations can be edited in place, and existing seat assignments are kept.

• FLEET-8009: Fixes an issue where an upgrade from version 10.x timed out. The queue-migration pre-upgrade hook waited for secrets that a 10.x install does not have. That migration is skipped on the 10.x to 11.x upgrade path, where RabbitMQ state is recreated.

• FLEET-6851: FILE_STORAGE_PREFIX in the datarobot-modeling-envvars ConfigMap now uses global.filestore.environment.FILE_STORAGE_PREFIX when that value is set. Previously the ConfigMap ignored that setting and fell back to the release namespace.

All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.