Managed Deep Agents v0.10: A Hosted Browser, a Sign-In Handoff and Background Subagents

LangChain put Managed Deep Agents v0.10 into public beta on October 29, 2026, and the release changes what a hosted agent can do rather than what it costs. A managed agent now drives its own browser, a person can take that browser over at a login wall, and long work can move into a subagent that finishes in the background while the conversation keeps going. That matters for teams whose agents stop dead at sites with no API.

LangSmith runs the harness, the runtime and the sandboxes (langchain.com); you write the instructions and the tools. Start with uvx --from managed-deepagents mda init my-agent, then uv run mda deploy. LangChain’s release post covers both features, the browser deep dive explains the design, and the blog index dates both posts October 29, 2026.

Four browser tools, added for you

Managed Deep Agents runs the browser in its own LangSmith sandbox and attaches four tools to your agent automatically.

Tool	What it does
browser_snapshot	Reads the page accessibility tree and labels interactive elements with IDs
browser_run	Navigates and interacts, through JavaScript or batches of actions against snapshot IDs
browser_screenshot	Captures the rendered page, optionally saving the image to the sandbox
browser_handoff	Gives a person control of the window

You turn it on from a file at the project root:

# browser.py
from managed_deepagents import define_browser

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

scope decides who shares a session. scope="thread" is the default: each conversation starts a fresh browser with no cookies or logins left from another thread, and that browser is reused across the thread’s turns. scope="user" gives each signed-in person one browser whose cookies carry across all of their conversations, so the agent asks you to sign in once. The browser stops after idle_ttl_seconds without activity, ten minutes by default.

The login wall is handed over, not typed around

Most browser agents stop at a login page or a two-factor prompt. browser_handoff(reason) hands the window to a person instead: the agent explains why it needs a human, Slack and Studio render a link to the remote browser, you sign in yourself and press Hand back, and the agent checks the page before it continues. Your password never enters the model’s messages or traces, which removes the reason many teams blocked browser agents. Handoff returns immediately, and the link expires after 15 minutes.

browser_run takes code, which keeps pages out of context

browser_run is not a click recorder. It takes code, so the agent can write a whole chain of steps as one call and return only what it needs, keeping most of the page out of the agent’s context. The tools are built on Stagehand, Browserbase’s open-source SDK. LangChain reports that on 100 WebVoyager tasks its toolsets passed 90% of tasks for $1.98 in total, while Browserbase’s MCP server, the closest alternative it tested, passed 89% at nine times the cost.

End-to-end testing through localhost

Browser use is not only for booking flights: a pull request changes a signup form, so the agent starts the app in its sandbox, opens the form and clicks through it, which is what LangChain’s own Open SWE coding agent does. The trick is a private link between browser and sandbox: when the browser opens localhost:5173, the request travels over that link to port 5173 inside the agent’s sandbox, so the app needs no public URL. Because every browser_run call is a piece of an ordinary Playwright script, the agent can save its steps and replay that file later with no model calls.

Subagents stop blocking the turn

Subagents used to run inline: the agent called one and waited for its answer. A subagent definition can now carry "async": True and run on its own thread while the orchestrator keeps talking to the user.

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 orchestrator gets task tools to start, check on, update and cancel those background runs, and every served agent also gets a background copy of a general-purpose subagent. Background tasks notify the agent themselves, so there is no polling loop.

Delivery depends on what the agent is doing. A busy agent picks the result up before its next model call, an idle agent is woken by a new run, and an agent paused on an approval keeps the result until you answer. A background subagent shares the agent’s sandbox, so it picks up files the agent already wrote, and its approvals post back to the original Slack thread.

The rest of v0.10 is smaller but operational: every thread carries a record of where it started and who is on it, tools can read runtime.thread on any run, Slack threads get a native Stop button that cancels the thread’s runs, and resolveUser maps a Slack sender to a user in your own system.

Breaking changes to schedule

Change	What to do
connectors.mcp() and the connectors/ layout are removed	Declare MCP servers in tools/mcp.ts or tools/mcp.py
The sandbox scope option is removed	Check any configuration that set it
Shell LANGSMITH_* variables now beat a project .env	Fix any deploy that relied on .env winning

What to do on Monday

• Add browser.py with define_browser to one project and pick the scope deliberately: thread for isolation, user if people should sign in once.
• Put the login-wall path in front of your security reviewers and check the claim worth checking: the credential never enters model messages or traces.
• Move one slow, blocking helper onto "async": True and one manual PR check onto the localhost bridge.

What is still open

This is a public beta, and the benchmark numbers come from LangChain’s own toolsets. The handoff link lives 15 minutes, the browser idles out after ten, and per-user scope means one person’s cookies travel across every conversation they start, which belongs in your data policy. For comparison, Microsoft Foundry’s browser automation tool already went GA, our guide to agentic browsers and the injection problem still applies to any agent that clicks a page someone else wrote, and Deep Agents context engineering covers the harness side.