Managed Deep Agents v0.10: Browser use and asynchronous subagents

‍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.

Browser handoff in Studio. The agent asked for help logging into a website, and you control the page until you click Hand back.📷

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

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.

‍