Skip to main content
Deploying a Managed Deep Agent creates or updates the hosted agent resource and syncs the managed file tree that contains instructions, skills, subagents, and tool configuration. A deploy does not create a LangSmith Deployment. For more information on what a deploy does create, refer to Created resources. Choose the interface that fits your task:
  • CLI for most setups.
  • SDKs for Python or TypeScript automation.
  • REST API when you need direct control over request payloads.
Managed Deep Agents is in private beta, available on LangSmith Cloud in the US region only. Join the waitlist to request access.
This page covers the full deploy workflow: project files, MCP tools, subagents, backends, shared-agent updates, and the REST API. For a faster, guided setup, see the quickstart.

Prerequisites

Before you deploy, make sure you have:
  • Managed Deep Agents private beta access.
  • A LangSmith API key for a workspace with private beta access, exported as LANGSMITH_API_KEY.
  • A client for your interface: deepagents-cli for the CLI, the managed-deepagents (Python) or @langchain/managed-deepagents (TypeScript) SDK for SDK workflows, or an HTTP client such as curl for the REST API. For install commands and version requirements, see Install a client in the quickstart.

Deploy from project files with the CLI

The CLI creates a local project, validates files, checks referenced MCP servers, and deploys the project to Managed Deep Agents. For all commands and project file rules, see the CLI reference.

Create a project

Create a Managed Deep Agents project:
The command generates: You can also add: The generated agent.json uses the readable local CLI format:
agent.json
Model identifiers use the {provider}:{model_id} form. For the providers and models you can use, see Supported models.
Edit AGENTS.md to define the agent’s behavior. The full project layout that deploy syncs to the managed file tree is:
deepagents init generates an empty tools.json, one example skill, and one example subagent so the initial deploy succeeds before you register an MCP server. Edit or remove the examples to fit your agent. Deploy reads every file in the project and syncs the tree to the Context Hub agent repo. For the complete field reference, see the CLI reference.

Add MCP tools

To let the agent call MCP tools, register the MCP server once for the workspace, then add tool entries to the project tools.json. Tool entries reference a registered server by URL. After you register a server, list its tools and print a paste-ready tools.json snippet:
The deepagents mcp-servers add command also tries to list tools after registration. Pass --no-tools when you want to skip that discovery step.
tools.json
Each tool requires name and mcp_server_url. The mcp_server_name and display_name fields are optional. Use the optional interrupt_config object to require human approval before a tool runs. Key each entry by "{mcp_server_url}::{tool_name}" and set it to true. Deploy validates referenced MCP server URLs before sending a request. If a server URL is not registered, deploy fails with a hint to add it. For server setup and OAuth, see Connect tools.

Add subagents

Subagents are delegated workers the main agent can call for focused tasks. Add a subagents/ directory to the project root, then create one directory per subagent. Each subagent directory requires an agent.json and an AGENTS.md, and can include its own tools.json and skills/. The subagent name comes from its directory name.
The subagent agent.json supports an optional description and model:
subagents/researcher/agent.json
Use model for new projects. For compatibility, the legacy model_id key still works in local subagent files, and the REST API subagent schema still uses model_id. Write the subagent instructions in subagents/researcher/AGENTS.md:
subagents/researcher/AGENTS.md
To give a subagent its own MCP tools, add subagents/researcher/tools.json with the same shape as the project-level tools.json. Subagent names are checked case insensitively for duplicates.

Review the complete project

Tools and subagents live outside agent.json: tools in tools.json, subagents in the subagents/ directory. A project that uses all three looks like this:
agent.json stays focused on agent metadata, model, and backend:
agent.json
AGENTS.md defines the main agent instructions:
AGENTS.md
tools.json references the workspace MCP server the main agent calls:
tools.json
subagents/researcher/agent.json sets the subagent metadata and model:
subagents/researcher/agent.json
subagents/researcher/AGENTS.md defines the subagent instructions:
subagents/researcher/AGENTS.md
subagents/researcher/tools.json gives the subagent its own MCP tools:
subagents/researcher/tools.json

Choose a backend

Managed Deep Agents projects generated by the CLI use the state backend in agent.json:
agent.json
Use a LangSmith sandbox backend when the agent needs an isolated environment for code execution, filesystem work, or long-running tasks. LangSmith manages the underlying sandbox lifecycle while the agent keeps its thread or agent scope. Add optional sandbox settings under backend in agent.json:
agent.json
backend.sandbox_config is valid only when backend.type is sandbox. For standalone sandbox features such as snapshots, service URLs, permissions, CLI commands, and SDK usage, see the LangSmith sandboxes overview.

Deploy the project

Deploy the local project:
To preview the assembled payload and managed file tree before deploying, run deepagents deploy --dry-run. The first deploy creates a Managed Deep Agent through /v1/deepagents/agents. Later deploys update the same remote agent using local deploy state. On success, the CLI prints the agent name, ID, short revision, the agent URL, and a post-deploy MCP health check:
The health output above is abbreviated; it includes the full mcp_check result for every referenced server. A mcp_check.ok value of True confirms the agent can reach the MCP servers its tools reference. Each deploy creates a new agent revision, even when no managed files changed, because deploy always sends a metadata update. The managed file tree itself only changes when its contents do.

Update a shared agent

For shared repositories or intentional updates to an existing Managed Deep Agent, set the target agent’s agent_id in agent.json:
agent.json
Then deploy:
Deploying with agent_id set updates an existing shared agent in place.
On first use, the CLI asks you to confirm before updating that remote agent. To skip the confirmation, pass --yes:

Troubleshoot a deploy

Create or update an agent with the SDK or API

Map project files to the SDK or API field

The create and update payloads accept the same project structure the CLI syncs. Each typed field maps to a managed file: Setting both a typed field and a files entry for the same path returns 422 (for example, instructions and files["AGENTS.md"]). Use one or the other for a given file. For the full request schema, see the update agent reference. On update, omitted fields are left unchanged. Nested structured fields such as tools, subagents, skills, and extras are replaced in full when you include them.

Authenticate and configure requests

For SDK usage, install and configure the Managed Deep Agents SDKs. For direct REST API calls, set request defaults:
API requests require the X-Api-Key header:
The Python SDK reads LANGSMITH_API_KEY from the environment. The TypeScript SDK takes an explicit apiKey.

Create an agent

Create the agent with the same instructions, tools, skills, and subagents the CLI keeps in project files: The REST API nests the model under runtime.model.model_id. The SDK and CLI use a top-level model field.
The call returns the created agent. Pass include_files=True to also return the managed file tree.

Update an existing agent

When you update an agent, include only the fields you want to change. Replace <agent_id> with the ID returned when you created the agent:
To remove raw managed files during an update, send deleted_paths, an array of relative file paths (for example, ["docs/old-notes.md"]). To remove a structured section such as all skills or subagents, send the field with an empty list.

Add raw managed files

Use top-level files for content that does not map cleanly to instructions, tools, skills, or subagents:

Check agent health

After create or update, check the agent’s backend and tool health with the SDK or API:
The result uses the same mcp_check shape shown in the deploy output.

Manage the agent lifecycle with the API

Use the agent management routes for lifecycle automation:

Next steps

After you create or deploy an agent, run it by creating a thread and streaming a run.