LangChain 在 LangSmith Cloud 公测 Managed Deep Agents

Introducing Managed Deep Agents

Updated November 2, 2026. Managed Deep Agents is in public beta on LangSmith Cloud, and this post now describes how it works today. It first ran on May 13, 2026, when we opened a private beta.

Managed Deep Agents lets you build a deep agent as a folder of files and deploy it to LangSmith with one command. You write the agent's instructions and tools and pick the model, and LangSmith runs the Deep Agents harness and the production runtime around it. There are no servers to run and no infrastructure to wire together.

A support agent, for example, can answer questions in a Slack channel and sweep stale tickets every night, with each of those declared as a file in its project. Managed Deep Agents is in public beta on LangSmith Cloud, and the quickstart takes you from an empty directory to a deployed agent.

Why we built it

Building a capable agent keeps getting easier. The open-source Deep Agents harness already gives an agent a filesystem and lets it plan its work and hand parts of it off to subagents.

Running that agent in production is still a lot of work, and it's impossible for an agent to be proactive or multiplayer unless it's running in production. It needs threads that survive restarts and a safe place to run the code it writes. It also needs memory that lasts between conversations and a record of what it did, and teams end up building and operating all of it before the agent reaches a single user. It needs a cron server to manage scheduled runs.

Managed Deep Agents takes that layer off your plate. Every deployment runs on LangSmith Agent Server, which gives you durable threads and streaming runs without operating a server.

We build our own agents this way. GTM Agent, Open SWE and Content Studio all run on Managed Deep Agents, and Content Studio's code shrank by about 80% when we moved it over.

An agent is a folder of files

A Managed Deep Agent is a normal Python project. The only required file is agent.py, which defines the agent with define_deep_agent. This is the research assistant from the quickstart:‍

from managed_deepagents import define_deep_agent

agent = define_deep_agent(
    name="research-assistant",
    model="openai:gpt-5.5",
    tools=[{"type": "web_search"}],
)

‍The system prompt lives next to it in instructions.md, and each folder under skills/ holds a playbook the agent loads when a task calls for it. Tools are ordinary Python functions under tools/ that you import into agent.py, and tools/mcp.py adds tools from remote MCP servers.

A few commands take the project from an empty directory to a deployment.‍

uvx --from managed-deepagents mda init research-assistant
cd research-assistant
uv sync
uv run mda dev
uv run mda deploy

mda dev starts a local Agent Server and opens the agent in LangSmith Studio, where you can chat with it and inspect its traces. mda deploy ships the project to LangSmith and adds your model provider's key to the deployment. If you'd rather have a coding agent do the setup, the managed-deep-agents skill walks it through the same steps.

Add what the agent needs

Each managed capability is a file or folder in the project, and mda deploy sets up whatever it finds. This lets you start with agent.py alone and add pieces as the agent grows.

• Memory. By default an agent remembers only the current thread. Add memory.py and it keeps knowledge across threads, in a layer shared by every caller, a private layer for each user, or both.
• Schedules. A file under schedules/ runs the agent on a cron schedule, and mda deploy provisions it once the deployment is live.
• Channels. With channels/slack.py, people start runs from Slack and get the agent's answers in the same conversation. Any service that can send a webhook can start runs over HTTP.
• Sandbox. sandbox/ gives the agent an isolated filesystem and shell for running the code it writes.
• Identity and connections. identity.py authenticates callers, so each person gets private threads, memory and credentials. Connections store API keys and run OAuth, so end users authorize their own accounts instead of you provisioning credentials for each one.
• Subagents. You declare subagents in the agent definition. An async subagent runs in the background while the agent keeps talking to the user.
• Evals. mda evals init -i sets up a Harbor eval workspace under evals/ and hands off to a coding agent to write the tasks.

A schedule, for example, is a few lines in schedules/daily_digest.py.

from managed_deepagents import define_schedule

schedule = define_schedule(
    cron="0 8 * * 1-5",
    timezone="America/Los_Angeles",
    prompt="Write the daily digest.",
)

Some capabilities need no file at all. The agent can use built-in web search powered by Parallel without a separate account or API key, and it can work in a browser, handing control to you when a site needs a login. To pause for human approval before selected tool calls, set interrupt_on in the agent definition.

Call it from your app or an MCP client

Every deployment serves the Agent Server API, so your own application can create threads and stream runs, or you can build a custom frontend on top of it. Deployments also serve an MCP endpoint at /mcp, which lets MCP clients like Claude Code call the agent as a tool.

What teams are building

Teams in the public beta run a wide range of agents on Managed Deep Agents, and a few patterns come up repeatedly:

• Incident triage. An agent picks up monitoring alerts posted to a Slack channel, investigates them in its sandbox, and reports what it found in the thread. Some teams have it open a pull request with the fix.
• Engineering workflows. A webhook from the team's issue tracker starts a run, and the agent works through a build-and-verify loop on the task. Other teams have an agent test fixes in preview environments with a browser before a person reviews them.
• Internal assistants in Slack. Teams deploy one agent per job, such as an HR policy assistant or a finance assistant that manages the team's tasks in its project tool.
• Agents inside a product. A customer-facing agent runs behind the company's own frontend through the Agent Server API, with per-user memory so each customer's context stays separate.
• Long-running project agents. One agent per project keeps that project's memory and handles tasks for its project managers as the work goes on.
• Scheduled work. Agents modeled on company functions, like sales or product, run on schedules and produce competitive reviews and marketing assets without anyone prompting them.

Improve the agent from real usage

Managed Deep Agents keeps the agent's instructions and skills in LangSmith Context Hub. Each mda deploy syncs instructions.md and skills/ from your project, and you can edit them in Context Hub for a quick change without redeploying. If someone changed the Hub copy since your last deploy, the CLI asks which version to keep.

Durable memory lives in Context Hub too, and the agent writes to it as it works. A support agent that learns your team's escalation path keeps it for every conversation that follows.

Runs are traced in LangSmith, so you can read every tool call and intermediate step. LangSmith Engine works from those traces to surface recurring issues and diagnose their cause. When you connect it to the agent's Context Hub repository, it can propose fixes to the instructions and skills.

Built on open-source Deep Agents

Managed Deep Agents runs the same open-source harness, with the same agent loop, filesystem tools, subagents and skills. In code, the difference is who compiles the agent. create_deep_agent returns a compiled agent that you run, and you own the backend, store, checkpointer and server around it. define_deep_agent takes the same parameters, minus the ones the runtime manages, and returns a definition that the managed runtime compiles for you.

If you've already built an agent with create_deep_agent, Move from Deep Agents walks through converting it. If you want full control over hosting, the Deep Agents SDK runs the same harness on your own infrastructure.

Get started

Follow the quickstart to deploy a research assistant. The tutorial then adds a custom search tool, durable memory and a daily schedule to the same project.

We would love to hear what you build, where the defaults work, and where you need more control.

‍