Managed Deep Agents v0.10 发布，新增浏览器使用与异步子智能体

‍

Managed Deep Agents v0.10 is out today. It adds browser use, so your agent can work on websites that have no API, and async subagents, which run long tasks in the background while your agent keeps talking to you.

In this post, we cover why agents need each one and how to turn it on, then the rest of the release.

Give your agent a browser

Booking travel, canceling a subscription, or filing a claim all happen on sites built for people clicking through pages, and there's often no API an agent can call. While agents can reason through how to complete the task, they can’t take action on websites without an API. Fetching the page with curl doesn't get far either, it produces HTML before any JavaScript renders the page and the agent can't click anything.

Personal agents like Instinct and Meta's Muse can browse websites to unlock a broader set of use cases, and DataDomesaw agentic browser requests jump 4.7x in September alone. Coding agents need a browser too, to check that a change to an app actually renders and works.

We cover where a browser helps and how it works under the hood in “Browser use in Managed Deep Agents”. To turn it on, declare a browser at your project root:

# browser.py
from managed_deepagents import define_browser

browser = define_browser(scope="thread", idle_ttl_seconds=600)

Managed Deep Agents runs the browser in its own LangSmith sandbox and adds the following browser tools to your agent automatically:

ToolWhat it doesbrowser_snapshotReads the page's accessibility tree and assigns element IDsbrowser_runNavigates and interacts, through JavaScript or batches of actions against snapshot IDsbrowser_screenshotCaptures the page, optionally saving the image to the sandboxbrowser_handoffGives a person control of the window

By default, each conversation gets its own browser, which is reused across turns and starts with no cookies or logins from other threads. With scope="user", each signed-in person gets one browser whose logins carry across all of their conversations, so the agent only asks them to sign in to a site once.

Hand the browser to a person

Most browser agents stop at a login wall or a two-factor prompt. With browser_handoff, the agent hands the window to you instead, so your password never ends up in the model's messages or traces.

The agent calls browser_handoff(reason) and explains why it needs you. Your agent channels — like Slack and Studio — will show have a link to allow users of your agents to hand off browser control natively, which opens a link to interact with the remote browser and a Hand back button . Custom clients can render the handoff artifact themselves. Once you sign in and hand control back, the agent checks the page to see whether the login worked and continues. Handoff returns immediately, so the agent can do other work while it waits. Handoff links expire after 15 minutes.

Handoffs let your agent use a webpage for you, without seeing your credentials.

The browser use docs cover scopes, per-run configuration, and the full handoff flow.

Run subagents in the background

Subagents let an agent hand a focused task to a helper with its own context window. Previously in Managed Deep Agents, subagents ran inline, so the agent called one and waited for its answer. This works for a quick lookup, and still is a supported pattern. But for a long task backed by a synchronous agent, or where multiple agents need to be fanned out, the person talking to the agent waits too, and additional interactions with the orchestrator agent are blocked.

With Managed Deep Agents v0.10, you can run subagents asynchronously, without blocking the orchestrator agent, by adding async to a subagent definition:

from managed_deepagents import define_deep_agent

agent = define_deep_agent(
    name="research-assistant",
    model="openai:gpt-5.5",
    subagents=[
        {
            "name": "researcher",
            "description": "Researches a topic in the background.",
            "system_prompt": "Research the topic and report your findings.",
            "async": True,
        },
    ],
)

The agent starts an async subagent on its own thread and can keep talking to the user while the subagent(s) run(s). The orchestrator agent starts, checks on, updates, and cancels these tasks with a set of async task tools. Every served agent also gets a background copy of a general-purpose subagent, so it can choose at runtime whether to run delegated work in the foreground or the background.

Async subagents notify the agent on their own, so the agent never sits in a polling loop. What happens next depends on what the agent is doing when a subagent finishes:

When the subagent finishes, the agent isWhat happensBusyIt checks unfinished tasks before each model call, so the result arrives mid-runIdleThe subagent wakes it with a new runPaused on an approvalThe approval is left alone; the result arrives once the user answers

An async subagent shares the agent's sandbox, so it picks up the files the agent already wrote. Its run appears under the agent's run in LangSmith. In Slack, its approvals post back to the original thread, and answering them there resumes the subagent.

Also in v0.10

• runtime.thread: every thread now carries a record of where it started, such as a Slack thread, and who is on it. Tools can read runtime.thread on any run, which is how a Studio resume, a scheduled run, and an async subagent's wake-up run all reply in the original Slack thread.The runtime docs cover the managed fields tools can read.
• Stopping runs: Slack threads get a native Stop button that cancels the thread's runs, and Studio can cancel runs on Slack threads.
• Slack channel handlers (experimental): onEvent decides what each Slack event starts, including mentions, direct messages, other messages, and button clicks. status sets what Slack shows while a run works, and reply: "none"leaves replying to the agent. See the Slack channel docs.
• Bring your own Slack app: mda deploy asks which app a new Slack channel should use. You can pick one that LangSmith creates and manages, create a new one from a manifest, or use one you already have.
• resolveUser: when someone messages your agent in a channel like Slack, Managed Deep Agents verifies who sent it. resolveUser maps that sender to the matching user in your own system, so your tools can look up that person's account and permissions. Write it as a function or point it at an endpoint we call, and set it on the identitydeclaration to cover every channel or on a single channel.
• Breaking changes: connectors.mcp() and the connectors/ layout have been removed. MCP servers must be declared in tools/mcp.ts or tools/mcp.py. The sandbox scope option is also removed. For LANGSMITH_*variables, shell environment variables now win over a project .env.

Getting started

Managed Deep Agents v0.10 is available in public beta today. Start from the docs, or create a new project:

uvx --from managed-deepagents mda init my-agent
cd my-agent
uv run mda deploy

As always, we can't wait for you to tell us what you build.

ICYMI: v0.9 added agent-created schedules, per-run configuration, and Slack reactions. Read the v0.9 post.

‍