Overview
This page lists the limitations that apply to the MongoDB Atlas Agent Engine during Public Preview. Each limitation also appears on the page that covers the affected feature.
Important
Public Preview Limitations
The MongoDB Atlas Agent Engine is in Public Preview. MongoDB does not recommend that you run production workloads on the platform, and does not provide service-level agreements (SLAs) or service-level objectives (SLOs) for platform availability during Public Preview.
Scaling and Concurrency
The Atlas Agent Engine does not autoscale agent deployments. The scaling.replicas field in the agent.yaml file sets a fixed sandbox count, and each session reserves one agent sandbox and one tool sandbox for its lifetime. As a result, this field sets the number of sessions that a deployment can serve concurrently.
The scaling.replicas field accepts a value from 1 to 512 and defaults to 4 when you omit it. When every sandbox is reserved, a new invoke request fails with a pool full error.
The 512 concurrent sandbox limit applies to the Orchestration Engine, which is scoped to a project and can serve more than one agent. The scaling.replicas values of all agents in a project count toward the same ceiling. To run more sandboxes than one project allows, distribute your agents across multiple projects.
To keep invoke requests from exhausting the pool, reuse session IDs across requests. Requests that share a session ID reuse one reservation, but requests that omit a session ID use a new pair of sandboxes. A session ID must be 1 to 128 characters long and can contain letters, numbers, underscores (_), and hyphens (-). Pass the session ID in the --session option of the agentengine invoke command, or in the X-Session-ID header of an API request.
If your invoke requests require per-session isolation, you can't reuse a session ID. To serve more sessions at the same time, increase the scaling.replicas value, or reduce the scaling.agent_idle_ttl_seconds and scaling.tool_idle_ttl_seconds values so that idle sessions release their sandboxes sooner.
Because the Atlas Agent Engine snapshots scaling values at build time, you must build and deploy the agent again for a change to take effect. To learn more about these fields, see Agent Contract Reference.
Orchestration Engine Capacity
An Orchestration Engine can serve up to 50 concurrent requests per second across all agents in its project.
If your workload requires higher concurrency, create a new project and deploy the additional agents in that project, or contact MongoDB Support for assistance.
Compute Resources
You can't configure the compute resources for an agent or for the Orchestration Engine. Each agent has 0.5 vCPU and 2 GB of memory, and each Orchestration Engine has 0.5 vCPU and 512 MB of memory. These values are fixed and don't change with your workload.
If your workload requires different resource allocations, contact MongoDB Support for assistance.
Agent Builds
The platform enforces the following build limits for each project:
Limit | Value |
|---|---|
Concurrent active builds | 10 |
Daily builds over a rolling 24-hour period | 100 |
If you exceed a build limit, the request returns a 400 Bad Request error with a RESOURCE_LIMIT_EXCEEDED message.
To learn more about building and deploying an agent, see Deploy Your Build.
GitHub App Integration
The Atlas Agent Engine GitHub App is not available during Public Preview. You can't install the app on your GitHub organization, so you can't use the Connect Repository flow in the Atlas Agent Engine UI, create a workspace from a GitHub repository, or recieve GitHub App webhook events.
To create and deploy a workspace during Public Preview, run the agentengine deploy command from a local clone of your repository instead.
To learn how to deploy from a local clone, see Deploy Your Build.
Secrets
The platform enforces the following limits on secrets:
Scope | Limit |
|---|---|
Per project | 100 |
Per workspace | 100 |
If you exceed a secret limit, the request returns a 400 Bad Request error with a RESOURCE_LIMIT_EXCEEDED message.
To learn how to set, read, and delete secrets, see Provision Cloud Secrets.
Organization, Project, and Workspace Resources
Each organization can have up to 100 organization service accounts. If you exceed this limit, the request returns a 400 Bad Request error with a RESOURCE_LIMIT_EXCEEDED message.
The following table lists the resource limits for each project:
Resource | Limit |
|---|---|
Workspaces | 25 |
API keys | 100 |
Credential providers | 100 |
Project service accounts | 100 |
If you exceed a resource limit, the request returns a 400 Bad Request error with a RESOURCE_LIMIT_EXCEEDED message.
To learn how to manage these resources, see View Organizations and Manage Organizations, Projects, and Workspaces.
Public API Stability
Note
API Stability During Public Preview
The Atlas Agent Engine public API is subject to change during Public Preview. Endpoints, request formats, and response formats might change without a backward-compatible migration path. Pin the agentengine CLI version that your automation depends on, and review release notes before you upgrade.
To learn about the credentials that authenticate API requests, see Manage API Keys and Service Accounts.
Security
Secret Access
Agents have access to all secrets in their project. New secrets are added at the project level, not the workspace level, by default. Agents that you deploy into an existing project can access every secret in the project, including the MONGODB_URI that other agents use.
To restrict a secret to one workspace, append the --workspace-scope flag when you call the agentengine secret set command.
Database Access
When you use the agentengine atlas setup command to create an Atlas connection, the connection grants readWriteAnyDatabase access on the destination cluster.
If you need database access with a narrower scope, manually create a database user in Atlas. Then, set a MONGODB_URI workspace secret with credentials scoped to the MDB_AGENTIC_STORE_DB and MONGOMEM_DB_NAME databases.
Agent Isolation
All agents deployed in a project share the same Orchestration Engine, or agent control plane. The Orchestration Engine does not enforce authentication or authorization against the calling agents.
If you need stronger agent isolation, deploy your agents in independent projects.
Tool Isolation
Tools run in the agent sandbox by default. To run a tool in the tool sandbox instead, list it in the sandboxes.tool.tools field of your agent.yaml file. You can list the tool name or a glob pattern that matches the tool name. Tools that request delegated credentials can run only in the tool sandbox.
The agent sandbox and the tool sandbox isolate their workloads from each other. For example, tools in the tool sandbox run separately from your agent's control flow in the agent sandbox. However, tools that run in the same sandbox are not isolated from each other.
Tools in the same sandbox can access all secrets and egress destinations that you configure for that sandbox. The Atlas Agent Engine does not scope secrets or network access to individual tools. Tools that run in the agent sandbox also share the agent sandbox's secrets and egress destinations with your agent code. If your agent requires isolation between tools, do not treat either sandbox as a per-tool security boundary.
If your agent uses a tool sandbox, each session reserves one tool sandbox while the session is active. All tool calls in the session that the Atlas Agent Engine routes to the tool sandbox run in that sandbox. The Atlas Agent Engine does not create a new tool sandbox for each tool call. If a session is idle for longer than the scaling.tool_idle_ttl_seconds value, the Atlas Agent Engine releases its tool sandbox. When the session becomes active again, it uses a new tool sandbox.
To configure sandbox secrets and egress destinations, see Agent YAML Schema and Manage Network Egress Policies.